Direct3D 9 Support Proposed For DXVK

[F.Ultra]

Hm, but that's what AMD, NVidia etc. have been doing. They don't seem to have much trouble supporting all versions of D3D, OpenGL and now Vulkan in drivers, by leveraging a low-level core API and hardware interfaces. Especially since older fixed-function / high-level / inflexible APIs make it really difficult to map functionality precisely due to slight mismatches in semantics and behavior (just look at wined3d mapping D3D9 to OpenGL).

Incidentally, D3D9 may map nicely to D3D10, no arguments about that.

And how many man hours have AMD and nVidia put into that effort? if GabrielMajeri would put in similar effort (s)he would probably be finished in a millennia or two.

[R41N3R]

Hello everybody, I'm the original author of the pull request, and I would like to add some information related to the project.

First of all, a lot of people keep asking me why didn't I just contribute to VK9 / Gallium Nine. The answer is quite simple:

I believe it would be too hard to convert D3D9 directly to something as low level as Vulkan or similar. Look at how complicated VK9 / Gallium are.

That is why I am building on top of doitsujin's work. His project does the hard part of implementing a D3D11-to-Vulkan wrapper. It handles Command Stream Multithreading, manages textures and buffers for me, etc.

If you check out the VK9 source code, you will notice it contains a huge amount of similarities to DXVK. Why reimplement some common Vulkan utilities, when I can simply take advantage of doitsujin's library?

I only closed the pull request because I have now moved to my own repository (https://github.com/GabrielMajeri/d3d9-to-11). I should have done so from the beginning, but I instead experimented by forking DXVK's repository. It's better for me to maintain this project and doitsujin to focus on DXVK.

Great to hear that you want to continue. It looks definitely promising and I believe it is good to not reinvent the wheel again. It is understandable that some projects want to focus to avoid being flooded by new targets that have been not on their original road-map, but a separate branch sounds promising.

[oiaohm]

It makes sense in a lot of ways to do d3d9 on dx11 back end. In fact might make more sense to be on a dx12 backend yet..

https://docs.microsoft.com/en-au/windows/desktop/direct3d11/overviews-direct3d-11-devices-downlevel-intro

Feature levels are fun. You write a direct x 11 program and you can have it request a Dx9 feature level so you need to implement dx9 shaders. You had the same problem with Dx10.

https://docs.microsoft.com/en-au/windows/desktop/direct3d11/d3d11-graphics-reference-10level9

Yes the 10 and 9 reference on what behaved differently if you request or get told you have a 10/9 feature level.

Once you understand feature level the question them comes with winehq developers are working on dx12 VKD3D the question comes how much overlap back to dx11,dx10,dx9 will the VKD3D have and will be required to handle application feature level requests on dx12.

This also explains why wine developers were going what the hell with gallium nine having no interest in dx10,dx11.... Because it just does not make sense target only 1 version of direct x long term because they are interconnected by design. Dx12/11/10 need dx9 features to be complete.

It for sure makes sense to do dx 8 to dx11 on the same stack. A few have proven dx8 to dx9 redirection works. It could be perfect sense to do dx8 to dx12 on one stack.
dx1-7 kind of have to remain own stack that is where there is a true compatibility break.

Microsoft direct x did not reinvent the wheel with most version update but they did keep on stacking wheels next to each other so now we are looking at a car with insane number of duplicate wheels in the newest version.

[artivision]

It makes sense in a lot of ways to do d3d9 on dx11 back end. In fact might make more sense to be on a dx12 backend yet..

https://docs.microsoft.com/en-au/windows/desktop/direct3d11/overviews-direct3d-11-devices-downlevel-intro

Feature levels are fun. You write a direct x 11 program and you can have it request a Dx9 feature level so you need to implement dx9 shaders. You had the same problem with Dx10.

https://docs.microsoft.com/en-au/windows/desktop/direct3d11/d3d11-graphics-reference-10level9

Yes the 10 and 9 reference on what behaved differently if you request or get told you have a 10/9 feature level.

Once you understand feature level the question them comes with winehq developers are working on dx12 VKD3D the question comes how much overlap back to dx11,dx10,dx9 will the VKD3D have and will be required to handle application feature level requests on dx12.

This also explains why wine developers were going what the hell with gallium nine having no interest in dx10,dx11.... Because it just does not make sense target only 1 version of direct x long term because they are interconnected by design. Dx12/11/10 need dx9 features to be complete.

It for sure makes sense to do dx 8 to dx11 on the same stack. A few have proven dx8 to dx9 redirection works. It could be perfect sense to do dx8 to dx12 on one stack.
dx1-7 kind of have to remain own stack that is where there is a true compatibility break.

Microsoft direct x did not reinvent the wheel with most version update but they did keep on stacking wheels next to each other so now we are looking at a car with insane number of duplicate wheels in the newest version.

Many people trying to tell you the self-evident for months now: When you ask people if they would consider a change to Linux, 90% of the time, subject ends with games and smartphone suites (usb) in consideration. Yes that you say for months is the correct implementation, but it does matter only for a 10% of the potential users. As it requires a lot of job, this can be done in the future.

[oiaohm]

Many people trying to tell you the self-evident for months now: When you ask people if they would consider a change to Linux, 90% of the time, subject ends with games and smartphone suites (usb) in consideration. Yes that you say for months is the correct implementation, but it does matter only for a 10% of the potential users. As it requires a lot of job, this can be done in the future.

Wine project early on did not care about correct implementation. Incorrect implementations of direct x cause other issues like document loss when using MS Office because a extension dies. Its not people playing games paying codeweavers the most money. Its you so called 10% of the potential users who pay.

Lot of people don't think windows cost anything as it was part of the PC they bought so suggesting they pay extra for wine does not fly right.

He the hard facts most of those who attempt to tell me different are not paying customers.

USB device support(that covers your smartphone suites) in wine has been started many times never completed because no one has ever funded the developer/s todo it developers do need to pay bills and eat. Please note I know it can work with old patches and manually creating the USB device tree it works of course no user wants to have to manually create the USB device tree every time they plug in their phone. Please note the USB support was first done for supporting itunes for updating ipods.

DXVK has that same problem that it may turn into nothing more than experiment that in 5 years time is like wine USB support attempts lost to history. VKD3D developers are getting a wage from codeweavers.

I am sorry 90% might say something but you have to care about the 10% who pay. The 10 percent who pay don't in fact care that much about games as they are normally using wine to run legacy windows applications for business reasons. Breaking horrible coded business applications upsets them more. Yes horrible coded is like applications using dx9, dx10 and dx11 in 1 application because coders at different times added bits to applications with the idea at some point the old part of application would be updated and it never has been. The wrappers appearing for dxvk are now moving it to a location where it could work. Lot of ways games are easier problem than what those paying want.

Please note those paying with enterprise applications that are horrible don't care about performance as top requirement they care that the program works even if it insanely slow.

Horrible coded enterprise applications means direct x has to be implemented right way or at least cover enough that they can work to be merged in wine mainline. Not like codeweavers can risk it income without codeweavers getting income that is the core developers lost from the wine project.

Lot of ways you have to move from this idea that wine has to support X stuff and instead work out how to get the money to fund developers so wine can support X stuff. Hacks that only make limited number of applications work long term do not fly. Supporting only 1 version of direct x is a hack supporting only a limited number of applications.

DVXK with wrappers from dx8, dx9, dx10 on top of DVXK dx11 support would be supporting a very broad number of applications so would be able to truly compete for mainline include. Of course it does come should the dx8, dx9, dx10 wrappers point to VKD3D instead with a wrapper from dx11 to VKD3D to support from dx8 to dx12.

artivision my point of view is not moving and its not going to. Items like guiluim nine and vk9 are kind of doomed in their current forms they can never support broad number of applications..

[artivision]

Wine project early on did not care about correct implementation. Incorrect implementations of direct x cause other issues like document loss when using MS Office because a extension dies. Its not people playing games paying codeweavers the most money. Its you so called 10% of the potential users who pay.

Lot of people don't think windows cost anything as it was part of the PC they bought so suggesting they pay extra for wine does not fly right.

He the hard facts most of those who attempt to tell me different are not paying customers.

USB device support(that covers your smartphone suites) in wine has been started many times never completed because no one has ever funded the developer/s todo it developers do need to pay bills and eat. Please note I know it can work with old patches and manually creating the USB device tree it works of course no user wants to have to manually create the USB device tree every time they plug in their phone. Please note the USB support was first done for supporting itunes for updating ipods.

DXVK has that same problem that it may turn into nothing more than experiment that in 5 years time is like wine USB support attempts lost to history. VKD3D developers are getting a wage from codeweavers.

I am sorry 90% might say something but you have to care about the 10% who pay. The 10 percent who pay don't in fact care that much about games as they are normally using wine to run legacy windows applications for business reasons. Breaking horrible coded business applications upsets them more. Yes horrible coded is like applications using dx9, dx10 and dx11 in 1 application because coders at different times added bits to applications with the idea at some point the old part of application would be updated and it never has been. The wrappers appearing for dxvk are now moving it to a location where it could work. Lot of ways games are easier problem than what those paying want.

Please note those paying with enterprise applications that are horrible don't care about performance as top requirement they care that the program works even if it insanely slow.

Horrible coded enterprise applications means direct x has to be implemented right way or at least cover enough that they can work to be merged in wine mainline. Not like codeweavers can risk it income without codeweavers getting income that is the core developers lost from the wine project.

Lot of ways you have to move from this idea that wine has to support X stuff and instead work out how to get the money to fund developers so wine can support X stuff. Hacks that only make limited number of applications work long term do not fly. Supporting only 1 version of direct x is a hack supporting only a limited number of applications.

DVXK with wrappers from dx8, dx9, dx10 on top of DVXK dx11 support would be supporting a very broad number of applications so would be able to truly compete for mainline include. Of course it does come should the dx8, dx9, dx10 wrappers point to VKD3D instead with a wrapper from dx11 to VKD3D to support from dx8 to dx12.

artivision my point of view is not moving and its not going to. Items like guiluim nine and vk9 are kind of doomed in their current forms they can never support broad number of applications..

I don't know about you friend but i was a manager on something in the past. I can tell you for sure that Codeweavers should drop the development of WineD3D and focus to advance other Wine libraries plus to develop the last connection bits for D3D implementations others made. Also forget about OpenGL.

[oiaohm]

I don't know about you friend but i was a manager on something in the past. I can tell you for sure that Codeweavers should drop the development of WineD3D and focus to advance other Wine libraries plus to develop the last connection bits for D3D implementations others made. Also forget about OpenGL.

OpenGL cannot be forgot about at least for another 15 years without directly losing customers. Enterprise can run hardware for up to 30 years.

Most of the D3D implementations others have made don't work with each other. Just like wined3d the DVXK multi dx solution will not work properly with galluim nine or VK9. WineD3D is still need for Dx1-7 there is no other alternative at this stage. Remember you still have enterprises running applications that they use to run on Windows 2.0 on wine and paying money so they can.

artivision funny saying drop Wined3d when no complete replacement exists.

DVXK does offer at least broad enough coverage to possibly be expanded to be a proper competitor to wined3d.

VKD3D is targeting dx12 first no other party is working on that either.

Really artivision suggesting dropping some thing when suitable replacement does not exist even if you manged to assembled all the bits different groups have made you must have been one very incompetent manager.

[artivision]

OpenGL cannot be forgot about at least for another 15 years without directly losing customers. Enterprise can run hardware for up to 30 years.

Most of the D3D implementations others have made don't work with each other. Just like wined3d the DVXK multi dx solution will not work properly with galluim nine or VK9. WineD3D is still need for Dx1-7 there is no other alternative at this stage. Remember you still have enterprises running applications that they use to run on Windows 2.0 on wine and paying money so they can.

artivision funny saying drop Wined3d when no complete replacement exists.

DVXK does offer at least broad enough coverage to possibly be expanded to be a proper competitor to wined3d.

VKD3D is targeting dx12 first no other party is working on that either.

Really artivision suggesting dropping some thing when suitable replacement does not exist even if you manged to assembled all the bits different groups have made you must have been one very incompetent manager.

Simple management directions:
1. Linux it self doesn't support 30 years hardware any more. No clients there!
2. 3D design apps don't run correctly on emulators, they demand native api exact behaviour. No clients there!
3. OpenGL is made to be used as native, not as base. There is Vulkan for this job. No progress can be achieved here!
4. If they have money to pay me, then they have money for new hardware. Always work with Standards!
5. The manpower can be used to develop the connection points between VK9-8UP-DXVK-10UP-VKD3D-OGL. Best manager ever the middle man!

[oiaohm]

1. Linux it self doesn't support 30 years hardware any more. No clients there!

This is what you call not being up to date.

https://www.cip-project.org/announcement/2017/10/22/civil-infrastructure-platform-announces-the-release-of-cip-core

Yes mainline Linux attempted to drop supporting old hardware. Civil Infrastructure you know the ones that pay money to run really old software have started maintaining their own kernel supporting 30 year old hardware.

This old hardware is going to be running on video cards that don't support vulkan. So unless a decent wrapper from vulkan client program to opengl backed appears we are kind of stuck maintaining the opengl backend support for another 15 years.

2. 3D design apps don't run correctly on emulators, they demand native api exact behaviour. No clients there!

Except a lot of enterprise applications have little areas of direct x they do work quite well with software rendering. This are not games this can be like a 3d graphic of pipe work inside a plant. Not needing game class performance 1 to 2 frame per second good enough.

3. OpenGL is made to be used as native, not as base. There is Vulkan for this job. No progress can be achieved here!

VKD3D is the new development from codeweavers. wined3d is fairly much in maintenance and repair mode.

4. If they have money to pay me, then they have money for new hardware. Always work with Standards!

Civil Infrastructure is a true pain in ass it can take up to 10 years to certify hardware for usage in that environment and then another 5 to get approval to deploy. So its not just having the money it is the bureaucracy. So new hardware in particular areas of Civil infrastructure is all 15 year old hardware. This kind explains why they got upset when Linux kernel started dropping 30 year old hardware support.

5. The manpower can be used to develop the connection points between VK9-8UP-DXVK-10UP-VKD3D-OGL. Best manager ever the middle man!

Problem here is this idea cannot work as you described internal modifications. The require connection point between dx9 to dx11 is the allocate of memory. Why because a resource allocated in dx9 function call has to be free-able by a Dx11 function call with the reverse as well. This means VK9 is dead path having it own unique allocate system for dx resources means it worthless. Direct3D 9 for DXVK being worked on now is a possibility. 8UP is not a problem as it not its own allocate system but using the dx9 one.

Next release of DXVK will be Dx10 and dx11. In time DXVK could be dx9, dx10 and dx11. This would mean when VKD3D is more functional it would be work out how to use 1 allocator under DXVK and VKD3D so supporting programs for Vista and newer using direct x to Vulkan.

There is also a curve ball in XP and before Nvidia drivers provided an opengl extension to use direct x allocated bits in opengl and opengl allocated bits in direct x back in that time frame yes this does include allocating something in opengl and freeing it in direct x and the reverse.

wined3d putting direct x 9 and before on a opengl backing to have the same allocator between opengl and direct x allows supporting particular programs made for XP and before.

Basically your list contained 4 allocators. VK9, DXVK, VKD3D and OGL. VK9 can be nuked from list it going to be a pointless project just like galluim nine will be long term same mistake of only making framework to support 1 direct x version and basically become superseded by DXVK direct x 9 support.. OGL what is wined3d allocate system we need for XP and before applications using particular Nvidia extensions to opengl these legacy programs.

So I see wined3d needing to be maintained for a while yet. Call for the end of wined3d when people are not using XP and before applications using Nvidia extensions to share resources.

One of the hard things to learn is that opengl and direct x under windows is sharing the same allocator because the allocator is performed by the hardware vendors drivers. That shared allocator gives behaviours windows applications expect. So independent projects implementing independent versions of direct x are paths to hell because they end up with a allocator per version that is no how it is in Windows.

Really the correct thing for codeweavers management todo is sit back and see what projects get designed the way they should and in the end support the winner who has done the right things. DXVK is winning that at this stage.

[adelpozoman]

I have less fps on GTA IV than on GTA V because IV uses dx9 and V dx11, therefore DXVK.