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.
Parentheses confused the term counting because they weren't taken into
account for the "neither expression can be split" check, resulting in a
later segfault due to walking off the end of the array.
That is, vector ops with 3-component general vectors and quaternion ops
with 3 and 4 component general vectors "promote" the general vectors to
vector or quaternion as appropriate. Needed for operations with
vector and quaternion literals.
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.
This took sorting out a few issues with type property evaluation, but it
seems to work nicely now. Just one known error to sort out and then it's
time to get the spir-v correct.
Explicit intrinsics are very similar to inline functions, so the
function data for generic explicit intrinsics functions also need a full
scope. Fixes the undefined symbols for generic type names.
There are problems with symbol lookup (eg, generic type names, image
operand names) but the system seems to be working: texelFetch ->
OpImageFetch (which uses explicit arguments even though it doesn't need
to) seems to set the arguments to OpImageFetch correctly.
Now all my glsl shaders build, though most likely none of them
correctly. However, I'm finally out of that tunnel... only to find
myself in a moonlit forest fill with the sounds of wolves (at least, I
hope they're wolves).
All was fine... until the texture handling. Ugh, what a mess: 16
variants of "texture", times all the sampler variants. And I haven't
done even half of them.
I won't say it belongs in glsl-builtins, though the glsl-specific stuff
probably does (glsl texture handling is a mess). Also adds sampler
attribute handling (which falls back to image when necessary).
If `@intrinsic()` is followed by `[expr_list]` then those expresses will
be used to create the intrinsic rather than the function's parameters,
allowing for reordering, adding extra parameters or even complex
expressions.
However, only the parsing is implemented.
Unfortunately, this require using different syntax for the two cases:
type.attr works in cases where types are expected, but not in
expressions (lots of shift/reduce and reduce/reduce conflicts). However,
treating type like an Objective-C class works nicely, though
`[type attrib(params)]` looks a little odd. However, this allows using
generic types to provide function calls (eg, converting texture
coordinates).
I had forgotten that subpassInput can't be used but the normal imageLoad
functions since they don't (and mustn't, by the spec) have subpassInput
as a possible type. While creating a specialized version works, I think
I need to come up with a better way of specifying intrinsics.
It seems the base atomic functions should use const for the data
parameters and just a reference for the mem parameter (not entirely sure
yet as I need to check with spirv-val, but there are still build
issues). Using __imageTexel correctly took a little thinking since it
returns a pointer but the atomic functions take a reference.
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.
Used the wrong generic type name for gvec4*, and missed @construct. Now
gridplane.frag tries to generate spir-v again (fails due to the
instruction names).
