R600 Gallium3D To End Code Sharing With RadeonSI Driver

[phoronix]

Phoronix: R600 Gallium3D To End Code Sharing With RadeonSI Driver

While the R600g and RadeonSI drivers are two distinct Gallium3D drivers for R600 (HD 2000) through Northern Islands (HD 6000) and GCN and newer, respectively, they have up until now shared some code via gallium/radeon. But that will now be ending...

http://www.phoronix.com/scan.php?page=news_item&px=R600-Ending-Radeon-Gallium

[eydee]

New mining code not compatible with non-mining architectures, splitting is necessary to make linux the One Big Mining Platform of all times.

[L_A_G]

New mining code not compatible with non-mining architectures, splitting is necessary to make linux the One Big Mining Platform of all times.

With the GPU mining craze set to end by early next year simply due to upcoming difficulty increases making it unprofitable that's just stupid...

The reason for this is pretty obvious when you think about it. Maintaining code for loads more hardware is obviously loads more work (loads more hardware to test on and loads more chances for bugs) and the more hardware you have to maintain your codebase for, the more you're going to be constrained in terms of optimizations.

Some people are going to freak out over this, but I'd say AMD has maintained the R600 codebase for long enough that they can in good conscience leave any further maintenance and development of it up to the rest of the Gallium3D development community.

[Serafean]

As a heavy user of r600g admitting that the platform is way past its prime, if this reduces the risk of regressions, then it is welcome.

[yoshi314]

maintenance wise, this makes sense. this sort of explains why nvidia has so many driver branches. but it doesn't explain why are they so lazy updating the oldest of them.

[shmerl]

So what will happen to R600_TEX_ANISO variable that's now used to force anisotropic filtering for both radeonsi and r600? Will there be a separate one for radeonsi? It's very useful in older games in Wine.

[schmidtbag]

maintenance wise, this makes sense. this sort of explains why nvidia has so many driver branches. but it doesn't explain why are they so lazy updating the oldest of them.

I was thinking the opposite. I would argue one of the reasons to go for Nvidia is because of how well they maintain outdated hardware. Nvidia (to my recollection) only seems to have 3 driver branches going all the way back to the GeForce 6000 series. Basically, they've got drivers for DX9 hardware, DX10 hardware, and Vulkan-compatible hardware. Sure, whatever isn't modern isn't updated as frequently, but I personally am glad they do anything at all. AMD's closed drivers pretty much never update anything that isn't from the current family (which right now is GCN), and Intel (regardless of platform) tends to neglect anything that isn't the very newest.

I'm sure AMD's open-source efforts would put more effort into R600 if they had the resources to do so, but it is understandably a low priority. Sadly, by the time they could really devote attention to it, nobody will be using that hardware anymore.

[karolherbst]

I was thinking the opposite. I would argue one of the reasons to go for Nvidia is because of how well they maintain outdated hardware. Nvidia (to my recollection) only seems to have 3 driver branches going all the way back to the GeForce 6000 series. Basically, they've got drivers for DX9 hardware, DX10 hardware, and Vulkan-compatible hardware. Sure, whatever isn't modern isn't updated as frequently, but I personally am glad they do anything at all. AMD's closed drivers pretty much never update anything that isn't from the current family (which right now is GCN), and Intel (regardless of platform) tends to neglect anything that isn't the very newest.

I'm sure AMD's open-source efforts would put more effort into R600 if they had the resources to do so, but it is understandably a low priority. Sadly, by the time they could really devote attention to it, nobody will be using that hardware anymore.

Well, depending on the driver architecture it is more or less difficult to not regress old hardware. And I assume the Nvidia architecture to be very modular. And with Nouveau we also follow a similar approach and at least on the kernel side we always have the possibility to restrict a change to a certain chipset without needing to rewrite core parts of the driver, because we support this by design.

[boffo]

I hope this will stop regressions.

[RussianNeuroMancer]

Someone please fix this

https://bugs.freedesktop.org/show_bug.cgi?id=100953