David Airlie Continues With Holiday Improvements For R600g

[DanL]

While i can apprciate the effort i have to wonder if such talent would be better used to support newer hardware? Sometimes you just need to let go of old tech.

If you don't add features to older hardware that supports them, you will be accused of prematurely abandoning support for your hardware. An Intel dev (IIRC) had a good post about that here on Phoronix after he added a feature that folks had been asking for to an older Intel GPU, and then someone complained he should have spent the time on newer hardware.

[monte84]

Yep, War Thunder cause GPU hang On Mesa 17.3 right now.

And before that it was a graphical glitch fest. Unless you like the bright neon textures everywhere.

[schmidtbag]

If you don't add features to older hardware that supports them, you will be accused of prematurely abandoning support for your hardware. An Intel dev (IIRC) had a good post about that here on Phoronix after he added a feature that folks had been asking for to an older Intel GPU, and then someone complained he should have spent the time on newer hardware.

That sounds vaguely familiar, but I can't say that scenario is fully analogous to this, for a couple reasons:
1. Arlie is doing this simply because he can and wants to. He has absolutely no obligation to do this, and to my knowledge he isn't an AMD dev. Intel, meanwhile, has some degree of an obligation to support their own old products. When it comes to outdated products, you could argue "it is unrealistic to maintain several years worth of products" but as a counter-argument, you could say "the product was lacking complete functionality before it was obsoleted, and the consumer never got what they paid for".
2. I'm not sure how old the Intel chipset in question was, but Intel does have an annoying tendency to prematurely abandon support for things that are just a couple years old. If it was a chipset before the Core i# days, then yeah, maybe development should've been discontinued - those chipsets were so bad that they still tarnish Intel's reputation for graphics to this day.
But otherwise, I do see your point. It's hard to find the right balance between justifying development and premature abandonment. The way I see it, if the hardware is still capable of handling modern tasks smoothly, it is worth developing for.

[chithanh]

Hopefully all the bits will soon be in place so the missing soft-FP64 can be switched on for all the non-HW-native-FP64 chips.

Soft-fp64 is what i want for my current card. I'll probably buy a newer when vp9 stuff land.

Which exact software do you use that depends on hardware fp64?

[timofonic]

I just wonder if this driver can be merged with the newest driver (AMDGPU?). And if possible: What are the showstoppers to do it?

schmidtbag It's okay, airlied is a Red Hat employee. But does AMD pays Red Hat for working in AMD drivers? How's the chain of responsabilities in the AMD driver development?

[Michael]

I just wonder if this driver can be merged with the newest driver (AMDGPU?). And if possible: What are the showstoppers to do it?

First of all, this is R600g Gallium3D driver in Mesa. AMDGPU is the DRM kernel driver for GCN 1.2+ and experimentally for GCN 1.0~1.1.

But if you mean RadeonSI, no, they are vastly different GPU architectures with GCN and no real benefit, plus a lot of work would be involved even it was possible... It would just clutter RadeonSI code-base and bloat it up If you mean pre-GCN support for the AMDGPU DRM driver, there is no code written, the GPU architecture is very different, and not really worthwhile for all of the work involved, etc.

[timofonic]

First of all, this is R600g Gallium3D driver in Mesa. AMDGPU is the DRM kernel driver for GCN 1.2+ and experimentally for GCN 1.0~1.1.

But if you mean RadeonSI, no, they are vastly different GPU architectures with GCN and no real benefit, plus a lot of work would be involved even it was possible... It would just clutter RadeonSI code-base and bloat it up If you mean pre-GCN support for the AMDGPU DRM driver, there is no code written, the GPU architecture is very different, and not really worthwhile for all of the work involved, etc.

Oh, sorry. I wasn't aware about the drivers being developed for different GPU architectures. Thanks a lot for your explanation!

I did a quick read and it seems this is the ecosystem of drivers for AMD/ATI GPUs. Am I right?

R600g - R600, Evergreen.
RadeonSI - Northern Islands, Southern Islands, Sea Islands.
AMDGPU - GCN 1.2, experimental 1.0~1.1. I suppose the following are part of GCN, as are mentioned to have somewhat compatibility degree with it (Gentoo wiki, Archlinux wiki): Southern Islands, Sea Islands, Volcanic Islands, Arctic Islands.

So will RadeonSI only support Northern Islands in the future and the newer ones will go to AMDGPU?

I'm not sure about AMDGPU support of certain generations, as there seems to be some contradicting information out there.

[Michael]

Oh, sorry. I wasn't aware about the drivers being developed for different GPU architectures. Thanks a lot for your explanation!

I did a quick read and it seems this is the ecosystem of drivers for AMD/ATI GPUs. Am I right?

R600g - R600, Evergreen.
RadeonSI - Northern Islands, Southern Islands, Sea Islands.
AMDGPU - GCN 1.2, experimental 1.0~1.1. I suppose the following are part of GCN, as are mentioned to have somewhat compatibility degree with it (Gentoo wiki, Archlinux wiki): Southern Islands, Sea Islands, Volcanic Islands, Arctic Islands.

So will RadeonSI only support Northern Islands in the future and the newer ones will go to AMDGPU?

I'm not sure about AMDGPU support of certain generations, as there seems to be some contradicting information out there.

RadeonSI is used by ALL GCN 1.0 and newer graphics cards. RadeonSI is the OpenGL driver.

AMDGPU is the kernel driver used by all GCN 1.2+ GPUs. Radeon DRM meanwhile is the default DRM driver for pre-GCN-1.2 graphics cards.

You need Radeon/AMDGPU + RadeonSI for a working system, RadeonSI (or R600g) is just the OpenGL component, not the DRM driver that does mode-setting, memory management, and everything else.

[timofonic]

RadeonSI is used by ALL GCN 1.0 and newer graphics cards. RadeonSI is the OpenGL driver.

AMDGPU is the kernel driver used by all GCN 1.2+ GPUs. Radeon DRM meanwhile is the default DRM driver for pre-GCN-1.2 graphics cards.

You need Radeon/AMDGPU + RadeonSI for a working system, RadeonSI (or R600g) is just the OpenGL component, not the DRM driver that does mode-setting, memory management, and everything else.

Thanks again! So many time not following AMD hardware made me get very confused. I wonder if Radeon DRM will slim down as support for ealier GCN GPUs get implemented in AMDGPU?

[gerddie]

R600g - R600, Evergreen.
RadeonSI - Northern Islands, Southern Islands, Sea Islands.

R600g includes also Northern Islands (specifically HD 6xxx), see https://www.x.org/wiki/RadeonFeature/