AMD Developers Discuss Better Switching Of Radeon/AMDGPU CIK Support

[RussianNeuroMancer]

Which one is the right source for DAL version of AMDGPU?

https://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-4.12

https://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-4.12-wip

Is there pre-build packages or PPA?

[Veerappan]

Since Ubuntu started to activate CiK for AMDGPU for their kernels (17.04 & mainline ppa) I've had no major problems switching between them. The only thing needed is adding modprobe.blacklist=radeon to the kernel line.

The downside to that is: What do you do if you want amdgpu for radv, and you still want/need to use a pre-GCN card for something? By blacklisting the Radeon driver, you've prevented that other card from working. A mechanism to choose the default driver for SI/CI cards would fix that situation.

[bridgman]

Which one is the right source for DAL version of AMDGPU?

https://cgit.freedesktop.org/~agd5f/...=drm-next-4.12
https://cgit.freedesktop.org/~agd5f/...-next-4.12-wip

Is there pre-build packages or PPA?

Both of those are based on Dave's drm-next, so no DAL code yet. What you want is the latest amd-staging-* branch, currently:

https://cgit.freedesktop.org/~agd5f/...md-staging-4.9

Check for presence of the /drivers/gpu/drm/amd/display folder.

[starshipeleven]

This is a problem.

Linux should have a general way in which to handle multiple drivers for same hardware elegantly.
(not just for this AMD hardware, not just graphics drivers, but for all kinds of hardware in general)
Kernel and drivers should be structured in such a way the administrator of the system can express a preference for which driver to use.
This should also be worked out in a flexible way.
Allowing administrators to specify hardware preferences on a per-application basis and which one to use if application preferences clash.
Linux should get a general way of dealing with such a driver situation. This is not the only case of drivers having overlapping hardware support.
Linux architecture, APIs and drivers should be made to handle driver switching at runtime.

??? you can load or unload drivers at runtime, and even blacklist them so they NEVER EVER get loaded, period.

Having a driver for each application is not really possible because most drivers need exclusive access to hardware (in any OS).

What would be cool is a way to get drivers to work on some hardware and not on others (like blacklist but by PCI ids or something), like said above, you decide that driver X will run on device 1 and 2, but not on device 3 because you want that to be run by another driver. And devices 1, 2 and 3 are identical.

[mitch074]

I was surprised last Saturday how far GCN 1.0 support has come in amdgpu (mainline kernel 4.11.rc5 + Padoka PPA) : I could run Tomb Raider (in Ultra including TressFX), Bioshock and Mad Max (MesaGL and radv) on a RadeonHD 7770 1Gb GHz edition, and the only problem I had was a purple line on the left of the screen; the system completed several benchmark runs without any crash or whatever. Now, maybe I have the exact same model of card that's used to test said backporting of SI support in amdgpu, but the added support for Vulkan is welcome.
Now, if DAL could land so that I don't lose sound over HDMI when leaving radeon behind, and if that pesky purple line could be gone, then a GUI tool to select which module to load would be most welcome - I'm getting lazy in my old age.

[Mez']

Well, first and foremost, before even thinking about a switch, SI/CIK should be exposed by default in most distribution kernels and mainline. I know Ubuntu 17.04 is around the corner and has enabled the kernel parameter, butI Don't think it is yet in most other distributions' kernels. And it is too much of a hassle in 2017 to recompile your kernel every time with a customized config.

Then, we can care about switching from radeon to amdgpu... But it is quite simple anyway, it is just a matter of adding or removing kernel options to grub : modprobe blacklist = radeon and amdgpu exp hw support = 1

[RussianNeuroMancer]

Both of those are based on Dave's drm-next, so no DAL code yet. What you want is the latest amd-staging-* branch, currently:

https://cgit.freedesktop.org/~agd5f/...md-staging-4.9

Check for presence of the /drivers/gpu/drm/amd/display folder.

Thanks! Any ETA for updating this to anything above 4.10.0? (Just because kernel with version above 4.10.0 will boot by default on Kubuntu 17.04, instead of kernel from repository.)

[pixo]

The downside to that is: What do you do if you want amdgpu for radv, and you still want/need to use a pre-GCN card for something? By blacklisting the Radeon driver, you've prevented that other card from working. A mechanism to choose the default driver for SI/CI cards would fix that situation.

Thre is a more elegant solution that I use.
Create /etc/modprobe.d/amdgpu.conf with following line:

install radeon /sbin/modprobe amdgpu; /sbin/modprobe -i radeon

Regenerate your iniftramfs and you are done.
This is only usable if both drivers are compiled as module and may need to be modified for your distribution.

[plonoma]

How can having multiple drivers for the same hardware be elegant at all? Linux has that feature, just don't build drivers at all And then plugin to it whatever drivers separatly you want

Who will maintain out of tree drivers for you i don't know but it is possbile that some distro can do it at least on paper

I mean handling having multiple drivers for the same hardware in an elegant way.
Not building drivers sometimes is just not good enough.
Not making multiple drivers for the same hardware happen.
What if due to the way drivers and hardware is structured you have two drivers with mostly different functionality but a small overlap in hardware support?
This happens and needs to be handled elegantly.
Your propositions do not address the problem.

What if I am using multiple graphics cards? And I want to assign specific applications to specific cards with specific drivers.
And testing applications for different drivers without a lengthy configuration process.
Then I can really benefit from the drivers to both be running and getting along.

[plonoma]

??? you can load or unload drivers at runtime, and even blacklist them so they NEVER EVER get loaded, period.

Having a driver for each application is not really possible because most drivers need exclusive access to hardware (in any OS).

What would be cool is a way to get drivers to work on some hardware and not on others (like blacklist but by PCI ids or something), like said above, you decide that driver X will run on device 1 and 2, but not on device 3 because you want that to be run by another driver. And devices 1, 2 and 3 are identical.

If you can load or unload drivers at runtime then it is possible to switch drivers at runtime.
I meant handling a device off to different drivers depending on which applications are started.
Which still means at any point in time only one driver is getting exclusive access to hardware.
Then it's possible to having per-application driver preferences.
Slightly more streamlined than having to specify load and unload drivers for benchmarking.
Just specify use this application with a specific driver or prefer a driver over another and we get a very elegant way to specify benchmarking for hardware. The phoronix test suite of course provides some abstraction, thus handles this already.
I rather work with a preferred list for hardware PCI ids instead of blacklist.
Having drivers load depending on PCI id preferences seems a good feature to me.