Announcement

Collapse
No announcement yet.

Mesa's Classic Drivers Have Been Retired - Affecting ATI R100/R200 & More

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

  • Originally posted by agd5f View Post
    The "more features" I was referring to in the kernel driver was stuff like native modesetting and display output handling. The 2D engine will be used in Xorg if using the xf86-video-ati DDX. There is nothing equivalent for wayland-based compositors.
    This is not just wayland compositors. Its been a long term problem that you cannot use 2d accelerators in gpu with any form of standard library without running X11.

    This effected directfb before wayland existed. Yes this has result in lots of programs using opengl to perform 2d work so ignoring the 2d accelerators existence.

    Device Dependent X (DDX) has really been one of the long term things that has hindered development over the years of a X11 replacement.

    agd5f think about it with the native modesetting driver and a program that directly setups the screen there is no way for that application to use the 2d engine when its not using DDX. This is not a Wayland problem. This is we have not provided library like mesa or standard like opengl/vulkan for 2d problem. Yes libraries/standard that can stand on their own two feet without X11 for 2d engines in gpus is missing.

    Comment


    • Originally posted by oiaohm View Post

      This is not just wayland compositors. Its been a long term problem that you cannot use 2d accelerators in gpu with any form of standard library without running X11.

      This effected directfb before wayland existed. Yes this has result in lots of programs using opengl to perform 2d work so ignoring the 2d accelerators existence.

      Device Dependent X (DDX) has really been one of the long term things that has hindered development over the years of a X11 replacement.

      agd5f think about it with the native modesetting driver and a program that directly setups the screen there is no way for that application to use the 2d engine when its not using DDX. This is not a Wayland problem. This is we have not provided library like mesa or standard like opengl/vulkan for 2d problem. Yes libraries/standard that can stand on their own two feet without X11 for 2d engines in gpus is missing.
      Most hardware from the last 10+ years doesn't have a 2D engine so the usefulness of this on consumer GPUs is pretty limited. Even with X and 2D acceleration, in a lot of cases, with things like damage tracking and shadow framebuffer, just using the CPU is faster than 2D engines. I don't think there is a lot of demand for this in desktop environments which is probably why no one has done much work in this area.

      Comment


      • Originally posted by agd5f View Post
        Most hardware from the last 10+ years doesn't have a 2D engine so the usefulness of this on consumer GPUs is pretty limited. Even with X and 2D acceleration, in a lot of cases, with things like damage tracking and shadow framebuffer, just using the CPU is faster than 2D engines. I don't think there is a lot of demand for this in desktop environments which is probably why no one has done much work in this area.
        This change does not start 10 years ago. This problem starts before Linux. Linux framebuffer (fbdev) right back at early Linux could not use the 2D engine on graphics cards. We are talking 30 years back.

        Think about it you are writing a program that cross platform. You want to use the GPU to accelerate the 2d stuff. Opengl in the late 90s is everywhere. So you end up using the 3d engine in the GPU because that cross platform. Lack of a standard to use GPU 2d accelerators results in them being platform dependant. Under Linux very platform dependant because you must use X11 server or not be able to use them.

        Now limit users because of no standard results no reason to develop 2d engines to be high performance.

        This has fairly much been self filling prophecy. No one wants to work on the 2d engine now because there are no users and their are no users because there was no standard interface to use the 2d engine that was in fact cross platform and in fact supported all the different output options.

        There are still different embedded arm soc gpu with 2d engines that are quite good performance but we don't use them as Linux users still the same problem.

        Yes glamor went to the effort of using opengl to run 2d acceleration when used by DDX. There are quite a few X11 programs that still use this. But when you port those programs to wayland you have to covert that to something else so losing the common 2d acceleration interface location.

        This is change that happening due to a pure lack of cross platform standard for 2d acceleration. The writing was on the wall over this problem at least 2 decades.

        I would say at this point the boat has possible sailed for good on 2d engines but we have got to this point purely because of lack of 2d cross platform standard we had opengl in 3d. Opengl and its cross platform nature has been the hammer driving the nails in to kill the 2d engine off in GPUs. Things could have been way different if at the same item opengl appears a proper cross platform 2d engine access library appeared. Yes serous-ally we might have high performance 2d engine in our GPU with the 3d engine due to the massive number of users of the 2d engine.

        The death of 2d acceleration in GPU was written in the 90s well before wayland. Yes ATi and other into the early 2000s attempted to keep 2d acceleration alive while completely missing what was leading to 2d engine usage death..

        Comment


        • Prior to OpenGL, you didn't really have any standard drawing APIs. There was X and GDI for windows. Both of which were accelerated by their respective environments so there was no real need for a cross OS API. OpenGL finally came along and could do everything you could do on a 3D engine and more. At that point, why do we need a 2D API? Modern desktops (i.e., desktops from the last 15 years) want things like alpha blending and coordinate transforms. By the time you add all of that to a 2D API, it can't be accelerated by most 2D engines or the 2D engine becomes 90% of a 3D engine and why waste the die area? If all you can do is blits and fills in hardware, it will always be faster to just use the CPU if you need anything else (alpha blending, transforms, etc.). Having to ping pong between CPU and GPU access kills performance.

          Comment


          • Originally posted by agd5f View Post
            Prior to OpenGL, you didn't really have any standard drawing APIs. There was X and GDI for windows. Both of which were accelerated by their respective environments so there was no real need for a cross OS API. OpenGL finally came along and could do everything you could do on a 3D engine and more. At that point, why do we need a 2D API? Modern desktops (i.e., desktops from the last 15 years) want things like alpha blending and coordinate transforms. By the time you add all of that to a 2D API, it can't be accelerated by most 2D engines or the 2D engine becomes 90% of a 3D engine and why waste the die area? If all you can do is blits and fills in hardware, it will always be faster to just use the CPU if you need anything else (alpha blending, transforms, etc.).
            Opengl is 1992 when released that back 29 years We have Microsoft starting to direct X their desktop before the year 1998..

            https://en.wikipedia.org/wiki/Xgl
            Yes X11 server starting to appear in Opengl backend form in 15 years ago in 2006. glamor that modern is only from 2011.

            The no real need for a cross OS APi for 2d ignores when directfb appears
            https://tech.slashdot.org/story/01/1...phics-standard
            yes 2001 and ywindows before that. This is also ingoring items like beos and os/2 warp.... So there was a lot more than X and GDI for a time frame. Of course gpu vendors basically for a long time decided winners by not providing support.

            The reality is there was a need for a cross platform 2d acceleration API.

            Originally posted by agd5f View Post
            Having to ping pong between CPU and GPU access kills performance.
            Even this is not counter to having a 2D API. Yes back in the before 2005 having generic 2D API for hardware 2d engine did make sense CPU were not that powerful so the gain in performance of the 2d engine could out do ping pong overhead. But today even having a generic 2D API that is software rendered by CPU or converted to opengl like glamor is does make some sense other than the fact we don't have one.

            There are still cases with different embedded soc chips where the 2d engine still make sense due to how much more performance the 2d engine has compared to the cpu core those cases the ping pong cost is cheaper than the performance gain.

            Think about it with something like libglvnd you could have 2D APi that used CPU when you have a GPU without a 3D engine and when there is a 3D engine do a glamor process. When only wanting to perform 2d operations having to software emulate 3d operations you do have some overhead.

            It made sense to create a cross platform 2D API when opengl started but no one did. This has lead to the location where we have everything by 3D API even when it does not make perfect sense todo that. Like when using a output that does not have a 3D engine.

            Comment


            • Originally posted by endlesseden View Post

              Crazy enough i was thinking the same thing... I maintain a collection of retro machines for a small computer club and my family. Documenting the history and enjoyment of not only the software but the hardware. | All the WinXP and earlier machines i have linux distro + (windows) installed to ensure that i can deploy updates, etc. efficiently without risking security issues. | i also use them for retro lan-parties, which means running linux and using wine or native linux games, because its plain stupid to risk it otherwise when some games DRM's require internet access..

              I dont know how or if this will affect any of these machines, but it worries me that mesa will just abandon the branch and not push any security updates allowing these old unpatched games to fall victim as vectors of attack on otherwise safe but old machines...
              There are some emulation options that are becoming very useful. Dosbox has been around for a long time but it has it's limitations. I've had much success and lots of using https://github.com/86Box/86Box recently. I still have some games that doesn't run well in Dosbox but needs a 16bit runtime. Windows 95 and some of my games worked well with 86Box.

              I ran it on my Linux Host 2700X -> Windows VFIO VM Rx480 -> 86Box 2.07 + 86BoxManager 1.7.2 -> Pentium 75Mhz & Diamond Stealth 64 -> Windows 95 -> 16bit retro games

              I'm not sure how well it works on Linux though... see https://news.ycombinator.com/item?id=26526795 This is the guide that I used: https://www.youtube.com/watch?v=PgMKUezEEqk but the project is in active development so it might be different in the new versions.

              Games like Age of Empires II, Red Alert 2 and Unreal Tournament will run. How legal is it? Not sure. Naturally I own Windows and the games that I play but I don't know about the firmware. I'm sure it's different for every country. Finally security... well since it's emulating hardware and using the original drivers... I'm sure there's a lot of exploits for these systems. With regards to DRM, I try to support GOG as much as I can. Newer games like Warcraft 3 might need better GPU support IIRC someone is working on getting ATI Rage emulation working but who knows maybe it still works with Voodoo 3 emulation? One needs to test it.

              PS: https://86box.net/2021/12/01/86box-v3-0.html

              Comment


              • Originally posted by Jabberwocky View Post
                There are some emulation options that are becoming very useful. Dosbox has been around for a long time but it has it's limitations. I've had much success and lots of using https://github.com/86Box/86Box recently. I still have some games that doesn't run well in Dosbox but needs a 16bit runtime. Windows 95 and some of my games worked well with 86Box.
                I am sorry I am forced to question this.
                https://emulation.gametechwiki.com/index.php/Intel_CPUs
                There are two programs that have the name dosbox in the emulation space.
                https://dosbox-x.com/ people commonly don't try because it commonly not packaged with distributions.
                https://flathub.org/apps/details/com.dosbox_x.DOSBox-X

                Yes it flatpak install

                Yes dosbox-x supports all versions of Windows 95 where dosbox without the X is windows 95 version picky.

                The two programs with the name dosbox really do cause some serous issues when people say they got x to work in dosbox and you try it in dosbox and it does not work only to find out the person was really using dosbox-x and left the x off.



                Comment


                • Clearly everybody has forgotten GGI! ;-)

                  Comment

                  Working...
                  X