The technique used only works for AABBs. Trying to apply the model
matrix to the extent like that isn't valid. For now, switch back to
the naive approach. This is quite a bit slower, but at least it's
correct.
If there is only a single pass in the submit, barrierCount is zero
since there will be no inter-pass synchronization. This is almost
correct, but not quite, because if a Pass has compute and render work,
the render pass may need to synchronize with the compute pass. So a
barrier is still necessary. For simplicity, always allocate the full
number of barriers, even though the final render barrier will always be
empty.
Additionally, avoids passing NULL to memset when the barrier count is
zero and the barrier arrays are NULL.
This fixes issues where some fonts would have glyphs with weird windings
and they would get rendered inside-out.
Unfortunately updating msdfgen increased its size by a factor of 2-3x.
- rm :getTallyData, it's totally lame, just do a readback
- rm gpu_tally_get_data too, webgpu doesn't support it anyway
- Clamp tally copy count so it doesn't overflow buffer
- Tally buffer offset's gotta be a multiple of 4
- Return nil instead of 2 values when tally buffer isn't set
- Copy correct number of tallies (multiply by view count instead of max
view count)
- Skip occlusion queries entirely if no tally buffer was set
Quat:mul also takes numbers.
They both require 3 args when using numbers.
I didn't opt for the 4-component Mat4:mul(numbers) variant, mostly out
of laziness.
Co-Authored-By: Josip Miskovic <josipmiskovic@gmail.com>
They defaulted to 1 to avoid confusion when mipmaps weren't generated
during a render pass (withou the { mipmaps = true } flag), but now the
mipmaps flag is obsolete and render passes automatically generate
mipmaps for all levels in their texture views. This means that render
passes can have mipmaps by default again, which leads to better
appearance when sampling them later.