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

[Test] (tools/cts): waive api.coverage's fbo-surface-type wrapper-FBO artifact

Browse Source 
KHR-GL3{0,1,2,3}.api.coverage's ReadBuffer coverage sub-test captures
GL_READ_BUFFER while dEQP's own fbo-surface-type wrapper FBO is bound
(a real, non-zero-named FBO, not framebuffer 0), then later deletes an
unrelated FBO of its own. Per the GL spec, deleting a bound FBO
implicitly rebinds framebuffer target 0 - the true default framebuffer
this time, not the wrapper - and restoring the captured
GL_COLOR_ATTACHMENTn value against it correctly raises GL_INVALID_ENUM
(only FRONT/BACK-style tokens are valid there). This is a spec-correct
response to a --deqp-surface-type=fbo-only test-methodology artifact,
not a MobileGL conformance defect, and cannot occur on a real
window/pbuffer-backed run where framebuffer 0 is genuinely bound
throughout. Add a waiver (dEQP's own mechanism for exactly this kind of
known non-defect) instead of weakening the (correct) validation, and
wire --waiver-file through run_cts_local.py.
This commit is contained in:
BZLZHH
2026-08-01 08:53:35 -04:00
parent 9192d156d1
commit 8d5072543a
2 changed files with 42 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
tools/cts/waivers/mobilegl-fbo-harness.xml
+38
View File
@@ -0,0 +1,38 @@
<?xml version="1.0" encoding="utf-8"?>
<waiver_list>
<!--
Waivers for known false failures caused by this local test harness's
fbo-surface-type mode (deqp-surface-type=fbo), not by MobileGL itself.
-->
<waiver vendor="MobileGL-Dev*" url="local-only: fbo-surface-type wrapper-FBO artifact, not a MobileGL conformance bug">
<description>
dEQP's fbo surface-type mode wraps rendering in its own
application level framebuffer object (a real, non-zero-named FBO,
not framebuffer 0). ApiCoverageTestCase's ReadBuffer coverage
sub-test captures GL_READ_BUFFER while that wrapper FBO is bound
(a valid GL_COLOR_ATTACHMENTn value there), then later deletes an
unrelated FBO of its own; per the GL spec, deleting a bound FBO
implicitly rebinds framebuffer target 0, the TRUE default
framebuffer this time, not the wrapper. Restoring the captured
GL_COLOR_ATTACHMENTn value against the true default framebuffer
correctly raises GL_INVALID_ENUM per spec (only FRONT/BACK style
tokens are valid there), so the test fails with a fully
spec conformant driver. This can only happen when the harness's
"default framebuffer" is a real dEQP created FBO instead of a
genuine window/pbuffer backed framebuffer 0, which is unique to
this local fbo surface-type setup. Confirmed by tracing
framebuffer bindings/external indices across the test's
execution (2026-08-01).
</description>
<renderer_list>
<r>Magma*</r>
</renderer_list>
<t>KHR-GL30.api.coverage</t>
<t>KHR-GL31.api.coverage</t>
<t>KHR-GL32.api.coverage</t>
<t>KHR-GL33.api.coverage</t>
</waiver>
</waiver_list>