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.
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).
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)
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.
When I wrote vkgen's stdint.h, qfcc didn't support long or ulong, and
with the common init check, it now matters that the correct types are
used. It turns out some of my structs may not have been initialized
correctly, but with the next commits (long and ulong for cexpr), they
should be but do seem to be working at least.
And use it in preference to the crusty old XSetScreenSaver API. This
should work on modern systems (though might need to support the dbus
method too, but that can wait).
I got a sync validation error on a scatter command (I think) thus the
setting was probably wrong. Most of the parameters are still what they
were, but I'll be able to tweak the barriers as necessary.
Unfortunately, it didn't help with the hang on fetching the light cull
query data when starting in fisheye mode (no hang when enabling fisheye
after startup). I'm not sure what's going on there other than the
queries aren't getting updated: the counts seem to be fine so maybe the
commands aren't running. I've probably got a tangled mess of
pseudo-parallel command buffers: I need to go through my system and
clean everything up.
Since spir-v needs actual bools for its conditional instructions, the
time to do bool properly finally came. As expected, the changes caused
quite a mess, but Ruamoko now does bool/true/false.
Unfortunately, the function isn't used yet, so it's easy to miss. I just
happened to notice things didn't look right when looking at my
projection matrices.
BSP textures have pre-generated mips, including the transparent
textures, but mips don't play nicely with the transparency color (255):
it gets blended to other colors (at least in ad tears). Regenerating the
mips from the rgba texture (using transparent black) produces nice
results.
Also, needed to discard on 0 alpha to avoid weird interactions with fog
(I didn't know ad tears had fog: I guess I had last loaded it before
implementing fog).
One is potentially legit (depends on what really happens when allocating
0-length arrays on the stack), but the offset null pointer ones are
dubious as `a` should never be null when `size` is non-zero, and when
`size` is zero, everything gets corrected.
Switching to native ruamoko bool for vkgen resulted in bool getting
incorrectly parsed as a string (which mean getting the string's address
written to the value). Fixes the randomly enabled debug pipelines (and
probably a few randomly disabled normal pipelines, though less likely as
they're usually implicitly initialized). The one bit of actual legit UB
(ie, that which wasn't immediately mitigated one way or another) found
by ubsan, and it was a data error.
Recent vulkan validation layers started complaining about vertex
processing stages having read-write buffers without atomics enabled
(fair enough), but I decided to get all the buffers that don't need to
be written.
Thanks to validation layers showing command buffer debug regions, it was
pretty easy to find the offending buffers. Did need to modify
QFV_PacketCopyBuffer to take a source barrier as well as the destination
barrier, but this is probably for the best.
Now all pipelines and any tasks that have a command buffer attached get
a region using their names (tasks use the function name). I don't know
when it happened, or if I failed to notice last time, but (sync)
validation layers now include the debug region for command buffers: very
nice.
The particle renderer uses the palette texture in the vertex shader, so
updating the palette needs the vertex shader stage included in the
barrier, but I imagine not all texture updates will need it, so add a
parameter to Vulkan_UpdateTex to select inclusion.
Recent nvidia drivers now crash with more than 17 views when building
pipelines. Still no idea if it's me or the drivers. However, I really
need to come up with a way to use the render graph render passes as a
template so things aren't so hard-coded.
There's still a lot of work needed to separate out quake from
quakeforge, but this lets my test scene get a rather mangled scene
rendering (weird translucency: not sure what I've done wrong: probably
bad clear).
It turns out what I thought was a cascade selection bug was just very
bad choice of cascade steps: factors of 8 just don't work nicely. I'm
not sure that simple factors work all that well, either. I need to make
the cascade system configurable and probably support more cascades.
This puts pixels that have not been rendered at infinity. I was rather
surprised to see fog in my test scene, but it depended on my position
relative to the origin, so something was definitely off (the pixels were
at the origin).
I'm not sure why the final range was only a factor of 4 instead of 8.
There are still issues with range selection, but I'll look into them in
a bit (flying around my little test scene really shows the problems).
While every possible subsystem needs an initialization call, all that
does is add the actual initialization task to the render graph system.
This allows the render graph to be fully configurable, initializing only
those subsystems that the graph needs.
Scripted initialization is still separated from startup as render graph
creation needs various resources (eg, attachments) defined before
creating render and compute passes, but all those need to be created
before the subsystems can actually start up.
Finally. However, it has effect only when no render config is provided.
When a config is provided, things will break currently as nothing is
done yet, but getting a config in will take some work in qwaq and also
the render graph system as I want to make the startup functions
configurable.
The config is a pre-parsed property list. Currently unsupported by
anything but Vulkan (but only a warning is given, not a hard error at
this stage), and Vulkan doesn't use it yet.
