Radeon's Open-Source Linux GPU Driver Has Nearly Caught Up With Windows' Driver

[nightmarex]

AMDGPU is a kernel driver so it won't implement Vulkan. RADV is the Mesa implementation of Vulkan for GPUs that use AMDGPU and the (currently) closed source implementation that agd5f talked about also uses AMDGPU and is part of that AMDGPU-PRO package.

amdgpu is also a name of Xorg driver (DDX) which also won't implement Vulkan, because it's only doing 2D acceleration and only when running Xorg.

There are three (or four) parts in Linux graphics stack:

• Kernel driver (like radeon, AMDGPU, i915, nouveau), which handles e.g. display stuff and audio.
• DDX, which is Xorg 2D driver (not used with Wayland) this is in user space.
• User space drivers for OpenGL (like r600, radeonsi, i915, i965, nvc0) and Vulkan (RADV, ANV) typically from Mesa.

You need a compatible combination of these to have a working graphics stack. AMDGPU-PRO replaces the OpenGL and Vulkan drivers with closed source drivers, but keeps the kernel driver (AMDGPU) and DDX (also called amdgpu) although it currently adds some patches on top of it, but those are open source too.

yeah, thanks, I know all that, buuuut he said "Vulkan support is available via the packaged releases until it's open sourced." yeah so... IDK where you guys thought I needed to talk about pro, or RADV or anything else other than my direct question in response to that statement.

This makes me think they're going to do their own open source implementation, I'm aware of radv, I know of pro, and it's vulkan implimentation but when he said "vulkan support... until it's opensourced"... that's why i asked, jesus people.

[Ground0]

Nice Result for AMD :-) everywhere on my Computer and Notebooks are AMD and one Notebook with a Intel/AMD dual graphic. The only Computer with a NVidia is a Computer in a company where i work sometimes (GTX 950 installed now with nouveau and no more proprietary shit who is killed on every Kernel Update. (DP Full Screen Resolution works and i didn't need more ...).

[bridgman]

Wait are you saying you're still going to implement your own Vulkan support to AMDGPU?

yeah, thanks, I know all that, buuuut he said "Vulkan support is available via the packaged releases until it's open sourced." yeah so... IDK where you guys thought I needed to talk about pro, or RADV or anything else other than my direct question in response to that statement.

This makes me think they're going to do their own open source implementation, I'm aware of radv, I know of pro, and it's vulkan implimentation but when he said "vulkan support... until it's opensourced"... that's why i asked, jesus people.

The "packaged releases" agd5f mentioned are the AMDGPU-PRO releases - that's the connection there. The AMDGPU-PRO packages include a closed-source Vulkan userspace driver which runs on top of a slightly tweaked (relative to upstream) amdgpu kernel driver also included in the packages.

The "open source implementation" you are talking about will be a modified version of the source code for that closed source Vulkan userspace driver, where the modifications primarily involve:

(a) restructuring the code so that it can be build and run without all of the third-party code we use when running that driver on other platforms than Linux,

(b) using the shader compiler subsystem from the open stack rather than our closed-source shader compiler, and

(c) being able to run on the upstream amdgpu kernel driver rather than the version included in AMDGPU-PRO packages.

Does that help ?

[nanonyme]

The "packaged releases" agd5f mentioned are the AMDGPU-PRO releases - that's the connection there. The AMDGPU-PRO packages include a closed-source Vulkan userspace driver which runs on top of a slightly tweaked (relative to upstream) amdgpu kernel driver also included in the packages.

The "open source implementation" you are talking about will be a modified version of the source code for that closed source Vulkan userspace driver, where the modifications primarily involve:

(a) restructuring the code so that it can be build and run without all of the third-party code we use when running that driver on other platforms than Linux,

(b) using the shader compiler subsystem from the open stack rather than our closed-source shader compiler, and

(c) being able to run on the upstream amdgpu kernel driver rather than the version included in AMDGPU-PRO packages.

Does that help ?

Do you guys own the shader compiler in amdgpu-pro or does it contain trickily licensed components? Just wondering why the idea of opensourcing *that* never came up in discussions I've seen

[bridgman]

AFAIK we own it but it contains trade secrets primarily related to the Windows market. We have discussed opening it up several times but the conclusion each time was "no".

We have already moved other drivers onto the LLVM-based direct-to-ISA compiler logic we will use for the open sourced Vulkan driver, including OpenCL.

[dungeon]

Just give me ddx and vulkan and out of mesa really... also why CL, as VK is 3D graphics but also compute API who would need anything else.

Mesa guys probably hate me, but it is better that way - no past, no breakages, no crap, no bloat and easy peasy . Only problem is i don't wear red hat, otherwise AMD might listen

[forkbomb]

I wonder when will the GCN 1.0 be fully supported from amdgpu kernel driver upwards. No news on that front for 4.12 I guess. And RADV still hangs the system on most stuff. I wouldn't go as far as to call the lack of Vulkan support and OpenGL compat profiles "nearly catching up", especially with Vulkan being hailed as the lord and saviour of Linux gaming.

[vein]

The "packaged releases" agd5f mentioned are the AMDGPU-PRO releases - that's the connection there. The AMDGPU-PRO packages include a closed-source Vulkan userspace driver which runs on top of a slightly tweaked (relative to upstream) amdgpu kernel driver also included in the packages.

The "open source implementation" you are talking about will be a modified version of the source code for that closed source Vulkan userspace driver, where the modifications primarily involve:

(a) restructuring the code so that it can be build and run without all of the third-party code we use when running that driver on other platforms than Linux,

(b) using the shader compiler subsystem from the open stack rather than our closed-source shader compiler, and

(c) being able to run on the upstream amdgpu kernel driver rather than the version included in AMDGPU-PRO packages.

Does that help ?

Maybe a stupid question but... how does this differ from RADV? Just that it is you who implement it?
I just think that maybe you should try cooperate on this...

And I would rather see you spend time on making rocm to being able to run on upstream kernel...

[bridgman]

Maybe a stupid question but... how does this differ from RADV? Just that it is you who implement it?
I just think that maybe you should try cooperate on this...

We wrote the Vulkan driver a couple of years ago and use it across multiple OSes and environments, not just Linux. We started working on an open source version of the Vulkan driver a year or so ago so we could have the kind of cooperation you suggest.

The RADV driver is more recent, started a bit less than a year ago.

And I would rather see you spend time on making rocm to being able to run on upstream kernel...

Rather than what - open sourcing the Vulkan driver ? Remember that we have to maintain our Vulkan driver for other OSes anyways, so it's not a case of "if we don't do X we free up resources for Y". On the other hand if we stop using our Vulkan driver and shift to RADV we have to *add* developers since we would now need to maintain two Vulkan driver code bases.

We already have other developers working on upstreaming KFD - if you remember my posts over the last year or so we had a lot of other work to do first (primarily implementing eviction logic so that hard-pinned ROCm buffers would not interfere when the graphics stack needed memory); we now have that running and so are able to resume upstreaming efforts.

Next steps were integrating KFD into the hybrid driver stack - (done, you'll see it in upcoming driver releases) and shifting the ROCm & internal trees onto newer kernel versions (WIP, next ROCm stack release should be 4.11-based). At that point we have all the foundation work done and can start pushing patches upstream.

[Mike Frett]

Now if only most of the Games would work with and support MESA...