mirror of
https://github.com/MobileGL-Dev/MobileGL
synced 2026-09-09 12:48:32 +09:00
swung0x48
50815a232e
- GLFunctionsTable had three entries that are frontend queries wearing a
backend interface (plan B v2 §2.1(a)): GetIntegeri_v, GetInteger64i_v and
GetProgramiv. Two of them have NO caller at all - `grep -o
'gBackendFunctionsTable\.GL\.[A-Za-z_0-9]*'` outside MG_Backend/ lists 69
distinct entries and neither GetInteger64i_v nor GetProgramiv is among them -
so both table slots, both backends' implementations and both registrations are
deleted here. This is plan B §11 P0's first "strictly no-op free win".
- Nothing was moved into MG_Impl, because MG_Impl already answers all of it.
glGetInteger64i_v is served by GL_Getter.cpp:1240-1314, which handles the
indexed buffer queries itself and derives every other pname from its own
GetIntegeri_v ("Handing the leftovers straight to the backend instead made
glGetInteger64i_v disagree with glGetIntegeri_v on the very same pname").
glGetProgramiv is served by GL_Program.cpp, whose GL_COMPUTE_WORK_GROUP_SIZE
arm (:928-946) reads ProgramObject::GetComputeLocalSize - a link artifact of
the program the APPLICATION wrote, which is the only program in the
application's namespace. §4.7.1 class B.
- GetIntegeri_v stays, but only for what a backend genuinely owns. Its pure
frontend arms were unreachable: GL_Getter::GetIntegeri_v answers
GL_SHADER_STORAGE_BUFFER_{BINDING,START,SIZE} through
TryDecodeIndexedBufferQuery (:991-1029) and the six GL_IMAGE_BINDING_* pnames
at :1115-1153, and returns before touching the table. That left 9 dead cases
in DirectGLES.cpp and 9 in DirectVulkan.cpp - the plan's "15" undercounts the
two files separately. What still arrives is GL_MAX_COMPUTE_WORK_GROUP_COUNT /
_SIZE (GL_Getter.cpp:1161-1177, and MG_Util/ShaderTranspiler/CompileEnv.cpp
:134-138 asks the table directly), so DirectVulkan keeps exactly those two and
DirectGLES becomes a plain driver passthrough.
- The dead arms were also WRONG, which is why deleting rather than reconciling
them is the strict no-op: they clamped a bound range's size to the buffer's
current storage, while the frontend reports the size glBindBufferRange was
asked for verbatim (GL 4.6 core tables 23.4/23.5 - the clamp answered 0 for
KHR-GL43.shader_storage_buffer_object.basic-binding's shape). Had a later
refactor made the table the answer, the regression would have been silent.
- ProgramResourceCache::computeWorkGroupSize and the spirv-reflect entry-point
loop that filled it go with DirectVulkan's GetProgramiv; nothing else read it.
- Three cases added to AdvertisedLimitsScenario pin what the frontend answers,
on both lanes: the indexed SSBO binding/start/size on the 32- and 64-bit
widths INCLUDING a shrink of the store underneath the binding (the arm that
actually separates verbatim from clamped), the six image-unit pnames on both
widths, and the compute local size plus the INVALID_OPERATION a program with
no compute stage must give.
- Both new gates were shown to go red for their reason: making
GL_COMPUTE_WORK_GROUP_SIZE answer a defaulted (1,1,1) fails
ComputeLocalSizeComesFromTheLinkedProgram on both lanes, and re-introducing
the deleted store clamp in GL_Getter fails
IndexedBufferBindingsAreReportedVerbatimOnBothWidths on both lanes.
- Tested: cmake --build build-linux -j 24 (clean); ctest -L unit -j 12 ->
1382/1382 passed; ctest -R AdvertisedLimits -> 18/18 passed (6 pre-existing +
3 new, x DirectGLES and DirectVulkan).