I had no idea how to do it back when I started working on the glsl
parser, but intrinsics made it very easy. It's just OpKill for now (and
might stay that way for glsl).
The types are built with the correct attributes before any expressions
see them, so any necessary duplication is done early and guaranteed to
be only once. Now my compute shaders pass spirv-val.
However, other shaders are broken. But I think I know where to look.
This makes using structs in interface blocks possible by auto-casting
whenever possible. Now my compute shaders compile, but there's another
duplicate type sneaking in somehow.
I had initially thought I'd need to duplicate types for block members,
but that was before I did the higher-level type branching, and then I
forgot to record the type for block members. Fixes the duplicate types
on structs in blocks, and thus a type mismatch validation error in
partphysics.comp.
I had vaguely remembered there was something, but forgotten what it was,
then found it while debugging my compute shaders. This greatly
simplifies copying structs to/from blocks.
It's currently `@sampler(...)`, but I'm not sure about the name (should
it be `@sampled_image`, `@sampled` or similar?). However,
glsl-builtins.c uses `@image` and `@sampler` now, so one step closer to
my shaders compiling again.
It has come time to get image handle type creation into Ruamoko. This
commit only gets the functions and types independent of glsl, @image (my
plan for dealing with the handles) isn't implemented yet.
I had forgotten the parameters needed to be in reverse order (since
constructor_expr was written as the implementation of a function call),
and I had also forgotten I need to do the assignment. No more broken
lights :)
This is a hack until I rethink the entire glsl implementation, but it
gets my vertex shaders such that Vulkan no longer rejects them. However,
there are a couple struct related bugs (next).
This allows struct block members to be copied out of a block for spir-v.
The code may not be optimal (the full struct is copied rather than only
used members), but it gets my vertex shaders compiling again and thus
passing that part of validation.
Any matrix, array or struct member in a uniform/buffer block requires
offset and stride annotations. These seem to be calculated correctly
(tricky due to qfcc's internal size system, which I should probably
adjust based on target (I think type_size() and type_align() should help
here). Now I've got fun with incompatible structs that are the same type
in the source (thus pass type checks), but different in the target (due
to concrete vs abstract addressing).
The function queue needs to be cleared before figuring out the interface
symbols otherwise the variables referenced only by called functions will
not get into the list of interface symbols.
This means that `layout(triangles)` etc now work, though there are
issues with frag shaders missing functions (since getting function calls
working) and compute shaders silently failing.
But only for non-extension. I'm not sure it's quite right (as I don't
know if all void intrinsics should not have res type/id (all extension
instructions *do*)).
The spir-v back-end needs to emit literal values in some places and
supporting that in explicit intrinsics required marking the expression
as special. Unary = seems a little odd at first, but at the same time
seems to make sense, especially for marking expressions as "use literal
value" (eg =ImageOperands.Lod will result in a literal 2 instead of an
op id that points to the 2).
While there's a bit of code duplication, it very much cleans things up
for the various targets, especially v6 progs. However, spirv is not
implemented yet, so that's broken again.
The v6 and v6p targets don't have horizontal operations, instead they
have direct vector/quaternion equality to float/int scalar result. Fixes
an ice when building game-source/quake.
The operand kinds form namespaces for their enumerants (only BitEnum and
ValueEnum operand kinds are supported for this). Now `Lod` and `Bias`
use `ImageOperands.Lod` and `ImageOperands.Bias`, which is probably a
big improvement in the long run.
Finally, all of QF's shaders *compile*, though the spir-v is generally
incorrect (capabilities etc), and the code gen may still be full of
bugs.
I guess I hadn't thought of it because GLSL doesn't have `auto`, but
since the builtin functions are implemented in Ruamoko, `auto` is
available and I use it for the atomic image functions.
And disable it for GLSL. I might need to make it target-dependent
instead as I don't know if I'll be able to implement it in SPIR-V, and
when I get to the C back-end, it will be superfluous.
Spir-v is pretty slack with the exact types of the operants to the
right-shift instructions so no need to care about the type for shift so
long as it has the correct number of components.
