The open source Vulkan driver for AMD hardware 'radv' now gets 'effectively a pass' for conformance. An awesome milestone for AMD fans.
From the blog post:
They do specifically note that the "Not supported" section isn't missing features, but rather pointless things and stuff the hardware doesn't support.
It still needs to go through the official Khronos Group procedure, so they can't say the driver is actually conforming properly just yet.
I still personally plan to switch to an AMD GPU when the time arises, so it's really pleasing to know that things are in such good shape.
Thanks for the tip Joeri!
From the blog post:
QuoteTest run totals:
Passed: 109293/150992 (72.4%)
Failed: 0/150992 (0.0%)
Not supported: 41697/150992 (27.6%)
Warnings: 2/150992 (0.0%)
They do specifically note that the "Not supported" section isn't missing features, but rather pointless things and stuff the hardware doesn't support.
It still needs to go through the official Khronos Group procedure, so they can't say the driver is actually conforming properly just yet.
I still personally plan to switch to an AMD GPU when the time arises, so it's really pleasing to know that things are in such good shape.
Thanks for the tip Joeri!
Some you may have missed, popular articles from the last month:
All posts need to follow our rules. For users logged in: please hit the Report Flag icon on any post that breaks the rules or contains illegal / harmful content. Guest readers can email us for any issues.
13 comments
So in other words this means that RADV driver is 72.4% conforming to the rendering test in the same way that browsers conform to ACID2 and ACID3 test to test their rendering capabilities?
Fantastic. I was hoping however to read that the pass was a "go-ahead" from their legal department or some other management to release code. Soon? Hopefully.
Fantastic. I was hoping however to read that the pass was a "go-ahead" from their legal department or some other management to release code. Soon? Hopefully.
0 Likes
So in other words this means that RADV driver is 72.4% conforming to the rendering test in the same way that browsers conform to ACID2 and ACID3 test to test their rendering capabilities?
Fantastic. I was hoping however to read that the pass was a "go-ahead" from their legal department or some other management to release code. Soon? Hopefully.
You're mistaking drivers I think; RADV is the mesa backed driver and all the code is already open and available. AMD has an in house vulkan driver that currently performs slightly better than RADV and I think that's the one you thought this article was about. They're still waiting for the greenlight to open source that one.
3 Likes, Who?
Knowing that the Linux kernel maintainers don't allow two drivers enabled for the same hardware at the same time (from what I understood), there's going to be a battle between RADV and AMD if they open source their Vulkan drivers...
0 Likes
Knowing that the Linux kernel maintainers don't allow two drivers enabled for the same hardware at the same time (from what I understood), there's going to be a battle between RADV and AMD if they open source their Vulkan drivers...
They would more than likely merge the two.
2 Likes, Who?
Knowing that the Linux kernel maintainers don't allow two drivers enabled for the same hardware at the same time (from what I understood), there's going to be a battle between RADV and AMD if they open source their Vulkan drivers...
They would more than likely merge the two.
This would make the most sense, I could see the radv developers "migrating" and submitting their patches directly to the AMD source.
0 Likes
Or AMD would hand it to dave to integrate into RADv which I feel they would do.
0 Likes
Knowing that the Linux kernel maintainers don't allow two drivers enabled for the same hardware at the same time (from what I understood), there's going to be a battle between RADV and AMD if they open source their Vulkan drivers...
They would more than likely merge the two.
I highly doubt that. We may see the AMDGPU-PRO driver making use of radv in future instead of their own implementation below AMDs AL in their driver. Same thing which goes on now with the DC/DAL patchset. It's more work involved there for the AMD devs, and AMD has been .. slightly pissed off not being able to do what ever they want for their hardware in the kernel, so we may still end up with two implementations in the end ;-).
Last edited by STiAT on 4 May 2017 at 8:32 pm UTC
0 Likes
Just in time for VEGA.
0 Likes
Knowing that the Linux kernel maintainers don't allow two drivers enabled for the same hardware at the same time (from what I understood), there's going to be a battle between RADV and AMD if they open source their Vulkan drivers...
While that *might* be true for the kernel (sort of, you can have both amdgpu and radeon enabled for the earlier GPUs, and blacklist one at startup time), RADV and the AMDGPU-PRO (vulkan) driver are using the same kernel module, so there is really no such policy.
In theory, it would be pretty easy, even right now, I think, to make a userspace utility to launch an application with one driver or another, with a right click.
Those are the userspace drivers, they should just communicate with the kernel module via libdrm or similar, and handle the shader compilation, scheduling, etc.
So in other words this means that RADV driver is 72.4% conforming to the rendering test in the same way that browsers conform to ACID2 and ACID3 test to test their rendering capabilities?Not really, more like your car is 100% operational (conformant), but it doesn't have some options that could apply to other products: skis, wings, thrusters, whatever. Maybe even some more relevant but narrow-use functionality like an elevated air intake.
Sorry, that was the only analogy that I could think of.
0 Likes
Knowing that the Linux kernel maintainers don't allow two drivers enabled for the same hardware at the same time (from what I understood), there's going to be a battle between RADV and AMD if they open source their Vulkan drivers...
They would more than likely merge the two.
I highly doubt that. We may see the AMDGPU-PRO driver making use of radv in future instead of their own implementation below AMDs AL in their driver. Same thing which goes on now with the DC/DAL patchset. It's more work involved there for the AMD devs, and AMD has been .. slightly pissed off not being able to do what ever they want for their hardware in the kernel, so we may still end up with two implementations in the end ;-).
We are referring to Vulkan and Radv not the kernel driver
0 Likes
While that *might* be true for the kernel (sort of, you can have both amdgpu and radeon enabled for the earlier GPUs, and blacklist one at startup time), RADV and the AMDGPU-PRO (vulkan) driver are using the same kernel module, so there is really no such policy.
I'm not saying that they implemented a system to prevent having two drivers for the same hardware, I'm saying that the maintainers' policy is to refuse patches that would enable two drivers for the same hardware. The idea behind that is to prevent to split the code and the resources in two. So that's why RADV and AMDGPU-PRO can live together: AMDGPU-PRO is not open source, so not in the kernel, so not under this maintainer' policy.
That being said, since these drivers are user space, I might just be saying garbage :D
0 Likes
Good to see such fast progress. I hope optimizations will be the next logical step.
Regarding two drivers. Once AMD will open source their Vulkan implementation, there is really no reason for distros not to provide it as an option. Let the user decide what performs better, radv or AMD Vulkan.
Last edited by Shmerl on 5 May 2017 at 1:43 am UTC
Regarding two drivers. Once AMD will open source their Vulkan implementation, there is really no reason for distros not to provide it as an option. Let the user decide what performs better, radv or AMD Vulkan.
Last edited by Shmerl on 5 May 2017 at 1:43 am UTC
1 Likes, Who?
next step is the performance conformance...
at least i'm my book
at least i'm my book
0 Likes
See more from me