glMultiDrawElementsIndirect documentation does not clarify that commands may not be read from client memory with core profile

[zopsicle]

The documentation for glMultiDrawElementsIndirect suggests that the indirect parameter may refer to client memory, if no buffer is bound to GL_DRAW_INDIRECT_BUFFER:

If a buffer is bound to the GL_DRAW_INDIRECT_BUFFER binding at the time of a call to glDrawElementsIndirect, indirect is interpreted as an offset, in basic machine units, into that buffer and the parameter data is read from the buffer rather than from client memory.

However, this is only allowed with compatibility profile. With core profile, draw commands can only be read from a buffer, not from client memory. But there is no mention of this distinction to be found in the documentation. I only found out after looking at Mesa source code and subsequently finding a forum post mentioning it.

[NogginBops]

Looking at the specification it says that the indirect parameter may be sourced from the

https://registry.khronos.org/OpenGL/specs/gl/glspec45.core.pdf page 351:

Arguments to the indirect commands DrawArraysIndirect, DrawElementsIndirect, MultiDrawArraysIndirect, and MultiDrawElementsIndirect (see section 10.4), and to DispatchComputeIndirect (see section 19) may be sourced from the buffer object currently bound to the corresponding indirect buffer target (see table 10.6), using the command’s indirect parameter as an offset into the buffer object in the same fashion as described in section 10.3.9.

I'm not sure if drivers implement this or if the wording of the spec needs to be fixed...

[NogginBops]

Looking at this issue https://github.com/KhronosGroup/OpenGL-API/issues/65 it seems like the specification does actually have an error for this. DrawArraysIndirect:

An INVALIDOPERATION error is generated if zero is bound to DRAW- INDIRECT_BUFFER.

DrawElementsIndirect:

An INVALIDOPERATION error is generated if zero is bound to DRAW- INDIRECT_BUFFER, or if no element array buffer is bound.

The rest of the indirect drawing function inherit these errors so I think we can safely change the wording of the documentation here to reflect that.