Yes, this is only ever provided by an ANGLE extension, and as you might
have guessed, The Great Google Overlords didn't bother caring to have
this supported outside of their browser.
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.
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.
Ew. At first I tried to just port a growable Array of StringViews (which
would already save quite a lot), but then I realized I have a clear
upper bound on the extensions and so can use a "counting sort" without
having to deduplicate anything after.
After the previous (rather minimal) reduction by the Context cleanup,
this reduces the size of magnum-gl-info.wasm from 245 to 237 kB. Quite
significant, I'd say!
Good thing I checked this -- based on WebGL I was under assumption that
all GPUs have it just 256, but that was really just WebGL limitation.
Also ugh why this query wasn't there since the 90's?
What's left is *a lot* of places taking monstrous
std::vector<std::reference_wrapper> and that can't be changed to
std::vector<Containers::Reference> in a source-compatible way. Even that
would be only a temporary change, since the goal is to fully avoid
dependency on STL in those cases.
The final version of these APIs should take
Containers::ArrayView<Containers::Reference> and be implicitly
convertible froom e.g. std::vector<Containers::Reference>. That's
definitely possible, but not in time for 2019.01, so instead of forcing
users to temporary pass a `{vec.begin(), vec.size()}` everywhere instead
of just `vec`, I'm rather keeping these APIs intact.
The change done in 680144f1c5 was not
properly handling these cases:
* Mesh(NoCreateT) and wrap() were not constructing the internal vector,
which blew up when move-assigning another instance.
* ~Mesh() was not destructing the internal vector if the VAO ID was
zero or non-owning wrap() was used.
Strangely enough none of these were causing *any* problems for me on
Linux (even ASan was totally quiet and due to the unfortunate
combination of bugs even when I assigned totally random data to the
storage vector). This however blew up on MSVC, assuming there the
implementation is more checked.
Because it's possible to construct Mesh with no GL context available,
the move construction and destruction needs to avoid accessing Context
unless really necessary (it would be also unclear which type of vector
should be constructed if we have no context).
Extended the tests to handle hopefully all the cases.
This is actually a preparation to make buffer-owning meshes a
possibility (where I would need an union of vectors otherwise),
nevertheless it removes the dependency on a vector.
At the moment just the GL library itself w/o the tests, and without
backwards compatibility aliases. The following types were left in the
root namespace, despite being in the GL/ directory, as they will get
moved back soon:
* Image, CompressedImage and their dimensional typedefs
* ImageView, CompressedImageView and their dimensional typedefs
* PixelStorage
Not PixelFormat etc., that one will stay in the GL namespace and a
completely new PixelFormat enum will be provided in the root namespace.
Minimal updates (just the include guards) so Git is hopefully able to
detect the rename and track the history properly.
Everything except Magnum::GL doesn't compile now.
Currently the user had to ensure that buffers added to mesh were not
moved at all, which was very annoying, basically each one of them had to
be allocated on heap. Now the Mesh stores a weak copy (yes, really) using
Buffer::wrap() with no deletion on destruction, so the original instance
can be freely moved around without any fear of crash.
Thanks to @Squareys for the original idea/request about wrap() functions,
really useful part of the API.
The original goal was to avoid branches when binding the vertex
attributes for drawing, so I stored float, integral and double
attributes in separate std::vector instances and then was going through
each one of them in separate loop. In retrospect that was _not_ a good
idea, because it results in larger Mesh class, two more allocations
resulting in far more pointer chasing and more complicated
constructor/destructor.
Now everything is stored in a single vector. I may optimize it further
by not calling the constructor/destructor on it when VAOs are used.
Actually properly supporting ANGLE_instanced_arrays. Emscripten
currently has the functions without the ANGLE suffix. Only causes linker
warnings when not used, need to fill a bugreport and fix properly.
This function was added to ARB_instanced_arrays spec very late and thus
some implementations don't provide it (one case being AMD drivers on
Linux). If that function is not available, the non-DSA VAO specification
is used instead.
No backward compatibility issues should exist, as the class is in most
(if not all) cases used with unscoped name:
class MyShader: public AbstractShaderProgram {
public:
typedef Attribute<0, Vector3> Position;
// ...
};
In OpenGL ES this is implemented in EXT_multi_draw_arrays extension, if
it is not available, the functionality is emulated using sequence of
normal draw() calls.
Functionality provided by GL 3.3 and ARB_instanced_arrays, on ES2 this
is again implemented in three different extensions --
{ANGLE,EXT,NV}_instanced_arrays. They are disabled until Magnum has
proper extension loading on ES.
On desktop GL this is provided by ARB_draw_instanced (GL 3.1). Base
instance is available only on desktop GL (4.2, ARB_base_instance). In
ES2 the instanced functionality is provided by three (!) different
extensions (ANGLE_instanced_arrays, EXT_draw_instanced,
NV_draw_instanced), the proper implementation is chosen on context
creation based on what extension is available. Though we don't have
extension loader for ES yet, thus all these extensions are disabled and
the implementation has assertion in it.
Added blind test which tests only that something has been drawn and no
errors were emitted, but not whether the right command is used. I'll
probably need to check this later, because the Mesh::draw() behemoth is
going slightly out of hand :)
The only places where they aren't absolute are:
- when header is included from corresponding source file
- when including headers which are not part of final installation (e.g.
test-specific configuration, headers from Implementation/)
Everything what was in src/ is now in src/Corrade, everything from
src/Plugins is now in src/MagnumPlugins, everything from external/ is in
src/MagnumExternal. Added new CMakeLists.txt file and updated the other
ones for the moves, no other change was made. If MAGNUM_BUILD_DEPRECATED
is set, everything compiles and installs like previously except for the
plugins, which are now in MagnumPlugins and not in Magnum/Plugins.
Vladimír Vondruš