AMD Open-Source Driver For Vulkan "AMDVLK" Is Now Available

[davidmaoAMD]

Absolutely!
Could you file an issue on github with backtrack attached?
You will get informed when we make any progress.

Any plans to support SteamVR? It looks like all the extensions that SteamVR requests are supported, but

*** Error in `/home/chris/.local/share/Steam/SteamApps/common/SteamVR/bin/linux64/vrcompositor': malloc(): memory corruption: 0x0000000001a19370 ***

[haagch]

Sure, but first I'll need to build a debug version because https://pastebin.com/bwNiq9Dq is not very informative.

At the AMDVLK or xgl repository?

[GruenSein]

Why would it be odd ? That's a compiler issue and the compiler is not shared with Windows. All of our open source drivers use a common LLVM back end, albeit slightly different versions for each driver at the moment.

That said, in the same way that moving to a common amdgpu kernel driver meant more developers working on open source kernel driver code we should now have more developers working on open source compiler code from a graphics POV.

Is the closed source version of AMDVLK going to stick with the proprietary compiler or is it eventually going to switch to the LLVM-derived open source one. The other way around doesn't seem to be feasible otherwise you guys would've done so from the start since I figure that the proprietary compiler was there first.

[geearf]

That's a compiler issue and the compiler is not shared with Windows.

Why isn't the compiler shared? What else, if anything, is not shared?

[VikingGe]

They work just fine for me on RADV. They take a second to load, but they do load.

Thing is, do they load correctly? On my system it looks like this: http://s1.bild.me/bilder/110417/5479...hirmfoto-6.png

And yes, that was with the old PRO-Driver, looks identical with RADV though - so no idea what's wrong.

[davidmaoAMD]

The backtrace seems enough
You could just file an issue on AMDVLK.
Please don't forget to let us know the distro you are using as well as the kernel version.
Thanks!

Sure, but first I'll need to build a debug version because https://pastebin.com/bwNiq9Dq is not very informative.

At the AMDVLK or xgl repository?

[ramrod]

Thing is, do they load correctly? On my system it looks like this: http://s1.bild.me/bilder/110417/5479...hirmfoto-6.png

And yes, that was with the old PRO-Driver, looks identical with RADV though - so no idea what's wrong.

Yeah they load correctly for me. Here's a screenshot of what it looks like on RADV for me. https://imgur.com/cIKqecv

This is a screenshot of the same spot with same settings on AMDVLK. https://imgur.com/94urads

[Constantine]

First time posting here.

Just wanted to say thank you to everyone who was involved in open sourcing this driver at AMD!

[bridgman]

Is the closed source version of AMDVLK going to stick with the proprietary compiler or is it eventually going to switch to the LLVM-derived open source one. The other way around doesn't seem to be feasible otherwise you guys would've done so from the start since I figure that the proprietary compiler was there first.

The long term plan is to standardize on the LLVM-based compiler, but there is still some work to do.

Why isn't the compiler shared? What else, if anything, is not shared?

Two part answer - we already had a solid open source compiler back end that was being used for both Mesa and ROC/HCC, and our overall direction is to move from our older proprietary shader compiler to the LLVM-based one over time anyways. The choice was whether to spend time sanitizing the older compiler or work on improving the newer one.

The compiler is the only substantial difference between closed and open AFAIK - the other differences are a consequence of removing code for other OSes and APIs.

[Evil Penguin]

The long term plan is to standardize on the LLVM-based compiler, but there is still some work to do.



Two part answer - we already had a solid open source compiler back end that was being used for both Mesa and ROC/HCC, and our overall direction is to move from our older proprietary shader compiler to the LLVM-based one over time anyways. The choice was whether to spend time sanitizing the older compiler or work on improving the newer one.

The compiler is the only substantial difference between closed and open AFAIK - the other differences are a consequence of removing code for other OSes and APIs.

So even Windows and Mac OS drivers will end up using LLVM for shader compiling down the line?