Announcement

Collapse
No announcement yet.

Mesa 22.3 Lands S3TC Texture Compression Software Fallback

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

  • Mesa 22.3 Lands S3TC Texture Compression Software Fallback

    Phoronix: Mesa 22.3 Lands S3TC Texture Compression Software Fallback

    As a follow-up to the recent article about Mesa preparing a software fallback for S3TC, that code was merged for next quarter's Mesa 22.3...

    https://www.phoronix.com/news/Mesa-2...-S3TC-Fallback

  • #2
    Great news. Raspberry didnt support s3tc and some games didnt work. For example, Morrowind on openmw engine
    https://youtu.be/z6NlabwfR_0

    Comment


    • #3
      OpenMW dev here, there is an environmental variable one can use "OPENMW_DECOMPRESS_TEXTURES" that when set will allow OpenMW (via OSG) to decompress s3tc in software.

      Comment


      • #4
        Out of interest, how many games are playable on arm systems, even with box86? (I say that as most games are compiled for x86, and Windows)

        I'd assumed that x86 emulation wasn't fast enough to make this useful in practice, but I'd be happy to be proven wrong.

        Comment


        • #5
          Originally posted by hamishmb View Post
          Out of interest, how many games are playable on arm systems, even with box86? (I say that as most games are compiled for x86, and Windows)

          I'd assumed that x86 emulation wasn't fast enough to make this useful in practice, but I'd be happy to be proven wrong.
          Notice the person said openmw. Open source game majority of them have arm builds.
          https://trac.wildfiregames.com/wiki/CompressedTextures
          https://en.wikipedia.org/wiki/List_o...ce_video_games

          0ad gives a very big reason why you want compression. 1/4 of the video memory required if you can s3tc compress and the GPU supports it. Raspberry pi their GPU does not support s3tc in GPU. Even software decoding textures equals 1/4 what you have to read from disc.

          Up until this point you have only need compression when the application are built and decode at runtime.

          Then you have games that in their engine have like zram https://en.wikipedia.org/wiki/Zram for their generated textures. These are the ones needing compression at runtime.

          https://forums.raspberrypi.com/viewtopic.php?t=289179 This person got to over 200 games playable on a Raspberry pi 4 lot use s3tc compression.

          Does pay to remember that the libtxc_dxtn​ yes mesa would use this for software fall back if the library was present for s3tc. This is from the time of patented. Turns out there is a compression format s2tc yes the 2 is not a typo. s2tc was patented expired when s3tc was add to opengl and turns out s2tc decodes s3tc with some artifacts. Yes there is a s2tc version of libtxc_dxtn out there for the time that s3tc was patented so you had some textures. Basically texture with artifacts is better than no textures..

          Now that s3tc is patented making the feature mainline mesa makes sense as this will remove the need to use libtxc_dxtn and in the process remove the problem of user having two choices and one of those options sux..

          Do note libtxc_dxtn is just decode s3tc not encode s3tc as well. These recent changes are talking about allowing compression and decompression. There are older amd and intel gpus that only support s3tc decode in hardware as well. Also noted in the bug reports is particular hardware s3tc decode or encode turns out to be broken as well.

          People have got openmw working with full graphics on raspberry pi 2 by adding libtxc_dxtn the s3tc version. Note debian based distributions like what raspberry pi OS has been based off of would have habit of giving you libtxc_dxtn_s2tc yes the s2tc version that is not decoding exactly right.

          The problem with s3tc decoder outside mesa leads to some fun issues because user can have missed installing libtxc_dxtn so end up with black boxes instead of textures/game not running at all or have installed libtxc_dxtn s2tc version so having texture artifacts(game looks horrible at times) or they have installed the correct libtxc_dxtn that is s3tc so get a game looking right. One in 3 of having game work right is not ideal. Of course a person without enough knowledge is not going to solve this problem right lot of times.

          Of course having s3tc decoder does not help you with the programs that need s3tc encoder.

          Comment


          • #6
            Good to know that lots of open source games can be made to work (or work better) now. I guess my real question was about the practicality of box86.

            That said, if it exists and gets talked about as much as it does, it must be useful for some lighter games at least.

            Comment


            • #7
              for that formally-patent-encumbered texture compression algorithm
              I believe the part in bold is a typo which should read "formerly-patent-encumbered".

              Comment


              • #8
                Originally posted by oiaohm View Post
                snip stream-of-conciousness about libtxc_dxtn, s3tc, s2tc
                As discussed in the previous thread about this patch, libtxc_dxtn sources were imported into Mesa soon after the s3tc patents expired in 2017 in commit 04396a134f003aece573df593acfa1ab4418ffe8 which wound up in a Mesa release as of version 17.3

                Subsequently the libtxc-dxtn-s2tc package was removed from debian, see https://bugs.debian.org/888430 , and debian stable (bullseye) no longer has it.

                I believe libtxc_dxtn contains code both for compressing and uncompressing. What this commit does, AFAICS, is wiring up use of it as a fallback for hardware lacking s3tc decompression support.


                Comment


                • #9
                  Originally posted by hamishmb View Post
                  Out of interest, how many games are playable on arm systems, even with box86? (I say that as most games are compiled for x86, and Windows)

                  I'd assumed that x86 emulation wasn't fast enough to make this useful in practice, but I'd be happy to be proven wrong.
                  you are mistaken. most existing games are android games and primarily work on arm systems

                  Comment

                  Working...
                  X