swung0x48/MobileGL
1
0
Fork 0
mirror of https://github.com/MobileGL-Dev/MobileGL synced 2026-09-11 13:48:30 +09:00
Code Issues Packages Projects Releases Wiki Activity

[Fix] (MG_Util, MG_Test): never take a non-null eglGetProcAddress result as support

Browse Source 
On GLVND Linux eglGetProcAddress returns a non-NULL trampoline for ANY
name - including a fabricated one - so pointer-nullness can never
signal driver support. The three EXT multi-draw entry points were
registered as required (spurious error logs on drivers without them)
and their pointers were trusted; the NVIDIA ES driver hands back a
stub for glMultiDrawElementsBaseVertexEXT that SILENTLY DROPS draws,
which once made a "77% faster" multi-draw batch that rendered nothing.

The three entries are optional now, and two extension-derived
capability flags follow the established Supports* pattern - each is an
extension-string check AND a resolved pointer, so a flag alone is
sufficient at a call site:
  SupportsMultiDrawIndirect: GL_EXT_multi_draw_indirect + both entry
  points resolved.
  SupportsMultiDrawElementsBaseVertex: (GL_EXT or
  GL_OES_draw_elements_base_vertex) + GL_EXT_multi_draw_arrays + the
  entry point resolved. The multi_draw_arrays conjunct is the registry
  fact the stub exploited: glMultiDrawElementsBaseVertexEXT exists only
  in interaction with GL_EXT_multi_draw_arrays, and this NVIDIA driver
  advertises everything else EXCEPT that one - so the entry point is
  genuinely unsupported while eglGetProcAddress still "resolves" it.

Two DriverPost rows report both capabilities (INFO when absent - a
fallback always exists). Unit tests pin the stub shape, the exact
NVIDIA shape, the supported shape and extension-without-pointer.

Proven load-bearing: forcing the old pointer-only condition on the
NVIDIA ES driver reproduces the silent drop exactly (sodium retrace
SSIM 1.000000 -> 0.329522, no crash, no GL error); with the gate the
same run is a literal 1.000000. Unit suite 423/423 (two new tests),
retrace subset 10/10, integration suite 52/52.
This commit is contained in:
BZLZHH
2026-08-07 06:00:54 -04:00
parent 335f2decbd
commit ac3a83b207
4 changed files with 133 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files
MobileGL/MG_Util/SelfTest/DriverPost.cpp
+25
View File
@@ -298,6 +298,31 @@ namespace MobileGL::MG_Util::SelfTest {
"not supported; no impact: the native indirect path deliberately does not "
"rely on it (shader-side emulation handles baseInstance semantics)");
}
// Both multi-draw rows gate on the capability flags, not the entry-point pointers:
// eglGetProcAddress may hand back a non-NULL stub for these on drivers without the
// extension (NVIDIA ES does, and its glMultiDrawElementsBaseVertexEXT stub silently
// drops every draw), so the pointers prove nothing. Absence is INFO in both cases
// because MobileGL falls back to an equivalent per-draw loop.
if (caps.SupportsMultiDrawIndirect) {
builder.Pass("Multi-draw indirect",
"glMultiDrawArrays/ElementsIndirectEXT available via GL_EXT_multi_draw_indirect");
} else {
builder.Info("Multi-draw indirect",
"GL_EXT_multi_draw_indirect not supported; no impact today: multi-draw "
"indirect is decomposed into per-command indirect draws regardless");
}
if (caps.SupportsMultiDrawElementsBaseVertex) {
builder.Pass("Multi-draw base vertex",
"glMultiDrawElementsBaseVertexEXT available (EXT/OES_draw_elements_base_vertex "
"with GL_EXT_multi_draw_arrays); glMultiDrawElementsBaseVertex batches into one "
"driver call");
} else {
builder.Info("Multi-draw base vertex",
"glMultiDrawElementsBaseVertexEXT not supported (needs EXT/OES_"
"draw_elements_base_vertex plus GL_EXT_multi_draw_arrays); "
"glMultiDrawElementsBaseVertex falls back to a per-draw loop with "
"identical output");
}
if (caps.SupportsTextureBorderClamp) {
builder.Pass("Texture border clamp",
"supported (GL_TEXTURE_BORDER_COLOR reaches the driver, so "