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

[torbido]

Huh ? If you are using Mesa then you *are* using the official drivers (ignoring Vulkan for a moment).

When you say "official" are you thinking about the packaged drivers ? They use the same open source driver code as upstream for non-PRO, and the PRO option (for workstation aka RadeonPRO) replaces the 3D drivers with closed source OpenGL and Vulkan code.

The radeonsi driver supports everything from SI through Navi - are you talking about an SI (GFX6) GPU ? If so then it is supported by the packaged drivers even today.

2015... maybe you are talking about fglrx ? If so then we replaced that with the amdgpu/amdgpu-pro package... it wasn't just dropped for older parts.

The point you may be missing is that we replaced fglrx with an upstream-based driver, where AMD developers continue to be the primary developers of the upstream code, and we added the fglrx kernel/X team to the upstream effort as well.

No man, I have AMD Radeon HD 8750M, and there are no AMDGPU driver, or AMDGPU-pro driver for this GPU since 2015 when it was called FGLRX.

The only supported GPUs from HD series are: HD7700/7800/8500/8600, and there is no M in their names!

My GPU is supported by AMDVLK, but it only started to work for my GPU from a month ago, and the performance is always worse than RADV, and I can't get any Vulkan game to work, only DXVK games.

[Nille_kungen]

Heck even less capable HD 4000 from IVB era received vulkan support under linux which is nonexistent under windows and still kicking.

Could you please explain this.
I don't think that's true.

[SkyWarrior]

https://www.phoronix.com/scan.php?page=article&item=mesa-12-released

well it is there since mesa 12

[bridgman]

No man, I have AMD Radeon HD 8750M, and there are no AMDGPU driver, or AMDGPU-pro driver for this GPU since 2015 when it was called FGLRX.

The only supported GPUs from HD series are: HD7700/7800/8500/8600, and there is no M in their names!

My GPU is supported by AMDVLK, but it only started to work for my GPU from a month ago, and the performance is always worse than RADV, and I can't get any Vulkan game to work, only DXVK games.

If you are running AMDVLK or RADV then you are also running the amdgpu kernel driver, either from upstream or from one of our packages. Can you take a quick look at your dmesg output and confirm whether your GPU-related messages are coming from amdgpu or from radeon ?

[torbido]

If you are running AMDVLK or RADV then you are also running the amdgpu kernel driver, either from upstream or from one of our packages. Can you take a quick look at your dmesg output and confirm whether your GPU-related messages are coming from amdgpu or from radeon ?

The point of my last comment is that I can't use AMDGPU-pro driver like this driver >>> https://www.amd.com/en/support/kb/re...orad-lin-18-40

The experimental amdgpu kernel driver is always enabled, and radeon is blocked.

Here is the full dmesg output: https://www.mediafire.com/file/ueyri...g.txt.zip/file

[PuckPoltergeist]

The point of my last comment is that I can't use AMDGPU-pro driver like this driver >>> https://www.amd.com/en/support/kb/re...orad-lin-18-40

Why do you want to use it? Shouldn't bring you any benefit.

[bridgman]

The point of my last comment is that I can't use AMDGPU-pro driver like this driver >>> https://www.amd.com/en/support/kb/re...orad-lin-18-40.

OK, that makes sense, but why would you want to run the workstation driver in the first place ? I don't think we ever made a FirePro / RadeonPro version of the 8750M, and the upstream driver has been the primary desktop/gaming driver for a few years now with significantly higher performance and game support.

The experimental amdgpu kernel driver is always enabled, and radeon is blocked.

Just to be clear, the "experimental amdgpu kernel driver" from upstream is identical to the AMDGPU-PRO kernel driver other than (a) a couple of additional IOCTLs to support workstation features (which your chip doesn't have) and (b) DKMS/KCL logic to let the driver package install on a variety of kernel/distro versions.

Other than that it's line-for-line identical... the kernel driver package includes source code if you want to confirm that.

Finally, the -PRO packages should install and run over the upstream kernel if you really want to use them. I wouldn't recommend it for anything other than workstation apps though.

[torbido]

OK, that makes sense, but why would you want to run the workstation driver in the first place ? I don't think we ever made a FirePro / RadeonPro version of the 8750M, and the upstream driver has been the primary desktop/gaming driver for a few years now with significantly higher performance and game support.

What?!! So Mesa is the official driver for AMD?! But why there is AMDVLK when Mesa already has RADV?! And why there is no GUI for Mesa?!

I am more confused that I was before, could you explain, please?

[bridgman]

What?!! So Mesa is the official driver for AMD?!

For OpenGL and video, yes (although the closed source OpenGL is official for RadeonPRO). Vulkan is a bit more complicated.

But why there is AMDVLK when Mesa already has RADV?!

One could ask "why is there RADV when we already had AMD Vulkan" but it's not that simple either. Reality is that they developed in parallel.

We had been shipping our Vulkan driver for quite a while before RADV was ready for use, but cleaning our Vulkan driver up for open source release took a long time and during that time RADV matured and became a solid driver. RADV also has a "public upstream" development model that is tough to duplicate with AMD Vulkan because it leverages code from other OSes and APIs which are less open-source-friendly.

It's easier if we talk about OpenGL and video

And why there is no GUI for Mesa?!

There is no GUI for the closed source drivers either, so that's a bit of an academic question.

That said, the full answer is that we believe that a cross-vendor GUI would be more broadly useful than a vendor-specific GUI, and that we have prioritized getting the right controls into environment variables and sysfs/debugfs mechanisms, but there has been much less community interest in a cross-vendor GUI than we expected, and we need to figure out if it's worth making a vendor-specific GUI even though we don't believe it's the right way to go.

In the meantime we are using driconf and its GUI as a cross-vendor solution for setting and managing 3D driver behavior.

[ermo]

There is no GUI for the closed source drivers either, so that's a bit of an academic question.

That said, the full answer is that we believe that a cross-vendor GUI would be more broadly useful than a vendor-specific GUI, 1./ and that we have prioritized getting the right controls into environment variables and sysfs/debugfs mechanisms, 2./ but there has been much less community interest in a cross-vendor GUI than we expected, and we need to figure out if it's worth making a vendor-specific GUI even though we don't believe it's the right way to go.

In the meantime we are using driconf and its GUI as a cross-vendor solution for setting and managing 3D driver behavior.

(emphasis mine)

Ad 1./:

Good on you and AMD for doing this. FWIW I think it's nice to have a CLI/TUI/GUI agnostic way of tweaking card settings.

Ad 2./:

I think you might have underestimated how lost "the community" is when it comes to the architecture and functioning of the FLOSS graphics driver stack in general.

I also don't think a single cross vendor GUI is necessarily the way to go; for starters, I think a library for managing the same underlying options which each DE can then hook into via their control panel would probably be more useful?

E.g. GNOME Shell, KDE, Xfce, Cinnamon and MATE all have a Display entry in their Settings/Control Panel. Putting on my ordinary user hat, this is where I would expect to be able to control the various knobs for my graphics card(s) (be it intel, AMD or possibly both in the same system), including tweaking per-app rules for iGP or dedicated GPU rendering via RandR.

So yes, pooling resources would be a boon. But doing so by having a common library (possibly as part of Mesa?) and a common/minimal set of knobs dependending on hardware, might be a more useful approach?

The library might even be able to abstract away the kernel specifics such that the BSDs could also use said library with e.g. KDE and Xorg+Mesa?

Just my €0.02 of course.