Since the main point of the low-level API is to make use of the
EXT_multi_draw_arrays / ANGLE_multi_draw / WEBGL_multi_draw extensions
for a reduced driver overhead *and* the builtin gl_DrawID variable, it
just doesn't make sense to provide a fallback to draw() in a loop. When
the extensions are not available, the user has to do extra work in order
to supply proper UBO draw offset for each draw call, and thus the
fallback path has basically no practical use.
On the other hand, draw() taking the MeshView instances is kept as-is --
this one is rather old and so breaking compatibility would be an
unnecessary pain point. Plus, since it has to allocate the contiguous
arrays internally, it's not desirable for any fast-path rendering
anyway.
It doesn't allow anything except full RGBA and 32-bit types to be read
from the framebuffer. Chromium browsers weren't complaining but Firefox
did. I remember a similar restriction from GLES2 but all implementations
I tested with including ANGLE and SwiftShader allow that already, so
it's practically just a WebGL limitation.
This doesn't actually fix the WebGL-specific error (there it
additionally disallows mismatched signedness in a vertex attribute) but
is nevertheless good to have correct.
Because a MeshView might not be the best thing to have when you are
submitting a batch of thousand draws. It takes a strided array views to
allow for more flexibility, but can also detect if the input is already
contiguous and use it as-is.
UNFORTUNATELY the GL 1.0 legacy still continues to stink and so there
has to be a 64-bit-specific overload which is the *actual* variant that
doesn't allocate because glMultiDrawElements takes a `void**` for INDEX
OFFSETS and it's IN BYTES! Which foolish soul designed such a thing back
in the 1860s, I wonder. There's no reason to not have an index offset
in elements because all indices have to have the same type ANYWAY. And
yes, I wasted about three hours debugging driver crashes because I
THOUGHT this parameter takes offset in elements, not bytes.
Also note: on 32-bit platforms this depends on latest Corrade with the
CORRADE_TARGET_32BIT definition. Spent an embarrassing amount of time
wondering why all local builds but Emscripten work.
Or, the horror when I comment-out half of it and it still kinda passes.
The new code tests it more thoroughly, with actually checking that
different draw produce different results instead of one draw overwriting
the other.
Plus also verifying interaction with gl_VertexID and gl_DrawID to ensure
it really behaves correctly:
- gl_VertexID should get the same value regardless of whether we
perform a multi-draw or a one-by-one fallback, so this catches issues
where the mesh would get reconfigured in some nasty way, losing this
information
- gl_DrawID should get properly populated if and only if we use the
multi-draw code path, so this catches issues where the fallback would
get used instead of the actual multi-draw code path
Instead make use of the ArrayView STL compatibility. To avoid breaking
almost all existing code the Corrade/Containers/ArrayViewStl.h header is
included implicitly when MAGNUM_BUILD_DEPRECATED is defined, but this
will get removed in some future release to speed up the compilation.
Would fail on an incomplete framebuffer error on framebuffer-less
windowless contexts. Didn't happen before, I think it's because of a new
check in a new Mesa.
This one crashes. Turns out the 169031fb7b
contained a random temporary test state instead of the real solution
(and so the comment didn't even match the code, it should have been
resetting that to 0). That also made some tests fail with DSA disabled,
but none of the tests were actual Mesh tests, just accidentally hitting
the problematic code path.
I took the opportunity to look at this more closely and investigate
*why* this failed -- turns out, in setIndexBuffer(), I was resetting
the state tracker to a VAO state that was about to be set in the very
next step, and then, when doing that next step the state tracker
"optimized away" the state change because it thought it was already done
(even though it wasn't). The new test in MeshGLTest covers this
particular case.
Vladimír Vondruš