News Linux Community Finally Fixes 20 Year Old AMD GPU Bug

linuxdude

Distinguished
Sep 1, 2015
33
19
18,535
What a poorly researched article - sounds like someone without any clue what is going on copied from phoronix and tried to re-write a bit to not get caught.
 
  • Like
Reactions: domih
It does not appear that this is accurate. What was the bug? Aaron's article doesn't say.

Isn't this a performance optimization utilizing the newer NIR and not a bug fix?
Reading the commit comments, it's not fixing the bug - it's compensating for a Wine D3D to OpenGL bug that goes over the Direct3D specification and then sometimes exceeds hardware capabilities (shader length longer than specc'ed). And it's not 20 years old, it dates back to 2013 : https://bugs.freedesktop.org/show_bug.cgi?id=70009
Note that Ati/AMD hardware between 2007 and 2013 changed drivers several times due to shenanigans at AMD following the merge with Ati, and some disputes between free software developers - essentially you had one driver that hit the hardware registers directly, others that would go through the hardware's firmware that provided an abstraction layer, and the proprietary one (that was undergoing its first ground-up rewrite).

The goal of this "new" work is not to develop a new driver, but to reduce maintenance cost by migrating the older Ati R300->R500 driver to a newer shader processing backend that's also used by other Mesa drivers (such as AMD R600, the newer Intel drivers etc.), in line with Mesa's decision to fork out several very old drivers that couldn't be integrated into the current Gallium3D's architecture : most were drivers that didn't even support 3D acceleration, in short if they didn't support shader compilation they were out. R300 made the cut because it is, actually, the oldest driver that supports shader compilation - but like any old code, it has its cruft, like its specific shaders backend.
It just happens that this new backend gives better performance and is easier to debug, exposing the EXISTING WineD3D bug and thus allowing the workaround to be developed - as such the developers are rather excited about it.
This is why there is so much activity on it, as it's the "perfect" bug : reduce overall code base, improve performance and stability and the cherry on top, testing for it allows one to dig out old hardware to play around with it some more.
 

domih

Reputable
Jan 31, 2020
205
183
4,760
Good for those who still use these cards nowadays.

Yes, that's one advantage of OSS. "Obsolete" hardware may get a 2nd, 3rd... life if someone, somewhere wants to write/update the driver(s) for it for whatever reason. The logic here is totally foreign to commercial support logic.

Old graphics cards can also be useful for low cost SOHO/start-up servers (using off the shelf consumer hardware vs. actual server hardware) where graphical performance is not a factor. Usually you administrate such a server via SSH or a Web GUI but if necessary or for convenience a local GUI can be useful by adding an antique graphics card that is good enough for such purpose.
 

domih

Reputable
Jan 31, 2020
205
183
4,760
What a poorly researched article - sounds like someone without any clue what is going on copied from phoronix and tried to re-write a bit to not get caught.

LOL, but give them a Nth chance for the next 36 months :)

Compared to a not so remote past, they are now actually reading Phoronix (for Linux) and cnx-software (for SBC). For SBC, they have quasi stopped to write "Raspberry-like" or "Raspberry competitor" in the title when talking about a new single board computer. It's a huge improvement...