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

[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

[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 ?

[SkyWarrior]

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

well it is there since mesa 12

[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.

[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.

[agd5f]

If you were me, who would you approach about such a "lift"?

I'd be willing to attempt to do some of the monkey work if I had access to a (set of) mesa/RADV developer(s) who would be willing to guide and mentor me. The goal would only be to make it more interesting/worthwhile for proper mesa devs to finish off the tricky/fun bits.

I'd also caution that I'd be asking a lot of stupid questions since I'm basically woefully underqualified for this kind of work; but giving it an honest try is at least better than the status quo.

And if anyone else is following along: I'm just some random guy on the internet wondering how to approach this and get the ball rolling.

Developers are regularly on #radeon and #dri-devel on freenode IRC. Start with radeonsi and take a look at the radeon and amdgpu winsys backends and get familiar with them. Use them as a reference to implement the relevant support in radv.

[ermo]

Yes.
(...)
in my opinion, tweaking some things around the edged to make the ioctls work for vulkan is a much smaller lift than porting the entire driver init sequence over to amdgpu and then making it stable (e.g., clocking, suspend/resume, etc.) on a wide variety of hardware.

If you were me, who would you approach about such a "lift"?

I'd be willing to attempt to do some of the monkey work if I had access to a (set of) mesa/RADV developer(s) who would be willing to guide and mentor me. The goal would only be to make it more interesting/worthwhile for proper mesa devs to finish off the tricky/fun bits.

I'd also caution that I'd be asking a lot of stupid questions since I'm basically woefully underqualified for this kind of work; but giving it an honest try is at least better than the status quo.

And if anyone else is following along: I'm just some random guy on the internet wondering how to approach this and get the ball rolling.

[agd5f]

I guess that answers my question, thanks.

Yes. The kernel driver handles the majority of the interactions with the hardware (interrupts, displays, power management, engine init, etc.). Getting all of that ported over and stable and tested on a wide variety of hardware is a huge amount of work. In the case of mesa, the user mode driver is building state packets which will be the same regardless of the underlying kernel driver (e.g., radeonsi does this already). The winsys is just a wrapper around the ioctl interfaces provided by each driver. The ioctls are pretty similar since amdgpu evolved from radeon. That's not to say it's trivial. amdgpu has a number of changes to the ioctl interface that make it easier to implement vulkan support. That said, in my opinion, tweaking some things around the edged to make the ioctls work for vulkan is a much smaller lift than porting the entire driver init sequence over to amdgpu and then making it stable (e.g., clocking, suspend/resume, etc.) on a wide variety of hardware.

[agd5f]

But amdgpu+amdkfd works on CI parts, while radeon+amdkfd doesn't. Or was that comment about radeon being fully featured specific to SI?

Specific to SI.

[chithanh]

amdkfd has never supported SI parts. SI lacks the necessary hardware (user mode queues) to support KFD/ROCm.

But amdgpu+amdkfd works on CI parts, while radeon+amdkfd doesn't. Or was that comment about radeon being fully featured specific to SI?