AMDVLK VS xgl

Budeš je muset sám compilenout z open source kódu.

If RADV hangs rdr2 at the moment you can temporarily switch to amdvlk, you can also switch on a game-to-game basis without rebooting or anything. You can get it from the release section of their github: https://github.com/GPUOpen-Drivers/AMDVLK. But keep in mind that amdvlk will make itself the default as long as you have it installed.

Other parts of the stack can be released, and I'd bet anything that AMD's vulkan driver, amdvlk, is at least very similar to the windows implementation, just with a different PAL backed by whatever the windows systems are instead of libdrm.

Switching from RADV to AMDVLK fixed the issue. I haven't noticed any performance differences once the shaders are compiled.

Looks like an issue with a more recent version of amdvlk (https://github.com/GPUOpen-Drivers/AMDVLK/issues/278). Some people resolved by uninstalling amdvlk, but I was able to launch it with amdvlk still installed by using the launch options settings I've provided with this report.

API layer is here: https://github.com/GPUOpen-Drivers/xgl

Not sure if you mean games or drivers, but AMDVLK uses C++ for it's usermode driver, it disables features like exceptions, RTTI etc. From my experience, games are generally the same. The kernel is still C though.

That's the wrong repo for AMDVLK. You have to look at these https://github.com/GPUOpen-Drivers/llpc https://github.com/GPUOpen-Drivers/xgl https://github.com/GPUOpen-Drivers/pal And this is also just the user space vulkan driver that nobody uses, the real driver you should look at is radv, which was initially written by red hat and Bas Nieuwenhuizen, and is maintained by Bas (afaiu as a hobby) and a team of Valve contractors. And then there's radeonsi, which is now mostly maintained by AMD, but has seen a lot of third party contributors over the years, and amdgpu + the display stack, which is mostly worked on by AMD.

The problem is not the global variable, maybe I've expressed my self wrong. The issue is that this doesn't store the needed function pointers for each instance, just for one and it will get overwritten if you create another instance. In many other layers you have some kind of map. (well not the VkInstance itself but the loader's dispatch table pointer, but that's probably too much details)