[Perf] (MG_Backend): batch DirectGLES multi-draw base-vertex where the driver really has it

When SupportsMultiDrawElementsBaseVertex is true, glMultiDrawElements-
BaseVertex issues one glMultiDrawElementsBaseVertexEXT instead of a
per-draw loop; the fallback loop is byte-identical otherwise.

The local NVIDIA ES driver lacks GL_EXT_multi_draw_arrays, so the
batch cannot engage here and no local win is claimed (counter-proven:
batched=0 / fallback=264329 across a sodium retrace). On Mesa llvmpipe,
which implements the full interaction, the batch engages (batched=4566,
~58 sub-draws per call) and is pixel-identical to a forced-fallback
control (same SSIM to the last digit). The beneficiaries are mobile
drivers advertising the interaction - the Sodium chunk path collapses
32 driver entries into one - and the DriverPost row shows which side
any device falls on. A/B on both backends: every case inside the 5%
bar. Unit suite 423/423, retrace subset 10/10.
This commit is contained in:
BZLZHH
2026-08-07 06:00:54 -04:00
parent ac3a83b207
commit d5f5e6405b
@@ -3155,6 +3155,13 @@ namespace MobileGL::MG_Backend::DirectGLES {
PrepareForDraw(syncBit);
CheckPrimitiveRestartSupported(type);
// Gate on the capability flag, never on the entry-point pointer: eglGetProcAddress
// returns a non-NULL stub for glMultiDrawElementsBaseVertexEXT on drivers without the
// extension interaction (NVIDIA ES), and that stub silently drops every draw.
if (g_GLESCapabilities.SupportsMultiDrawElementsBaseVertex) {
g_GLESFuncs.glMultiDrawElementsBaseVertexEXT(mode, count, type, indices, drawcount, basevertex);
return;
}
for (GLsizei i = 0; i < drawcount; ++i) {
g_GLESFuncs.glDrawElementsBaseVertex(mode, count[i], type, indices[i], basevertex[i]);
}