./bin/fbo-generatemipmap-formats -auto GL_EXT_texture_compression_rgtc Using test set: GL_EXT_texture_compression_rgtc Testing GL_COMPRESSED_RED Probe at (1,1) Expected: 1.000000 0.000000 0.000000 1.000000 Observed: 0.988235 0.000000 0.000000 1.000000 Testing GL_COMPRESSED_RED_RGTC1_EXT Probe at (1,1) Expected: 1.000000 0.000000 0.000000 1.000000 Observed: 0.988235 0.000000 0.000000 1.000000 Testing GL_COMPRESSED_RG Testing GL_COMPRESSED_RED_GREEN_RGTC2_EXT Testing GL_COMPRESSED_RED (NPOT) Probe at (1,1) Expected: 1.000000 0.000000 0.000000 1.000000 Observed: 0.988235 0.000000 0.000000 1.000000 Testing GL_COMPRESSED_RED_RGTC1_EXT (NPOT) Probe at (1,1) Expected: 1.000000 0.000000 0.000000 1.000000 Observed: 0.988235 0.000000 0.000000 1.000000 Testing GL_COMPRESSED_RG (NPOT) Testing GL_COMPRESSED_RED_GREEN_RGTC2_EXT (NPOT) PIGLIT: {'result': 'fail' } f8d40deea5c4abbbf93c2c572ce668a5a25f95e2 is the first bad commit commit f8d40deea5c4abbbf93c2c572ce668a5a25f95e2 Author: Kenneth Graunke <kenneth@whitecape.org> Date: Tue Jun 5 23:51:04 2012 -0700 mesa: Return 8 bits for GL_TEXTURE_RED_SIZE on RGTC formats. From the issues section of the GL_ARB_texture_compression_rgtc extension: 15) What should glGetTexLevelParameter return for GL_TEXTURE_GREEN_SIZE and GL_TEXTURE_BLUE_SIZE for the RGTC1 formats? What should glGetTexLevelParameter return for GL_TEXTURE_BLUE_SIZE for the RGTC2 formats? RESOLVED: Zero bits. These formats always return 0.0 for these respective components and have no bits devoted to these components. Returning 8 bits for red size of RGTC1 and the red and green sizes of RGTC2 makes sense because that's the maximum potential precision for the uncompressed texels. Thus, we need to return 8 bits for GL_TEXTURE_RED_SIZE on all RGTC formats and 8 bits for GL_TEXTURE_GREEN_SIZE on RGTC2 formats. BLUE should be 0. Fixes oglconform/rgtc/advanced.texture_fetch.tex_param. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Brian Paul <brianp@vmware.com> BTW llvmpipe works fine. GPU:RV530 Kernel: 3.4.0-1.fc17.i686
Hmm. That patch shouldn't have changed the result at all---and it does look fairly close---so I think your hardware just has somewhat lower precision than mine. The Piglit test uses GL_RED_SIZE etc. to determine the tolerances/precision expected, so with the increase from 4 to 8, the test became more stringent. Normally this would make sense, but since GL_RED_SIZE and friends are /approximate/ precision for a compressed format---and in this case, the /maximum/ precision---I think we may need to lower the test's tolerances. Changing this to a Piglit bug.
Can't find this exact test in the piglit anymore, probably fixed.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.