mirror of
https://github.com/HeyPuter/gex.git
synced 2026-11-13 20:12:43 -10:00
velzieandClaude Opus 5
84ff44891c
`lookup` answers zero for a guest object name the host has never seen, and
zero is a *legal argument* to every call that takes one -- an unbind, the
default framebuffer, the default vertex array, the default transform feedback
object. So an unknown name did not lose the error GL owed: it performed a
different valid operation and reported success.
`lookup_bindable` has existed for this since KHR-GL32.buffer_objects
.gen_buffers, handing GL a name GL has never generated so GL raises the error
itself. It had three callers out of the eight sites that wanted it, and the
row saying so had been sitting in the notes for two sessions.
Landed only where the answer does not depend on the profile:
- glDrawTransformFeedback{,Instanced,Stream,StreamInstanced} -- an unknown
id became the *default* transform feedback object and the draw was legal.
Now GL_INVALID_VALUE. Fixed at the generator, not the generated file.
- glBindSampler -- samplers never had implicit creation. Now
GL_INVALID_OPERATION.
glBindFramebuffer, glBindRenderbuffer and glBindVertexArray are deliberately
*not* changed. A core context owes INVALID_OPERATION there, but a
compatibility context has EXT_framebuffer_object semantics and must implicitly
create the object -- and both profiles really occur, because the guest picks
one per EGL context: the CTS asks for core, a default eglCreateContext gets
compatibility. The host is not told which, so neither answer can be given yet.
The new probe also reports those three identically on native and in the
browser, so the transport is not what differs for them.
Found via KHR-GL44.transform_feedback.api_errors_test, which cost more than it
should have: the CTS prints "glUseProgram unexpectedly failed when transform
feedback is paused" at two sites, and at the second the code tests
glDrawTransformFeedback and never calls glUseProgram at all. An existing probe
had already cleared the real glUseProgram sequence 12/12, so the case read as
a dead end for as long as the message was believed.
The case now fails one check later, on an invalid-mode INVALID_ENUM that is
the same profile question arriving from a second direction, so the family is
still 18/21. Probe suite 160 OK of 167, same seven expected.
Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01KPX8TWunJNt4FwqbYDgTyz