RADV Achieves Same-Day Conformance For Vulkan 1.1

[dungeon]

That is of course fantastic news, however, is RADV otherwise feature complete and fully conforming?

It seems enough feature complete to pass conformance

[artivision]

I hope that RADV will not adopt all the stink to, like the protected video playback. Those companies are full of shit, they are always advertising something like HLSL front end to SPIRV but that is from HLSL source, no one ever does the right thing like DXBC to SPIRV. Since you all use Linux here, just make sure that you see the difference.

[nuetzel]

@Michael: Update please, all is there!

https://cgit.freedesktop.org/mesa/mesa/log/

Currently, even with AMD_gcn_shader extension from Daniel Schürmann.

[nuetzel]

That is of course fantastic news, however, is RADV otherwise feature complete and fully conforming?

Didn't you 'click' the offered link?

https://www.khronos.org/conformance/adopters/conformant-products#submission_308

[nuetzel]

Really impressive work by the driver devs. Its actually astonishing. However, it will take months till things appear in an official release. You may say thats no problem because we have no users of Vulkan 1.1 anyway but what if this changes? Maybe next feral game come with support, nvidia and amd binary users can start right away, mesa people wait 6 months till their distro picks up support...

Why can't you (if you need it for i.g. gaming) add a repro for Mesa git?

[pal666]

Is it possible to bring RADV to Radeon?

yes, by installing recent kernel and booting with parameters disabling radeon and enabling amdgpu

[bridgman]

Is it possible to bring RADV to Radeon? Why is AMDGPU needed?

Do you mean "radeon rather than amdgpu on GCN hardware" or "radeon so I can run pre-GCN GPUs" ? That's an important distinction AFAIK.

Running RADV on radeon rather than amdgpu on GCN hardware is probably doable (although the radeon IOCTL set might need some additions) but it hardly seems worth the effort.

Running on pre-GCN hardware is more of an issue - Mantle definitely needed GCN-level hardware and I *think* that is also the case for Vulkan, but I'm not 100% sure since IIRC the Vulkan spec was tweaked relative to Mantle in order to allow support on slightly less feature-ful hardware.

[nuetzel]

yes, by installing recent kernel and booting with parameters disabling radeon and enabling amdgpu

But some 'older' APU's (my father's Kaveri) have some trouble with it (at least under openSUSE 43.2).
screen console 'flashing'

[airlied]

Do you mean "radeon rather than amdgpu on GCN hardware" or "radeon so I can run pre-GCN GPUs" ? That's an important distinction AFAIK.

Running RADV on radeon rather than amdgpu on GCN hardware is probably doable (although the radeon IOCTL set might need some additions) but it hardly seems worth the effort.

Running on pre-GCN hardware is more of an issue - Mantle definitely needed GCN-level hardware and I *think* that is also the case for Vulkan, but I'm not 100% sure since IIRC the Vulkan spec was tweaked relative to Mantle in order to allow support on slightly less feature-ful hardware.

I think you could to Vulkan on CAYMAN, but I don't think evergreen could (at least I don't think the virtual memory hw is up to how you'd want to do it).

Dave.

[Kavalor]

Really impressive work by the driver devs. Its actually astonishing. However, it will take months till things appear in an official release. You may say thats no problem because we have no users of Vulkan 1.1 anyway but what if this changes? Maybe next feral game come with support, nvidia and amd binary users can start right away, mesa people wait 6 months till their distro picks up support...

Unfortunately that is the best you will ever see, to push the changes in a public repository earlier would violate the NDA's and Information Embargoes. We have seen with the chaos around Meltdown/Spectre , which broke a week early because of speculation resulting over some code pushes into the kernel.

Maybe the release model of mesa should change from a time based release schedule to a feature based schedule.
Same for maintenance releases. It may sounds cool if you have 100 patches in each stable release but honestly I think once an important bug gets fixed, like fixes for popular games / apps, crash and hang fixes, fixes for WM / DE the release should happen at least in the same week.

And that would only change things for rolling releases but not for stable one, where it already depends when they plan the next release. These decision are already done independent of the upstream release cadence. They just take whats current mostly , when they start building.