mirror of
https://github.com/MobileGL-Dev/MobileGL
synced 2026-09-10 05:08:31 +09:00
BZLZHH
8b75628dec
Three separate holes, all of them silent, that KHR-GL3x.framebuffer_blit walks straight into because it clears and reads back depth and stencil directly: - glClearStencil was frontend-only. The value was recorded in render state and never synced, so the real driver kept its default of 0 and every glClear(GL_STENCIL_BUFFER_BIT) wrote zeros. glClearColor and glClearDepthf were already synced right next to it. - Stencil readback assumed GL_STENCIL_INDEX works. It is not part of core ES (it needs GL_NV_read_stencil) and a driver without it rejects the read outright, which left the caller's buffer untouched. Where the attachment is a combined depth-stencil buffer the packed GL_DEPTH_STENCIL read carries the same bytes in its low octet, so that is now the fallback; the widening to GL_UNSIGNED_SHORT/INT moved into the same helper, since even a byte-for-byte read needs it. - Depth readback always went through GL_UNSIGNED_INT. A floating-point depth attachment (GL_DEPTH_COMPONENT32F, GL_DEPTH32F_STENCIL8 - the latter is what dEQP's own fbo-surface-type wrapper framebuffer picks) rejects that with GL_INVALID_OPERATION and only reads back as GL_FLOAT. Try both. And one format gap behind the same test: GL_DEPTH_COMPONENT32 has no ES equivalent and was being normalized to the *unsized* GL_DEPTH_COMPONENT base format, which is not a legal glTexStorage/glRenderbufferStorage internal format there - the attachment ended up with no storage and the framebuffer read back as incomplete. GL_DEPTH_COMPONENT32F is the sized ES format that keeps the requested 32-bit depth footprint; the transfer type follows it to GL_FLOAT. Takes KHR-GL3x.framebuffer_blit from 0/3 to 2/3 (the remaining multisampled_to_singlesampled_blit_color_config_test is a separate single-channel MSAA resolve issue). Note that scissor_blit additionally needs the suite to run with a depth/stencil config the test agrees with (--deqp-gl-config-name=rgba8888d24s8): under FBO surfaces the test hardcodes GL_DEPTH24_STENCIL8 for its own buffers while dEQP's wrapper framebuffer defaults to GL_DEPTH32F_STENCIL8, and blitting depth between mismatched formats is a spec error that any conformant driver has to report.