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

[artivision]

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/win...ing-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.

Or just develop Interop for our current Apis as they are. Also you haven't proved that hybrid apps use any Interop at all, they probably just call two different state trackers without any connection.

[rmoog]

Virgin WineD3D vs Chad DXVK

[DMJC]

Saying that people should just chuck non-vulkan supporting graphics cards is just nuts. Laptops that are 7-8 years old (Sandy Bridge) still perform perfectly fine for office and audio production purposes. Throw an SSD and 16GB of DDR3 RAM in and those machines fly. No, it is unreasonable to expect people to upgrade perfectly functional hardware now that CPUs have slammed into Moore's law for the average person's needs. It's only high end gaming and video/3D production that need faster systems. Most end users have no need for faster computers. They are mostly being forced to upgrade by vendors deciding to drop security support for fully functional equipment. I understand why a Vulkan backend would be good for DirectX in WINE, and I support the developers trying to add it, but I don't support the deprecation/removal of the GL backend, especially when the equivalent functionality hasn't been reached, and that shouldn't just be a tick list of features, but should involve detailed application testing to prove the equivalent functionality is there. Much better to have the two backends be switchable with a registry entry or a winecfg checkbox option.

[oiaohm]

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.

Please note I said button effects. Different installers have there own custom text effects and the like some are done in dx7. Some games wanted the installer to have something that looks like their in game menus. Its one of those horrible ones where you would expect a dx11 game if it was using dx in the installer to use dx11 as well but they did not and its not even dx9. They had not got the memo that Dx7 was going to be deprecated or their license to sell the game would run out first so they did not care. Since dx7 would work and they could recycle their old installers this saved those companies work.

https://docs.microsoft.com/en-us/windows/desktop/directwrite/how-to-implement-a-custom-text-renderer

Basically you start doing this then take a horrible turn to hell as a programmer and do something in dx7.

This is not windows gpi back end going down to DX7. This the problem with the way installer has themed itself and this is basically in newer games using custom installers from windows 9x. Just think about how many 32 bit applications failed to install when Microsoft removed 16 bit mode because their installers were 16 bit. Companies have bad habit of using installers until they don't run any more. Worst at times gluing odd bits on.

[JoshuaAshton]

Saying that people should just chuck non-vulkan supporting graphics cards is just nuts. Laptops that are 7-8 years old (Sandy Bridge) still perform perfectly fine for office and audio production purposes. Throw an SSD and 16GB of DDR3 RAM in and those machines fly. No, it is unreasonable to expect people to upgrade perfectly functional hardware now that CPUs have slammed into Moore's law for the average person's needs. It's only high end gaming and video/3D production that need faster systems. Most end users have no need for faster computers. They are mostly being forced to upgrade by vendors deciding to drop security support for fully functional equipment. I understand why a Vulkan backend would be good for DirectX in WINE, and I support the developers trying to add it, but I don't support the deprecation/removal of the GL backend, especially when the equivalent functionality hasn't been reached, and that shouldn't just be a tick list of features, but should involve detailed application testing to prove the equivalent functionality is there. Much better to have the two backends be switchable with a registry entry or a winecfg checkbox option.

You do know how cheap and inexpensive Vk hardware is these days right?

[oiaohm]

Or just develop Interop for our current Apis as they are. Also you haven't proved that hybrid apps use any Interop at all, they probably just call two different state trackers without any connection.

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

Read. To be correct the output buffer generated by dx9, dx10, dx11 and dx12 need to be going to the same dxgi interface. Application can directly talk to dxgi about buffers in play. Buffer swapping rules are written into dxgi.

Your output is required to be connected. You need to be able to get information about all the buffers at play.

Currently wined3d and dxvk have totally incompatible implementations of dxgi. dxvk does not have a opengl dxgi link as of yet.

The wined3d route of adding Vulkan support to wined3d makes sense. So you expand implementation of dxgi to support opengl and vulkan buffers.

Please note both dxvk and wined3d are cheating at the dxgi point by using either opengl or vulkan buffers instead of buffers formated the same as windows. Interop by transforming the output buffers to the same on cpu/gpu for the dxgi stage will cause performance overhead. Please note not all buffers that get past dxgi ever get displayed on screen so if something is never going to be displayed the final transformation does not need to be done.

For applications that are opengl/dx hybrids using opengl dx with opengl buffers equals less transformations so less overhead. dxgi alway using vulkan buffers is not right.

There is a output state tracker at the dxgi level.

Really stop this call two different state trackers.

dx9ex dx10 dx11 dx12 are all using the same state tracker on output being dxgi and opengl by extension access the state tracker. Yes you have other shader state trackers as well but this is not where the conflit is. It the output state tracker where the conflit is.

Problem is when you get to dxgi you need the buffers you are dealing with to be compatible.
If you have full vulkan dxgi you need opengl dx7-12 to be handing over vulkan compatible buffers.
If you have a full opengl dxgi you need opengl dx7-12 to be handing over opengl compatible buffers.

Can you do a half vulkan/opengl dxgi the answer is no you cannot buffer transformation cost will kill you. Also if you decide to have vulkan process only opengl compatible buffers you will be limiting vulkan performance.

Wine project had the idea as well like you that they would be able to leave dx 1 to 11 as opengl and do dx12 as vulkan and do a interop at dxgi. Yes the dxgi state tracker of output kills you because its depending to perform well that you made the correct choices when you made the output buffers and does not have the processing time to mess around converting buffers layers above them have sent them across in incompatible formats.

This is why I said what happens after the AMD-IL that runs right processing a buffer then that buffer get merged with other buffers to be displayed. dxgi is controlling that merge stage. Merging incompatible buffers formats cost more processing time that you really don't have by the time you have got to dxgi.

This is like the car crash model where first car sees something hits the breaks and drives on then next car hits breaks and drives on this repeats enough time and then two car crash into each other.

Problem happens in dxgi state tracker caused is in opengl dx7-12 rendering choice of output. So have to choose Vulkan or Opengl output buffer types before you get to the dxgi. Having 2 output buffer types when you hit dxgi is not workable.

Restricting only to Opengl buffer types for output also does cause overhead and would cause dxvk to run slower. So at a min wined3d to run well with dxvk has to be updated to support enough vulkan to make vulkan output buffers compatible to dxvk and both altered to use the same dxgi.

[skeevy420]

You do know how cheap and inexpensive Vk hardware is these days right?

In that user's defense, those external GPUs aren't what I'd consider to be inexpensive.

But that topic gets into the area of at what point should developers drop support of micro-architectures (or not support from day one) both due to older ones becoming less used and newer ones becoming more used. For a great example, my CPU is a Westmere and I have to live with the fact that I can't use Clear Linux, try the PS4 emulator, and other things due to not having AVX...not complaining since I knew that going in and just wanted cheap and capable hardware that suited my needs...

IMHO, y'all going with Vulkan and up GPUs isn't any different than Clear targeting AVX and up CPUs or random Linux distributions not supporting 32-bit CPUs. Sometimes it's necessary to draw a line.

[rmoog]

Sometimes it's necessary to draw a line.

Gentoo. We've got optimizations for everything.

[oiaohm]

In that user's defense, those external GPUs aren't what I'd consider to be inexpensive.

But that topic gets into the area of at what point should developers drop support of micro-architectures (or not support from day one) both due to older ones becoming less used and newer ones becoming more used. For a great example, my CPU is a Westmere and I have to live with the fact that I can't use Clear Linux, try the PS4 emulator, and other things due to not having AVX...not complaining since I knew that going in and just wanted cheap and capable hardware that suited my needs...

IMHO, y'all going with Vulkan and up GPUs isn't any different than Clear targeting AVX and up CPUs or random Linux distributions not supporting 32-bit CPUs. Sometimes it's necessary to draw a line.

The line is set by the customer group you are servicing.

https://www.cip-project.org/wp-content/uploads/sites/17/2018/10/CIP_Whitepaper_10.19.18.pdf

Infrastructure products face product life-cycles of 10 to 60 years.

Notice my quote 10 to 60 years. So Linux in 2 years will be 30 years old. This is only half the life span of support Civil Infrastructure wants. Opengl at least 10 years into the future is being down right conservative. Worst case Opengl 4.6 was releaseJuly 31, 2017 so we need to support that until July 31, 2078 to support infrastructure applications built when the infrastructure was made.

Those saying dropping opengl have no clue the nightmare the Civil Infrastructure world is.

[wyatt8740]

If your graphics card doesn't support Vulkan. Honestly, just toss it.

No one's made a laptop I like since around 2011. I'll toss my Thinkpad X201 tablet over my cold, dead body.
And I shouldn't need to have Vulkan support just to play a windows game from 1998. (MS Combat Flight Simulator, Unreal, or a nearly 20 year old version of AutoCAD).

I'm already maintaining a fork of a seven year old version of Dolphin (gamecube emulator) for the sake of playing one or two relatively low-demand gamecube games; Wine works on my laptop just fine as is and I'd be happy to keep a fork of it limping along for a similar duration.