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

[oiaohm]

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.

[agd5f]

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.

[oiaohm]

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..

[agd5f]

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.

[oiaohm]

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/10/23/1252214/directfb-a-new-linux-graphics-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.

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.

[Jabberwocky]

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

[oiaohm]

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.

[s_j_newbury]

Clearly everybody has forgotten GGI! ;-)

[kenren]

oiaohm
You are writing some information that seems to be wrong, please don't give fake information.
R100/R200 was on laptop, for example I have an Apple G3 ibook with R200 on it. Im 100% sure of it.
As I can see i915g support only third generation, not the second generation, where you have found that support montara and almadore GPU?
also, if I'm not wrong, for write a gallium3d driver you need opengl 2+ hardware, since need shader.
However i915g gallium have poor performance compared to dri driver.

[oiaohm]

oiaohm
You are writing some information that seems to be wrong, please don't give fake information.
R100/R200 was on laptop, for example I have an Apple G3 ibook with R200 on it. Im 100% sure of it.
As I can see i915g support only third generation, not the second generation, where you have found that support montara and almadore GPU?
also, if I'm not wrong, for write a gallium3d driver you need opengl 2+ hardware, since need shader.
However i915g gallium have poor performance compared to dri driver.

Ok that is a powerpc laptop with R200. That interesting. That time frame I was mostly in x86.

i915g gallium driver support intel hardware that does not have a shader. There is a catch here. i915g will expose that it supports opengl 2.x does this by using llvm software rendering.

It can be a good idea to say 1.4 opengl only(MESA_GL_VERSION_OVERRIDE=1.4) on some hardware.
So i915g gallium compared to the old i915 driver you have to be careful. Yes i915 driver is 1.4 only cannot llvm software render 2.x opengl as the i915g can in places.

Yes there are benchmarks done by phoronix on i915 generation hardware without opengl 2+ hardware shader using i915g.

https://www.phoronix.com/review/intel_i915g_default

The benchmark here is i915g on apple and other intel hardware that does not have opengl 2+ hardware. The hardware is only opengl 1.4 but i915g reports to software that it is opengl 2.1 cause is the following:
"This Gallium3D driver is a big win since it's much faster for software emulation of vertex shaders and other OpenGL features by leveraging LLVM to cover the graphics hardware's shortcomings."

So you are wrong gallium3d driver by nature will expose opengl 2.1 not matter what evil it has todo. Including software emulation of whatever is missing. Does galluim3d driver exposing opengl 2.1 mean the hardware under it has to be opengl 2.1 absolutely not. Remember option of LLVM emulation making up the difference here.

Most of the benchmarks really did not put the classic i915 and i915g in a fair fight. Most left the i915g driver not restricted to 1.4 so would software emulation when ever benchmark did different opengl 2.1 thing so was of course slow. There have been some fixes with the change of i915g to NIR that have reduced the overhead of the software emulation.

Software emulation does have price.

kenren its really simple to forgot you can do opengl shaders using the CPU and is a feature of the i915g driver. Using the CPU the GPU does not have to have the feature.