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.
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.
SPIR-V buffer block members need to be fully decorated with offsets
(recursively), which means that any members with struct or array types
need their own types in order to support having different offset and
stride (arrays) decorations. This breaks struct assignment at the
language level, but that is intentional as I want to deal with the
member copying needed to implement struct assignment before emitting
code. It also removes the need for some of the complication in
target_spirv.c, but I'll deal with that later.
The recursively built tag for nested structs might be a bit too
aggressive, but that too can wait until I have a better idea of what's
needed.
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).
