It's an interesting use case, but I don't think it's feasible to use DXVK for porting right out of the box unless your entire port is based on winelib. DXGI is tightly coupled to the win32 window management API, which causes a number of issues:
IDXGISwapChain and IDXGIOutput would have to be rewritten against whatever you use for window management (in this case, SDL2). It currently uses raw win32 functions.VkSurface for your window.I haven't explored the option of using DXVK for native apps yet, so there might be more potential issues.
Thanks for answer! :)
Port isn't based on winelib, as using wine is not an option.
If I will get something working, I will send a PR. Currently I just patched meson buildscripts a little.
Why using Wine/winelib is not an option though, if you are ready to use wrapping in general?
Feral would be interested in this, for sure.
@shmerl because it needs wine as a dependency. Also, winelib doesn't give any serious advantages at all.
@gasinvein for sure.
Nothing extracted yet.
Hello, fellow developers.
I am wondering, how hard using DXVK as a wrapper for Linux ports to minimize work?
All that I understood on this moment: DXVK provides DXGI(which initializes the D3D10/11 driver) and D3D10/11 implementation DLLs. For build it requires Wine headers.
So, for example, I am porting some game engine with D3D10 and D3D11 renderer backends. Game engine successfully initializes Vulkan with SDL2. Windows build already works fine with DXVK on Wine. Then...
Don't know if it was posted before, if so, sorry for taking your time.