xgl VS pal

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)

Journalists (mainly the clickbait blog sort) misreported a code change from one viral tweet that there would be up to '4 interpolated frames', which is unsurprising when they aren't programmers and per the code's readme, it's used as a way to translate between the GPU and graphic APIs like DirectX, and even states "PAL client drivers will have no HW-specific code".

It's not like an DX api call is free on native drivers, DXVK implements D3D9-11 on top of vulkan, native drivers probably on top of their own abstraction, like e.g. PAL for AMD. So DXVK is more constrained in what it can do (only what's possible with vulkan), but doesn't necessarily have massively more overhead on every api call compared to native drivers.

https://github.com/GPUOpen-Drivers/pal is a big chunk of the Windows driver that is open source. The history is pruned and so is the windows backend though.

Look at the comments in pal.h to get an idea of what the API does. https://github.com/GPUOpen-Drivers/pal/blob/dev/inc/core/pal.h

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.

AMD's PAL layer is also interesting: https://github.com/GPUOpen-Drivers/pal

The problem of AMDVLK is that while it is open sourced, the development of it is not open, like at all. The code gets regularly dumped from an internal repo to GitHub, yet no one knows why this got added, and why that got removed unless they dig deep into the code. Look at this commit list.