WineD3D Optimistic In Their Yet To Be Proven Vulkan Backend, DXVK "Dead End"

[Weasel]

Most of Wine's implementation of Windows libraries suck ass. Even in their latest 'staging' build they some how broke the GetTickCount API call...GetTickCount! One of the most commonly used API calls and some dipshit broke it, which broke every Blizzard game in existence (for example.) Too many hands in the pot. Wine should be broken up and unit tests should be written for popular applications (by people who own those applications).

That's what happens when you are obsessed with "code cleanness" instead of practical things that matter for the end user.

[bobwya]

i can understand that, since DXVK has per-game hacks to improve compatibility. that's not the right way forward.

e.g. https://github.com/doitsujin/dxvk/pu...a4841bb883a748

the Wine way was always to write code well enough not to do exceptions for specific apps. if something is wrong in Wine, the fix affects all the programs and aims to be generic. you may fiddle some knobs in winecfg but the app itself does not check the process name and apply some hacks to make it work better.

Bzzt not really... Given that games are churned out these days... Game development studios are generally not renowned for the quality of their code!

The Wine way is to say we will do everything "really, really cleanly"... If any games do something dubious - well tough luck you can't run that game then...
E.g. can it (wined3d) run Crysis... NO!

DXVK implements per-game hacks and will therefore always offer better performance and compatibility then Wine's Vulkan translation layer... Which will probably starting being useable in 20 years time or so... Also it should be noted... It CAN run Crysis!

[bobwya]

That's what happens when you are obsessed with "code cleanness" instead of practical things that matter for the end user.

^^^This

At least Phillip is doing regression testing with a suite of games and using different graphics cards / vendors...
He is also responsive to community feedback e.g. pulling DXVK versions that cause serious regressions.

The Wine Developers have a set of low-level unit tests, which do not, in any shape or form, mimic full applications or games.
Hence why we see so many game regressions, with stock Wine / Wine Staging...

[artivision]

You wrote mistake here.



And repeated it again. The D3D9 and D3D12 provides an api to the state tracker. The driver provides a state tracker single state tracker. Windows 10 D3D9 is in fact implemented on the Dx12 vendor driver state tracker. So windows design in fact have your proxy-ed and applications expecting that behaviour will see your caught because they are expecting locking in the two API state trackers to line up in places that only happens if they are proxies on top of 1 state tracker.

Please note the driver state tracker does have feature it does not expose in Dx12 for Dx11, Dx9 and Dx7.

Basically under windows all versions of Dx provided don't have individual state trackers. They have a common core state tracker provided by the graphics card vendor.



Sorry no if you remove WineD3D you remove Dx 1-7. You need dx 7 for new Windows 10 applications at times particularly in different game installers. Yes the game may be Dx11 but the installer is Dx7. So you need D7VK or something like that before you can remove Wined3d. Basically you are still 1 project short.

I am not past the idea of vulkan only version of wine but what is required todo that does not exist as of yet. This does come with downsides.



What you are not getting is it still only a part solution. There is no point avoiding the pit falls. By the way I am not interested in old applications. Hybrid mess are commonly brand new catalogue applications.

DXVK is only support games. Codeweavers/Crossover are supporting mostly supporting Enterprise applications like these horrible catalogue applications.

You have with the horrible enterprise apps having customers asking for I want this horrible program to run on this cheap android tablet. So no Vulkan.
You have as well same horrible enterprise apps to run on a 2002 computer. Yes using new Windows 7+ API.

So for codeweavers not have opengl support equals losing customers and money to maintain the core development.

Basically the problem here is DXVK/D9VK is not what provides codeweavers with the basic funding to maintain the wine core code.

Time you pull you head out the sand both of you and work out that wined3d not performing the best is not codeweavers first problem. Having enterprise applications work where enterprise customers want so enterprise customers pay for product to keep the lights on is.

DXVK developers and Wined3d developers are servicing two very different markets. Neither solution at this stage can service both markets well.

Remember the old saying you have two to tango. This case you have two markets with two different requirements. If you need one set of requirements the other one is not that suitable. Heck if you are needing both set of requirements you are stuck with complexity because currently neither DXVK or Wined3d can service both by themselves.

On Windows a D3D9 state tracker does DXBC9 to AMD-IL and a different D3D12 front end does DXBC12 to AMD-IL again, DXBC9 never converts to DXBC12 and then AMD-IL. Even if someone does this in the future, it will be games only because it will be lossy conversion as always. And again there is a need for a Staging without WineD3D with other options by default.

[JoshuaAshton]

i can understand that, since DXVK has per-game hacks to improve compatibility. that's not the right way forward.

e.g. https://github.com/doitsujin/dxvk/pu...a4841bb883a748

the Wine way was always to write code well enough not to do exceptions for specific apps. if something is wrong in Wine, the fix affects all the programs and aims to be generic. you may fiddle some knobs in winecfg but the app itself does not check the process name and apply some hacks to make it work better.

This is obviously a quote from someone who has never seen the source code of any graphics driver.

[Cybmax]

I still don't get it from the link in the article.
What's the reason Wine refuses to integrate/merge DXVK?

Because Philip has not responded to mails?
From what I read this guy is extremely polite.
Has this been sorted out?

Should not be too hard for Wine devs to reach Philip i think...

https://source.winehq.org/git/vkd3d.git/search?s=Philip+Rebohle;st=author

Now, this COULD ofc be another Philip Rebohle (from germany ref. the e-mail address given), that just happens to contribute code to Wine d3d12->vulkan api... but i would very much think not

Sure it LOOKS like having Wine integrate dxvk into wine would be the "right way", but as ppl have commented in this thread, and from current wined3d experience, wine with CURRENT implementation (and most likely future) is not about performance, but more compatibility. Wine dev's have proven probably a million times over that having "correct implementation" trumps "more fps". And for GAMERS, correct implementation kinda means nothing if that makes you pop around with 2 fps while playing.
However, having "correct implementation" would probably mean that program from 19-hundreds-before-inventing-fire program you try to run might work. And that is (as ppl have said) mainly Codeweavers whole businessidea.

So i say, let Wine devs diddle with their wined3d vulkan implementation for a few years, and lets all (and STEAM Proton) enjoy DXVK for gaming performance under Linux... although having DXVK kinda under the "staging hat" could be a doable idea, since staging is mainly for "hacks to get stuff working". Making DXVK or VKD9 easier compiled and implemented in wine would be a +, but do not expect this to be mainline.

[oiaohm]

On Windows a D3D9 state tracker does DXBC9 to AMD-IL and a different D3D12 front end does DXBC12 to AMD-IL again, DXBC9 never converts to DXBC12 and then AMD-IL. Even if someone does this in the future, it will be games only because it will be lossy conversion as always. And again there is a need for a Staging without WineD3D with other options by default.

Ok you are under a fatal miss understanding "vendor driver state tracker" where do you think the AMD-IL is going thinking that is not what the gpu takes.

Staging without WineD3D at this stage would equal many installers not working. DX7 functions is used in quite a few places for like button effects.

[artivision]

Ok you are under a fatal miss understanding "vendor driver state tracker" where do you think the AMD-IL is going thinking that is not what the gpu takes.

Staging without WineD3D at this stage would equal many installers not working. DX7 functions is used in quite a few places for like button effects.

AMD-IL like LLVM-IR is used as target for many Apis (like OpenCL) to do certain optimizations before the last HW compilation step. State trackers called the things above that level. That way you can say that all those Apis like WineD3D and DXVK are unified on a lower level NIR or LLVM or Nvidia-IL. I don't understand why you need to mix them on a higher level, no one does that. The vendor intermediate driver decides what must be done when you call two Apis at the same time.

[oiaohm]

AMD-IL like LLVM-IR is used as target for many Apis (like OpenCL) to do certain optimizations before the last HW compilation step. State trackers called the things above that level. That way you can say that all those Apis like WineD3D and DXVK are unified on a lower level NIR or LLVM or Nvidia-IL. I don't understand why you need to mix them on a higher level, no one does that. The vendor intermediate driver decides what must be done when you call two Apis at the same time.

Thing you are not allowing on is the Windows DX design allows particular calls straight down to the intermediate driver particularly when it comes down to buffer and shader sharing.

https://docs.microsoft.com/en-us/windows/desktop/direct3ddxgi/d3d10-graphics-programming-guide-dxgi

I made a error you did not correct me.

Lets look at this closely. Dx7 dx9 and dx12 don't go directly to hardware on Windows 7.

Output buffers are this pattern
DX9ex user mode driver to DXGI to Vendor kernel driver.
DX10 user mode driver to DXGI to Vendor Kernel driver.
DX11 user mode driver to DXGI to Vendor Kernel driver.
DX12 user mode driver to DXGI to Vendor Kernel driver.

Dx7 usermode on Windows 7 is basically a wrapper to DX9ex so the output buffers are also DXGI.

Reality is WineD3D and DXVK are unified at the driver layer and also unified at DXGI. But DXGI done backed on Opengl is different to DXGI done backed on Vulkan to the point of being incompatible.

Yes a lot look at the DX9ex and cannot find the API/ABI difference because there basically is not one. The difference is DX9ex is not going direct to vendor kernel driver for output buffers but to DXGI for output buffers so they can be synced .

There is a state tracker in DXGI you have missed.

Basically Windows design like or not has them on a higher level. You were missing a state tracker the DXGI state tracker that is shared every what way. So you need to get everything outputting to a single group of buffer types that can be API probed by DXGI.

https://github.com/nlguillemot/OpenGL-on-DXGI

Heres opengl by AMD, Nvidia and Intel being able to do the shared DXGI. These mixed mess are using DXGI heavily.

This is where things get tricky right. How does DXVK connect up to WGL_NV_DX_interop2 in Opengl into its DXGI. Wine backing on opengl connecting WGL_NV_DX_interop2 is simple and straight forwards. Same with connecting up Dx7, Dx9 and Dx10/11.

Changing to Vulkan backed due to having to support DXGI is a lot more complex and requires you to in fact deal the point where opengl and direct X pass though the same identical for outputting.

[Weasel]

DX7 functions is used in quite a few places for like button effects.

No that's gdi. Windows might implement the gdi functions using DX7 (although I doubt it) but the app doesn't care, all it does is call gdi functions or just uses the common controls themselves. So Wine can implement the gdi functions however it wants to.