Announcement

Collapse
No announcement yet.

S3TC => r600{c,g}

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

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


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


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


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


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


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


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


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


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


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

                      Originally posted by kraftman View Post
                      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...

                      Comment

                      Working...
                      X