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).
This fixes the tangled gl_PerVertex in geometry shaders. Other block
types aren't a concern as they're all user-specified and required to
have unique names (though I do suspect I did in and out incorrectly, but
that's for another day).
All math types (of the same width) are assignable, though warnings might
be issued, thus the type_assignable check used for block structs was too
broad resulting in incorrect specialization of generics.
I'd messed up the attribute check when encoding the type (such a
frequent occurrence, that) and forgotten to check for null pointer on
the list from the hash table. Fixes block member arrays not getting
their stride decoration.
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.
While there's still a duplicate type bug causing validation failure for
partupdate.comp, everything builds.
Also clean up a few build issues surrounding shaders.
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.
I forgot to set the symbol type of the members and the number of symbols
in the struct. Fixes the excessive initializers when writing to a block
struct.
Also ensure the type name has "tag " in it.
When targeting spir-v, qfcc does do dead code removal yet, so the return
followed the previous return (with no intervening label) so caused the
shader to not pass validation.
Now the fragment shaders work (mostly: there's a problem with discard in
the sprite shader).
I have no idea what should be promotion and what should be demotion, but
I think a specified format should at least be assignable to unspecified
format. It certainly helps get things compiling again.
While images are handles, they're not user-handles thus don't exist in
that name-space. slice.vert now compiles, but it looks like I have some
problems with sampled images/textures (sampler2D etc).
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.
An empty valid type list is a valid error since one can come from input
source code, but I still wanted an internal error for compiler-generated
generic functions when I get around to doing such.
It turns out it didn't need to expand the arguments itself. Now my
@image tests get past the pre-processor. ie, the following works (until
spir-v segs):
#define __image(t,...) @image(t __VA_OPT__(,) __VA_ARGS__)
#define _image(d,...) __image(float, d __VA_OPT__(,) __VA_ARGS__)
@generic(foo=[_image(1D,Array)]) { void bar(foo baz); }
It seems I hadn't understood the C spec very well when I implemented
__VA_ARGS__ as reading it again now was (after a bit of extra thought)
helpful in realizing that __VA_ARGS__ is simply a proper name for the
... "parameter". Fixes __VA_ARGS__ not expanding in the arguments to
another macro.
I think the __VA_ARGS__ magic macro is no longer needed, but I need to
test it properly before deleting it outright.
I'll probably tweak the syntax a little (make placement of the type more
flexible and not generate an error if either type or other arguments are
missing), but I think I like it result:
typedef @image(int, 2D, Array, R8) bimage;
typedef @image(float, 3D, Rgba8) fimage;
typedef @image(float, Cube, Rgba8) cube;
typedef @image(float, Array, Cube) cube_array;
Or mostly silent, since the core and enumeration symbols are expected to
be value, but the enumerant itself does not cause a diagnostic if not
found (needed for checking image dimension and format).
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.
