Wine Developers Are Creating Their Own Vulkan Loader Library

[Thunderbird]

WTF??? So it seems like to me there will necessarily have to many different loaders and it's gonna depend on which apps you use which loader will work for you.... Good job wine devs, I shoulda expected something like this, it's your typical BS.

Our vulkan-1 loader is not a big deal at all. It is just meant to give a good out-of-the-box experience. The only feature not there is layers, which is mostly a debug feature for troubleshooting. The main Vulkan features are all there. Actually my loader is slightly faster than the official loader, because there is much less overhead inside. In addition we will also make it easier over time to add the official Vulkan runtime.

Most users wouldn't even know which vulkan loader they are on and most should not have a need to toggle between runtimes. This is really a light dll, nothing like d3dx9 and other runtime dlls.

[duby229]

Phoronix: Wine Developers Are Creating Their Own Vulkan Loader Library

While mainline Wine development code has enough Vulkan support that it can run the few Windows Vulkan games like Wolfenstein and DOOM along with the Vulkan code samples and the Vulkan information utility, it's currently dependent upon the Windows Vulkan SDK being manually installed on the system. That's now changing with Wine developers working on their own Vulkan loader library...

http://www.phoronix.com/scan.php?pag...e-Own-Vulkan-1

WTF??? So it seems like to me there will necessarily have to many different loaders and it's gonna depend on which apps you use which loader will work for you.... Good job wine devs, I shoulda expected something like this, it's your typical BS.

[oiaohm]

That's a good point.
What is the reason for not doing that?

Reason go build library route and not the vulkan sdk install route is look at opengl in wine.

1) Its all about shorter distance between application and hardware. Using function tables so that you can use functions straight from the host vulkan library that the sdk would re-implement.\

2) the fact wine is planing on building on top. For running automated testing keeping the number of installers down will be good.

Of course this is going both ways winetricks and built in library are being done at this stage.

Please note the gecko wine uses is highly modified to be more like IE and it was just too resource costly to rewrite it completely and of course gecko is the wrong license..

This is one of the big differences wine core developers care that foundations are put down right. Not building on top of incomplete foundations.

Yes it possible to get ahead of what wine developers are doing mainly because they care about the foundations.

[geearf]

I'm not sure if that's as good. Easier would be to simply install it like gecko as default.

That's a good point.
What is the reason for not doing that?

[shmerl]

Plus, layers should be supported by libvulkan.so.1, as written above, even if not supported by the DLL. So, say steam/wine cannot inject its overlay in the rendering pipeline (for now), but if you launch yourgame/steam/wine trough steam/linux, you should have it (though probably not with the game-specific features). It's getting complicated, but that's my understanding.

I think it means you can't inject Windows Vulkan layers, but you still can inject Linux ones naturally. Layers are added as dynamic libraries by the loader. So Windows loader won't have that option, but Linux loader to which it all in the end translates, still has them. So this is only a minor issue, since if you really need Windows layers, you can use Vulkan SDK loader which supports them (not sure though, how Wine will need to be configured between the two).

[shmerl]

There is no need for inventing wheel again , just pull it from DXVK.

DXVK relies on existing loader, it doesn't implement one. That's why you had to install Vulkan SDK in Wine prefix to use it. With this loader, it won't be necessary.

[mike44]

I'm not sure if that's as good. Easier would be to simply install it like gecko as default.

[M@yeulC]

I think i should have been much more clear:
There is no need for inventing wheel again , just pull it from DXVK.

As far as I know, DXVK has no such thing, unless I missed something?

Last thing I read, you needed to install the Vulkan SDK (from lunarG?) either manually or trough winetricks. Hardly an out-of the box experience. This should fix it.

Plus, layers should be supported by libvulkan.so.1, as written above, even if not supported by the DLL. So, say steam/wine cannot inject its overlay in the rendering pipeline (for now), but if you launch yourgame/steam/wine trough steam/linux, you should have it (though probably not with the game-specific features). It's getting complicated, but that's my understanding.

[Leopard]

this is needed for DXVK to even work

I think i should have been much more clear:
There is no need for inventing wheel again , just pull it from DXVK.

[VikingGe]

In other words AMDGPU-PRO will not be supported where you have both OSS and AMDGPU-GPU Vulkan implementations present (which is probably always)?

No, because there's an additional layer of indirection. vulkan-1.dll -> winevulkan ICD -> libvulkan.so.1 -> whatever ICD you have installed on your system. You don't need to support multiple drivers to support multiple devices.

DXVK is way to go , no need for repeating same processes over and over again.

What? DXVK relies on this and these patches will make it so much easier to set up and use.