Wine's Direct3D Vulkan Back-End Continues Seeing An Uptick In Activity

[oiaohm]

You act like this developer didn't know what he was doing... Josh Ashton is the developer of d9vk and thus the d3d9 backend of DXVK itself. I'm not sure you should be questioning whether he knew what he was getting into when he forked his own project to make a native Linux compatible version.

Reality is saw Josh Ashton ask questions in freenode in #winehackers about 2 days after made that fork. So he did not know what the heck he was getting into when he made that fork. Has not got far enough yet for all the nasty finer details of how direct x applications using macros and other inlining methods ruin your day. But has got far enough that some of the nasty details will have raised their head requiring more planning and consideration to fix. So either he will be the first to get around these issues or dxvk-native will be just another project eaten alive by them.

I am not surprised by were the dxvk-native code base is that Josh Ashton would have slowed down and that slow down would have had to happen without developer interest dropping off just with types of problems that different direct x test cases would be showing at this point.

Basically history is not on Josh Ashton side. Remember many of the past attempts were not a solo developer working by themselves.

When I said was doomed to failure I don't mean as doomed to fail forever as in once you get particular point you are going to have dxvk-native fail to run the test cases that should work and then to make those work come up with a solve to the windows memory problem. These events are going to stall development speed like it or not.

What you think is a drop off due to developer lack of interest is not exactly that. It is combination that the problem is a little harder than it first appears and possible developer losing interest.

Please note Josh is not the first developer or likely the last to get caught this way.

[JPFSanders]

Reality is...

Thank you for your explanations oiaohm, much appreciated.

[oiaohm]

vkd3d is like FAudio. It implements an API similar to, but not exactly the same as, the Windows "equivalent" (which relies on Windows stuff). To be honest I do wish Wine just statically linked vkd3d somehow. Less pain in the ass dealing with a fucking distro's packages and you'd be sure it was specific to a Wine version when compiling Wine yourself.

vkd3d and faudio are not static linked in because the are meant to be used by Linux native programs as well as wine. Windows equivalent with vkd3d gets interesting thinking that Microsoft is planning dx12 on Linux so DX12 equivalent long term does not have to have the Windows particular stuff,

Compiling vkd3d is not difficult but it's an extra step, and now imagine if all other stuff had separate libraries. Yikes.

You don't understand the big change. Lets take the new ntdll.so in wine it does not depend on libwine and is a normal loadable elf .so file so what ever features end up in it will be usable from a normal native platform application.

You said wine should be using PE format. This is the price Weasel to-do that. The interface code to platform native on Linux, OS X, Freebsd requires the extra features that ELF format supports that PE does not have. So the result of getting rid of hybrid PE ELF is that the platform interface libraries will have to split in two.

Reality is both Faudio and vkd3d shows it was not that bad to split the interface libraries instead of making hybrid PE ELF.

Since there is not going to be any PE ELF hybrids in the future of wine there is really no where to static link vkd3d or FAudio in.

So now wine will move to pure PE dll files and pure platform native ELF .so files. Basically you asked for it Weasel you now got it and now you are complaining about it.

[Weasel]

vkd3d and faudio are not static linked in because the are meant to be used by Linux native programs as well as wine. Windows equivalent with vkd3d gets interesting thinking that Microsoft is planning dx12 on Linux so DX12 equivalent long term does not have to have the Windows particular stuff,



You don't understand the big change. Lets take the new ntdll.so in wine it does not depend on libwine and is a normal loadable elf .so file so what ever features end up in it will be usable from a normal native platform application.

You said wine should be using PE format. This is the price Weasel to-do that. The interface code to platform native on Linux, OS X, Freebsd requires the extra features that ELF format supports that PE does not have. So the result of getting rid of hybrid PE ELF is that the platform interface libraries will have to split in two.

Reality is both Faudio and vkd3d shows it was not that bad to split the interface libraries instead of making hybrid PE ELF.

Since there is not going to be any PE ELF hybrids in the future of wine there is really no where to static link vkd3d or FAudio in.

So now wine will move to pure PE dll files and pure platform native ELF .so files. Basically you asked for it Weasel you now got it and now you are complaining about it.

FAudio can be statically compiled/linked already. But Wine manually loads the symbols (at least for vkd3d) so it can't use statically compiled lib AFAIK.

It has nothing to do with PE/ELF hybrid. In fact, it removes the need for hybrid, that's why FAudio can be built as fully PE (but depends on PE SDL2.dll in such case obviously). Only reason for hybrid is because stuff is not statically linked and it needs to link to native .so libraries.

[oiaohm]

FAudio can be statically compiled/linked already. But Wine manually loads the symbols (at least for vkd3d) so it can't use statically compiled lib AFAIK.

It has nothing to do with PE/ELF hybrid. In fact, it removes the need for hybrid, that's why FAudio can be built as fully PE (but depends on PE SDL2.dll in such case obviously). Only reason for hybrid is because stuff is not statically linked and it needs to link to native .so libraries.

How clueless can you be. Wine is not using native faudio and vkd3d for no reason. vkd3d can also be built full PE.

Its a simple problem of distance between hardware and software. FAudio built for SDL2.dll as a PE instead of SDL2.so host would in fact have a longer distance to the output device.

Weasel its the basic concept of the levels of abstraction. PE/ELF hybrid can use both host libraries and libraries running inside wine because it has both host and wine memory models active at the same time.

Splitting PE/ELF means that PE parts of wine are running inside the wine memory model and the so parts are running with the host memory model.. So yes removing the hybrid file does not remove the reason PE/ELF hybrid existed in the first place now instead of having a single to get the same performance you need a PE Dll and a ELF .so.

There is a lot of stuff cannot be statically linked into PE binary and perform under wine.

To be correct dynamic linking to a native .so libraries is possible from a PE file under wine but you are calling though abstraction layer to convert from one memory model to another you do not want to be jumping though this abstraction layer excess number of times.

Think dx12-> wine abstracted calll to host >vkd3d->host vulkan host vs dx12->vkd3d->wine vulkan-> wine abstracted call->host vulkan. The first one in fact has less calls to be abstracted to host and less wrapper code as well(wine vulkan wrapper code is not without overhead). Same applies when you follow the Xaudio to Faudio path. Basically it does not make performance sense with wine to have Faudio or vkd3d as PE inside wine on x86 platforms.

[Vash63]

How clueless can you be. Wine is not using native faudio and vkd3d for no reason. vkd3d can also be built full PE.

Its a simple problem of distance between hardware and software. FAudio built for SDL2.dll as a PE instead of SDL2.so host would in fact have a longer distance to the output device.

lol ok