Announcement

Collapse
No announcement yet.

X.Org Server Change Allows GLAMOR To Fallback To Software Rendering For Obsolete GPUs

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

  • X.Org Server Change Allows GLAMOR To Fallback To Software Rendering For Obsolete GPUs

    Phoronix: X.Org Server Change Allows GLAMOR To Fallback To Software Rendering For Obsolete GPUs

    For those trying to use the X.Org Server's GLAMOR accelerated 2D rendering on legacy/obsolete GPUs, there's now a fallback in place to allow software rendering to work when encountering crippled hardware...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Matt Turner commenting, "I guess let's merge it and see what happens."

    You do not have permission to view this gallery.
    This gallery has 1 photos.

    Comment


    • #3
      This small commit is enough for me to keep using X11 instead of Wayland for my daily laptop.

      X11 still working without break anything, so I have no reason to migrate into Wayland for now

      Comment


      • #4
        it makes sense. Legacy/obsolete software allows to run on legacy/obsolete hardware. The modern cpus are better than those legacy hardware anyway.

        Comment


        • #5
          Back in the day, I played counterstrike, switched between gl and software, didn't notice any difference.

          These days, I can't even launch an app without lag if I relied only on software

          Comment


          • #6
            Originally posted by mirmirmir View Post
            Back in the day, I played counterstrike, switched between gl and software, didn't notice any difference.

            These days, I can't even launch an app without lag if I relied only on software
            decades of bloat and removal of "obsolete optimizations" plus blending 2d images in shaders instead of dedicated fixed function pipelines, ... ¯\_(ツ)_/¯

            Comment


            • #7
              Originally posted by mrg666 View Post
              it makes sense. Legacy/obsolete software allows to run on legacy/obsolete hardware.
              Usually, but not always true. More modern UNIX-like OSes run my ancient Intel GMA 915 GPU far better than software of that era. On Windows (XP), the vendor drivers never supported OpenGL past 1.2. On Linux and OpenBSD, I can get OpenGL 2.0. Some of it is emulated but not all of it, yielding almost double the performance.

              Sure, its a balancing act. I think the crocus driver for the legacy cards is a good middle ground.

              Installing Linux / BSD on SGI hardware is heresy though. For that the old OG software is the way to go.

              Originally posted by mrg666 View Post
              The modern cpus are better than those legacy hardware anyway.
              This is true to an extent. However, software rendering on any CPU takes more energy than a GPU doing the same task. It is less adapted to the task to efficiency suffers.

              That said, ancient CPUs that go hand in hand with ancient GPUs draw so much power that my above point is fairly redundant
              Last edited by kpedersen; 11 April 2024, 02:00 PM.

              Comment


              • #8
                And to be somehow more precise this change is important mainly for the very first D3D9 hardware generation which came with Shader Model 2.0. Those GPUs had support for only 64 ALU instructions while later Shader Model 2.0a and Shader Model 2.0b had support for 512.

                In the end this affects predominantly Intel iGPUs of the third and one model of the fourth generation, ergo the GMA 900 up to GMA 3150 models. From ATI/AMD only the original R300 series aka Radeon 9550 to 9800 GPUs were affected. All later Radeon GPUs came with Shader Model 2.0b or newer.

                Nvidia isn't affected by this because their D3D9 GPUs always came at least with Shader Model 2.0a and had therefore always support for 512 ALU instructions.

                However, this doesn't mean that Glamor works out of the box on ATI Radeon R400 and Nvidia NV30+ hardware. As of April 2024 Glamor works only for R500 ergo Shader Model 3.0 based hardware while the development for R400 is ongoing. Regarding Nvidia NV30 and NV40 hardware the state of Glamor is unfortunately quite unclear. Probably this is because the nv30 nouveau driver is in a not so good condition, - compared with the r300 driver.
                Last edited by lorn10; 12 April 2024, 12:12 PM.

                Comment


                • #9
                  Originally posted by lorn10 View Post
                  However, this doesn't mean that Glamor works out of the box on ATI Radeon R400 and Nvidia NV30+ hardware. As of April 2024 Glamor works only for R500 ergo Shader Model 3.0 based hardware while the development for R400 is ongoing.
                  Just to be curious, do you know the reason why R400 does not work? Is it because Glamor is using extensions/features not present on R400? And how is the plan to deal with this - add legacy shaders for older Model 2a?

                  Comment


                  • #10
                    Lot of ways this is not just Obsolete GPUs where this fall back to a software render could be good. Think some of your embedded GPU some of them are not great with one of the feature worse being the aspeed gpuless graphical output device that still in production and use for different things. Aspeed using item going straight to CPU 2d software rendering instead of having to go X11 to llvmpipe will be a help.

                    Comment

                    Working...
                    X