spirv: add/hookup SpvCapabilityStencilExportEXT
authorGustavo Lima Chaves <gustavo.lima.chaves@intel.com>
Mon, 12 Feb 2018 02:26:40 +0000 (18:26 -0800)
committerCaio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
Fri, 8 Jun 2018 18:15:37 +0000 (11:15 -0700)
commit7cc5178bbadff29f7191f5e9ca8ea51a17ad5f06
tree55aeab519805d079950ba55f2668c6f0fbeb816d
parent22cc83cf870ba34ba2b8187698661f227fcec28b
spirv: add/hookup SpvCapabilityStencilExportEXT

v2:
An attempt to support SpvExecutionModeStencilRefReplacingEXT's behavior
also follows, with the interpretation to said mode being we prevent
writes to the built-in FragStencilRefEXT variable when the execution
mode isn't set.

v3:
A more cautious reading of 1db44252d01bf7539452ccc2b5210c74b8dcd573 led
me to a missing change that would stop (what I later discovered were)
GPU hangs on the CTS test written to exercise this.

v4:
Turn FragStencilRefEXT decoration usage without StencilRefReplacingEXT
mode into a warning, instead of trying to make the variable read-only.
If we are to follow the originating extension on GL, the built-in
variable in question should never be readable anyway.

v5/v6: rebases.

v7:
Fix check for gen9 lost in rebase. (Ilia)
Reduce the scope of the bool used to track whether
SpvExecutionModeStencilRefReplacingEXT was used. Was in shader_info,
moved to vtn_builder. (Jason)

v8:
Assert for fragment shader handling StencilRefReplacingEXT execution
mode. (Caio)
Remove warning logic, since an entry point might not have
StencilRefReplacingEXT execution mode, but the global output variable
might still exist for another entry point in the module. (Jason)

Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
src/compiler/shader_info.h
src/compiler/spirv/spirv_to_nir.c
src/compiler/spirv/vtn_variables.c