Announcement

Collapse
No announcement yet.

S3TC => r600{c,g}

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #61
    I seem to be getting the same issue from r600g from xorg-edgers/radeon - any eta when the patch will be reverted/fixed in mesa master?

    Comment


    • #62
      Actually 32bit programs can use 64bit mesa you just have to make sure that your paths are set up correctly iirc its LIBGL_DRIVER_DIR= wherever your drivers are

      That was letting me run 32bit wine apps anyway on a 64bit gentoo... I did have most of the 32bit libs installed though except for mesa

      Comment


      • #63
        Are you absolutely sure about that one? 32 bit apps must link against 32-bit libs. That's why the compatibility libs are needed.

        Are you sure you didn't have x86-emul libs installed, including mesa?

        Comment


        • #64
          The only way 32-bit app can use 64-bit dri driver is glx protocol and indirect rendering, but then its limited to 1.4 ogl

          Comment


          • #65
            I just read that passing compressed texture work correctly with currend drivers put compressing them is not implemented.

            Can et be possible to patch wine in a way to prevend him to compress texture. If it's possible, it can fix a couple of games without touching the drivers..

            Comment


            • #66
              Originally posted by netkas View Post
              afaik, s3tc works in mesain two ways:

              1)rgb/rgba texture compressed with help of libtxc_dxtn and sent to gpu

              2) s3tc compressed texture sent to gpu

              so, why not just skip compression in first case, and change texture type to GL_RGB/RGBA

              in second case - decompress texture, chnage type and send to gpu

              so bye bye s3tc then
              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.

              Comment


              • #67
                Originally posted by kbios View Post
                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.

                Comment


                • #68
                  Originally posted by nanonyme View Post
                  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.

                  Comment


                  • #69
                    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

                    Comment


                    • #70
                      There's always the piglit tests

                      Originally posted by lxnt View Post
                      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?

                      Comment


                      • #71
                        I have tried your patch with my RV790...

                        Originally posted by lxnt View Post
                        Literally second attempt at guessing format codes succeeded.
                        Those two piglit tests are giving the following results:
                        Code:
                        $ ./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' }

                        Comment


                        • #72
                          Originally posted by chrisr View Post
                          Those two piglit tests are giving the following results:
                          Code:
                          :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:
                          Code:
                          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)

                          Comment


                          • #73
                            Originally posted by lxnt View Post
                            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:
                            Code:
                            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

                            Comment


                            • #74
                              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.

                              Comment


                              • #75
                                Originally posted by nanonyme View Post
                                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.

                                Comment

                                Working...
                                X