Bugzilla – Bug 32888
[r600g] GL_EXT_texture_compression_s3tc support
Last modified: 2011-08-18 22:21:51 UTC
mesa: 6d9ca78ef7bf831b9b63f4bda68623cbae627508 (master)
r600g currently does not support the OpenGL extension GL_EXT_texture_compression_s3tc, whereas r600 classic does. Gallium drivers softpipe, llvmpipe, and r300g currently also support GL_EXT_texture_compression_s3tc.
GL_EXT_texture_compression_s3tc is a necessary extension for VMware Workstation and VMware Player to support hardware graphics acceleration in Windows guest operating systems.
wine also kind of requires this extension, since s3tc is mandatory for Direct3D translation inside the wined3d layer.
I just noticed that there is the R600_ENABLE_S3TC option and tried to enable it.
However this triggers the CS checker in the kernel and reject most of the commands. Tried with Max Payne 2 and FEAR, since I know that these two use texture compression when available (MP2 even in the menu):
1) MP2 just displays a black screen
2) FEAR works in the menu, but crashes when going ingame
In both cases I get an error from r600_check_texture_resource (r600_cs.c), which comes from r600_bpe_from_format not knowing the FMT_BCx formas.
The format code was introduced in this commit:
The corresponding debug option here:
I dunno how this should have ever worked, when the kernel immediately rejects these formats?
I found this interesting thread in the Phoronix forums:
Created attachment 43156 [details] [review]
Disable CS check for textures
To quote Keith:
Seems to sort-of work for non-mipmapped textures.
Tested with quake4 (where s3tc is mandatory) and FEAR. Like expected all mipmap levels are broken, which results in funny colors. Use GL_LINEAR as r_texturemode in quake-based engines to get an idea how it could look like :)
(i) new git master (including Dave's recent patches)
(ii) CS texture checking disabled
1) quake4 works flawlessly now, even with R600_FORCE_TILING=1
2) Max Payne 2 (through wine), where s3tc support is mandatory, also works.
Both tested in menu and ingame.
Enabling R600_FORCE_TILING doesn't show any obvious artifacts.
3) FEAR is still triggering GPU resets once you get ingame.
However this doesn't have to be related to texture compression support.
At least some textures are now visible, shortly before the driver
resets the GPU.
Retested with the latest d-r-t and at at least on my RV740 the new CS checker code seems to do the job right.
@Dave: Would it be safe now to also advertise the remaining two BC formats in r600g? The BC4 and BC5 one? Also, is it intended that the s3tc_to_blittable (and the reset function) take a level parameter, which isn't used inside the function?
Concerning FEAR: I don't think this is related to texture compression. I fiddled around with the ingame performance options yesterday and the GPU resets disappeared when I switched the engine from DX9 level to DX8 level pixel shaders. Maybe this is related to the GLSL piglit tests that still lockup the GPU.
Anyway, apart from manually enabling the envvar, this issue looks fixed to me.
not sure if the rest of the code in Mesa is setup to use BC4 or BC5 if we do advertise them from the driver. I'd have to check what they correspond to I think they are for RGTC as opposed to S3TC
oh I should remove that level, it was used during some of my hacks.
Yes, they are the RGTC formats.
I asked, because the formats are also advertised in r300g.
Ubuntu 11.10 i386
r600g has GL_EXT_texture_compression_s3tc on the above mention configuration.