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.
It doesn't really work yet for multiple reasons (eg, not an exact match
with the spir-v names, and the type system itself being a little
inadequate), but gotta start somewhere.
It turns out it was completely tangled up when I first wrote it. The
previous correction got things mostly right, but the overall sign was
wrong (ie, it gave -1..0 instead of 1..0)
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).
Things aren't quite working yet (currently due to buffer blocks not
getting marked NonWritable (or maybe they should be BufferBlock)), but
this gets shader compilation via qfcc working at all, including
automatic dependencies.
