S3TC => r600{c,g}

[nanonyme]

Actually As Far As I Know 2) is already implemented in mesa and doesn't have patent issues (since no software decompression is involved). A workaround for 1) was started in this mesa branch http://cgit.freedesktop.org/~csimpso...tc-by-the-book.
I asked Corbin about it, and he said he would ask Ian Romanick to have a look at it. Basically it should do what you said, skip compression and change texture type. I think this would be the best solution as it would avoid the patent problem completely, would not require an external library and would work more or less automatically with all drivers. Also with modern cards VRAM size should not be a problem. Let's hope work on that side progresses.

As far as I've understood only works with r300g, not on r600g. And that's because the stuff has been RE'd on r300g. Not part of the docco deliveries.

[lxnt]

As far as I've understood only works with r300g, not on r600g. And that's because the stuff has been RE'd on r300g. Not part of the docco deliveries.

Here's the situation with r600g:

Texture format is represented by 6 bits (SQ_TEX_RESOURCE_WORD1_0 aka R_038004_RESOURCE0_WORD1, bits 31-26)

Of those 64 values, 48 are used for regular texture formats.

Thus, 15 values are not defined.

There are 5 S3TC formats, and a bunch of other texture compression formats.

My guess is that a simple test program drawing some triangles with compressed textures and a temporary method to submit any value as a format will allow to find the correct value for various supported texture compression formats assuming there are no side effects and/or other registers/fields don't change meaning in the face of a compressed texture.

Or AMD can just release the information.

[lxnt]

http://lxnt.info/stuff/radeon/dxtn-upload-r600.png

Literally second attempt at guessing format codes succeeded.
On the above image you can see Nvidia compressed texture demo (suitably patched to compile and run undex X/Mesa), rendering a quad with a DXT1_RGBA-compressed texture loaded from a DDS file.

Seems like DXTn format codes are 0x49-0x52. This needs more thorough verification though.

RV770 0x1002:0x9440
ubuntu lucid x86
2.6.36-020636rc6-generic from the mainline ppa
libdrm and mesa - todays git
mesa diff: http://lxnt.info/stuff/radeon/dxtn-discovery.diff

[chrisr]

There's always the piglit tests

My guess is that a simple test program drawing some triangles with compressed textures and a temporary method to submit any value as a format will allow to find the correct value for various supported texture compression formats assuming there are no side effects and/or other registers/fields don't change meaning in the face of a compressed texture.

There are two piglit tests that are used for S3TC texturing: s3tc-teximage and s3tc-texsubimage. Perhaps these could be hacked to iterate over the possible values until the "magic" ones that display correctly are found?

[chrisr]

I have tried your patch with my RV790...

Literally second attempt at guessing format codes succeeded.

Those two piglit tests are giving the following results:

$ ./s3tc-teximage 
PIPE_FORMAT_DXT5_RGBA->R600_DXT5_RGBA, 0xffffffff
EE r600_texture.c/r600_translate_texformat:731 - Unable to handle texformat 14 PIPE_FORMAT_UYVY
EE r600_texture.c/r600_translate_texformat:731 - Unable to handle texformat 15 PIPE_FORMAT_YUYV
PIGLIT: {'result': 'skip' }

$ ./s3tc-texsubimage 
PIPE_FORMAT_DXT5_RGBA->R600_DXT5_RGBA, 0xffffffff
EE r600_texture.c/r600_translate_texformat:731 - Unable to handle texformat 14 PIPE_FORMAT_UYVY
EE r600_texture.c/r600_translate_texformat:731 - Unable to handle texformat 15 PIPE_FORMAT_YUYV
PIGLIT: {'result': 'skip' }

[lxnt]

Those two piglit tests are giving the following results:

:fail:

I know. Sigh.

Please look at the screenshot, the command line I used to run the demo set three (of four) environment variables.

Currently I belive the following values are correct:

R600_DXT1_RGB=49
R600_DXT1_RGBA=50
R600_DXT3_RGBA=51
R600_DXT5_RGBA=52

Without the R600_DXT5_RGBA Mesa will not advertize GL_EXT_texture_compression_s3tc, so piglit tests just won't run at all.

However, both s3tc-related piglit tests fail as of now. They create a compressed texture, not load compressed data from file, and I'm still digging how mesa+gallium handle the former.

What worked was uploading precompressed data.

(UYVY and YUYV messages are not related to s3tc/dxtn)

[netkas]

I know. Sigh.

Please look at the screenshot, the command line I used to run the demo set three (of four) environment variables.

Currently I belive the following values are correct:

R600_DXT1_RGB=49
R600_DXT1_RGBA=50
R600_DXT3_RGBA=51
R600_DXT5_RGBA=52

Without the R600_DXT5_RGBA Mesa will not advertize GL_EXT_texture_compression_s3tc, so piglit tests just won't run at all.

However, both s3tc-related piglit tests fail as of now. They create a compressed texture, not load compressed data from file, and I'm still digging how mesa+gallium handle the former.

What worked was uploading precompressed data.

(UYVY and YUYV messages are not related to s3tc/dxtn)

mesa/gallium compresses texture with help of external library (libtxc_smth) and then send compressed texture to card.

there is tex compession tests in mesa demos

[airlied]

the values are in the R700 ISA spec as BC1, BC3 and BC5 which are the DX10 equivs of DXTn,

though the driver needs a bit more work than just adding the values.

[kraftman]

Gallium can load an external s3tc library on demand if it's available. The major legal issues are hopefully on user's end. r600g will assumably sooner or later have a similar stance to s3tc as r300g. Of these I'm fairly sure. I'd give it a whack myself if I a bit less vague idea of how it works.

Here's a very easy way to have s3tc working:

https://bbs.archlinux.org/viewtopic.php?id=79509

Just add a repo, update and install Gallium and s3tc packages. That's all.

[chrisr]

Have you actually tested S3TC support with >= R600 cards?

Here's a very easy way to have s3tc working

My understanding is that the code for supporting S3TC with R600 (both classic and gallium) hasn't been written yet...