The Experimental GCN 1.0 GPU Support Might Be Dropped From AMDGPU Linux Driver

[torbido]

Thanks for taking time to answer my questions. You have been so helpful bridgman . I am sorry, but I have more question that confuses me the most when it comes to Linux, and I hope that you can help me with them if you don't mind.

On Linux I have to use DRI_PRIME=1 to be able to switch to my AMD GPU, while on Windows I only open the game, and the driver switches automatically to the external GPU, and make a profile about this game in AMD driver settings. I don't know if WINE makes that a little harder to do, because there are WINE application, and native applications, but I think a tool for this specific reason will be one of the most wanted features on Linux, and a big step to make it user friendly.

Also, if someone decided to do a tool to switch automatically between iGPU, and dGPU, would AMD share their applications database with him/her? And how it can be done theoretically?

[pal666]

I'd rather leave it experimental for eternity than drop it at all. As said, Vulkan beats UVD.

not really. without uvd you can't watch youtube if your cpu is not high end. and if it is high end, then you don't have gcn 1.0 videocard and you have no such problem. old videocard is enough to watch youtube or play old games

[pal666]

This makes me question my tentative plans to buy AMD when my GeForce GTX750 dies.

lol, how does nvidia upstream kernel support go? basically in one line you've shown all stupidity of nvidiots

[bridgman]

My (unconfirmed) understanding is that DRI_PRIME can already be set on a per-application basis using the drirc file:

https://lists.freedesktop.org/archives/mesa-dev/2014-May/060131.html

Don't think driconf includes GUI support for that but it seems like it would be fairly easy to add.

I'm not sure how useful our Windows application database would be for Linux, since both the driver and the apps are fairly different.

[ssokolow]

lol, how does nvidia upstream kernel support go? basically in one line you've shown all stupidity of nvidiots

Doesn't really matter to me because Canonical does a great job of ensuring things Just Work™ so I can get on with being productive.

I started using nVidia cards around 2003 for TwinView which, at the time, was significantly more performant than Xinerama, and I can count the problems I encountered on one hand:

1. Back around 2009, I had to switch to a non-default driver version to fix a crash... and I think I might still have been on Gentoo at that point.
2. In two instances between 2010 and 2015, I had to opt for a newer/older driver version to fix a memory leak until an update was pushed for the default version. In both cases, it wouldn't have been a problem except that I leave my desktop running and logged in for months at a time.
3. I had to write a hack using apt pinning and an init script so that my drivers only get updated on reboot so the GL libraries can't get updated to a newer version than the loaded kernel module and break acceleration until I end my session and reload the kernel module.
4. When I bought the GTX750, I had to enable a PPA to get a compatible driver because I run LTS releases of Lubuntu or Kubuntu.

I'd say that's pretty damn good for over a decade and a half spanning back before things like KMS, XRandR 1.2, and glvnd.

When I bought my current card, fglrx was still the official driver for Radeon cards and was a significantly worse alternative to nVidia's binary drivers. If I buy an nVidia card next time, it'll be because it's a known quantity with 16+ years of reliable use to vouch for it.

[torbido]

My (unconfirmed) understanding is that DRI_PRIME can already be set on a per-application basis using the drirc file:

https://lists.freedesktop.org/archiv...ay/060131.html

Don't think driconf includes GUI support for that but it seems like it would be fairly easy to add.

There is an attempt to make a GUI for driconf >>> https://github.com/jlHertel/adriconf
Could you take a look at it?

I'm not sure how useful our Windows application database would be for Linux, since both the driver and the apps are fairly different.

It will be useful for games running through WINE if there is a way to add this option after adding support for native applications first.

[enigmaxg2]

Now, when we have RDNA, they should drop GCN completely, not just 1.0 Why waste time on legacy architecture?

Because all these millions of cards already sold (and some, still being available to buy) automagically will turn into RDNA's right?

[bridgman]

There is an attempt to make a GUI for driconf >>> https://github.com/jlHertel/adriconf
Could you take a look at it?

For clarity, driconf is the GUI for the drirc file(s) and is what all the distros include today AFAIK... it's just that driconf does not seem to include support for setting DRI_PRIME yet. The adriconf project is creating an alternative GUI.

It will be useful for games running through WINE if there is a way to add this option after adding support for native applications first.

Not so much... the database contains options for our Windows DirectX drivers, while WINE translates DirectX calls into OpenGL calls and then runs them on a different driver. Different driver = different quirks/bugs/performance unfortunately.

[bridgman]

Shame on AMD. Video decoding was created ages ago by a community member, all they need is to provide a firmware with proper headers.

Right, "all" we need to do is create a magic microcode image that makes make GCN1 hardware behave like a newer GPU when the microcode store is already 100% full. Nothing to do with headers.

Reading such news I don't see so much difference between AMD and Nvidia. Both require blobs. Both don't have FLOSS hardware.

Fixed that for you. We have FLOSS drivers, but the hardware requires microcode (like every GPU on the market) which we happen to load into RAM rather than burning into ROM.

[Soul_keeper]

I'd be running my 7870 as a secondary opencl device to my vega card if they were both supported by amdgpu/rocm.
We literally never got opencl support fully implemented for gcn outside of fglrx and a half effort for 1.0 with mesa that seems to have been abandoned in favor of rocm. It's a shame because GCN was so revolutionary from a compute perspective, and still has massive GFLOPs compared to CPUs