Instead of just stomping on the mode, it now validates asserts that the
previously set mode is correct and only changes it if needed. We need to
do this because, in geometry shaders, there are some builtins that can be
either an input or an output depending on context. We can get that
information from the SPIR-V source but we can't throw it away.
Previously, we were trying to handle them later when loading. However, at
that point, you've already lost information and it's harder to handle
certain corner-cases. In particular, if you have a shader that does
gl_PerVertex.gl_Position.x = foo
we have trouble because we see the .x and we don't know that we're in
gl_Position. If we, instead, handle it in OpAccessChain, we have all the
information we need and we can silently re-direct it to the appropreate
variable. This also lets us delete some code which is a nice side-effect.
When we get to the end of the _vtn_load/store_varaible recursion, we may
have one link left in the deref chain if there is a vector component select
on the end. In this case, we need to truncate the deref chain early so
that, when we make the copy for the load, we don't get the extra deref.
The final deref will be handled by the vector extract/insert that comes
later.
Previously, our location handling was focussed on either no location
(usually implicit 0) or a builting. Unfortunately, if you gave it a
location, it would blow it away and just not care. This worked fine with
crucible and our meta shaders but didn't work with the CTS. The new code
uses the "data.explicit_location" field to denote that it has a "final"
location (usually from a builtin) and, otherwise, the location is
considered to be relative to the base for that shader stage.
In Vulkan, VertexId and InstanceId will be zero-based and new intrinsics,
VertexIndex and InstanceIndex, will be added for non-zer-based. See also,
Khronos bug #14255
We don't actually use it to create all the instructions but we do use it
for insertion always. This should make things far more consistent for
implementing extended instructions.
We do control-flow handling as a two-step process. The first step is to
walk the instructions list and record various information about blocks and
functions. This is where the acutal nir_function_overload objects get
created. We also record the start/stop instruction for each block. Then
a second pass walks over each of the functions and over the blocks in each
function in a way that's NIR-friendly and actually parses the instructions.
Jason Ekstrand