D9VK might make direct3d 9 games perform better

[JZStudios]

3 minutes ago, ryao said:

What matters is whether they used fixed function shaders or programmable shaders. The fixed function shaders are mostly not implemented yet. Anyway, you could just drop the files into the directory and boot the game.

 

As for VAC bans, if you are concerned, then it is better not to risk it. However, it would be really strange if Valve banned someone for using D9VK or DXVK. They not only pay for their development, but also ship them for use on Linux as part of Proton. Banning someone for using software on Windows that they tell people to use on Linux would be really weird.

Eh, it's what the guy said on the Github.

[PlayStation 2]

Well, I do have an old ass throwaway account on Steam that I could probably use to test and see if VAC would trigger.

[ryao]

9 minutes ago, JZStudios said:

Eh, it's what the guy said on the Github.

I will see if I can get clarification from Pierre-Loup Griffais of Valve on this.

[Mira Yurizaki]

2 hours ago, ryao said:

You claimed that Direct3D was somehow at a disadvantage. It isn't. They both run in userspace (and there really isn't a penalty to doing that given that the game itself is in userspace). The code just isn't as good. Microsoft likely could make it better if they wanted.

Direct3D 9 has a disadvantage against anything modern. On top of what @trag1c mentioned, there are actual limitations that the shader models the API was designed around. It doesn't matter what memory space the API or the wrapper is in.

 

What I'm saying is the only reason why there's any performance uplift is because the wrapper may be able to figure out there are better ways to do what D3D9 wanted, not including any of the general benefits of simply using the API. I feel that in addition of trying to translate one API call to another, it's to make it perform better by doing things better. I mean, this sort of thing is great for Linux, but if there were no benefits on Windows, there wouldn't really be much of a point in using a wrapper over native the D3D9 render path.

[ryao]

18 minutes ago, Mira Yurizaki said:

Direct3D 9 has a disadvantage against anything modern. On top of what @trag1c mentioned, there are actual limitations that the shader models the API was designed around. It doesn't matter what memory space the API or the wrapper is in.

 

What I'm saying is the only reason why there's any performance uplift is because the wrapper may be able to figure out there are better ways to do what D3D9 wanted, not including any of the general benefits of simply using the API.

Direct3D 9 is an API. The Microsoft Direct3D 9 library and the D9VK both implement it. Everything that D9VK does to implement D3D9 could be done behind the scenes in the Microsoft library. Any fundamental issues in the API apply to the library no matter what the implementation is. However, D3D9 and D3D10/11 are extremely similar to each other. Any technique that speeds up a library implementing one of them will speed up a library the other.

 

As for the shader model, it is the same under D9VK. The shader model is a shader programming language and intermediate representation. That code is written by the game developers. You cannot change a game’s shader model without changing the game itself. It would be like saying that a new library switched the game’s language from C++ to Java and that is the reason that the new library makes things faster. That is clearly wrong. The newer library is simply better code.

 

The performance uplift comes from lower CPU requirements because GPU performance has grown far faster than CPU performance, causing the CPU to bottleneck. Microsoft had the ability to custom tailor everything to benefit their library. They left inefficiencies that they found in the code on purpose that were removed in their implementation of direct3d 10 (or even added some to cut development costs and encourage use of direct3d 10). That is the reason why some people find D9VK to be faster. In reality, D9VK is at a disadvantage since it does not have the ability to pass the D3D9 DXBC to driver shader compiler directly and must work around differences in the design of Vulkan and Direct3D. It is reportedly outperforming Microsoft’s code despite that.

[Mira Yurizaki]

18 minutes ago, ryao said:

D3D9 is an API. The Microsoft library and this library both implement it. Everything that this library does to implement it could be done behind the scenes in the Microsoft library. Any fundamental issues in the API apply to the library no matter what the implementation is.

I don't believe it works that way. Let's take emulators for instance. ePSXe with DirectX plugins can go beyond what the PlayStation GPU was capable of even though it implements the PlayStation GPU for games to use. To take this argument you're presenting is like saying no PlayStation emulator can go beyond what the PlayStation GPU was capable of because of the limitations of whatever the PlayStation was using.

 

I mean if that wasn't enough, there's a speed-up technique when emulating CPUs or implementing certain ISAs known as dynamic recompilation. This can lead to the host machine running the application faster than the target hardware when normalized.

 

Quote

However, D3D9 and D3D10/11 are extremely similar to each other. Any technique that speeds up a library implementing one of them will speed up a library the other.

I don't see how they're "extremely similar" when they're vastly different in terms of feature set and hardware requirements, at least to do to everything in said API's feature set. Plus the drivers are responsible for handling API calls. Anything Microsoft did in D3D10 or D3D11 is not automatically going to affect D3D9 unless Microsoft actually applied those same changes. Which is doubtful considering, again, the limitations, requirements, and design differences between the versions.

[ryao]

34 minutes ago, Mira Yurizaki said:

I don't believe it works that way. Let's take emulators for instance. ePSXe with DirectX plugins can go beyond what the PlayStation GPU was capable of even though it implements the PlayStation GPU for games to use. To take this argument you're presenting is like saying no PlayStation emulator can go beyond what the PlayStation GPU was capable of because of the limitations of whatever the PlayStation was using.

I am a software developer, although my area is not in graphics. I have talked with the developers working on these things. It works exactly the way that I said.

 

Your emulator remarks ignore the reality that before/after in native hardware vs emulators involves entirely different hardware. That is not happening here. The hardware is the same, the OS is the same and the graphics API library was changed for one that implements Microsoft's API more efficiently.

Quote

I don't see how they're "extremely similar" when they're vastly different in terms of feature set and hardware requirements, at least to do to everything in said API's feature set. Plus the drivers are responsible for handling API calls. Anything Microsoft did in D3D10 or D3D11 is not automatically going to affect D3D9 unless Microsoft actually applied those same changes. Which is doubtful considering, again, the limitations, requirements, and design differences between the versions.

They are similar enough that the techniques used to speed up one will speed up another, provided that they apply the techniques equally to both libraries. The slowdown is from them not doing that, which means that you are agreeing with me.

[JZStudios]

So I don't know much of anything about any of this, but after doing a few games dropping the x64 dll contents into the game root folder I've come to the conclusion that either A. It's not working, or B. it's not giving any performance change.

 

Someone mentioned DX9.0c, and I didn't actually make note of which game I have that actually uses that, and in the case of Dirt 2 it might just be using DX11 anyways. The other games just run so fast anyways, it might only be a problem on Linux. Mount &Blade I set the FPS limit to 300 and there it stayed. Figured you don't need much more than that.

 

I also tried to do the environment thing, but either did it wrong, or it's further proof that just dropping the .dll's in the game folder actually does nothing.

[ryao]

2 minutes ago, JZStudios said:

So I don't know much of anything about any of this, but after doing a few games dropping the x64 dll contents into the game root folder I've come to the conclusion that either A. It's not working, or B. it's not giving any performance change.

 

Someone mentioned DX9.0c, and I didn't actually make note of which game I have that actually uses that, and in the case of Dirt 2 it might just be using DX11 anyways. The other games just run so fast anyways, it might only be a problem on Linux. Mount &Blade I set the FPS limit to 300 and there it stayed. Figured you don't need much more than that.

  

I also tried to do the environment thing, but either did it wrong, or it's further proof that just dropping the .dll's in the game folder actually does nothing.

Most Direct3D 9 games are 32-bit. You want to use the 32-bit version. The 64-bit version will have no effect on 32-bit games because it won't be loaded. The HUD not appearing confirms that D9VK is not being used.

 

A Hat in Time is the only 64-bit Direct3D 9 game of which I am aware.

[JZStudios]

Just now, ryao said:

Most Direct3D 9 games are 32-bit. You want to use the 32-bit version. The 64-bit version will have no effect. The HUD not appearing confirms that D9VK is not being used.

 

A Hat in Time is the only 64-bit Direct3D 9 game of which I am aware.

Ugh. Fine, I'll try it again.

 

For arguments sake, here's what I did in the environment thing.

[ryao]

3 minutes ago, JZStudios said:

Ugh. Fine, I'll try it again.

 

For arguments sake, here's what I did in the environment thing.

The value should be set to 1, not DXVK_HUD=1. It is fine to just be a system variable. If the HUD does not appear, there is no point in testing.

[JZStudios]

1 minute ago, ryao said:

The value should be set to 1, not DXVK_HUD=1. It is fine to just be a system variable. If the HUD does not appear, there is no point in testing.

I've never done a system environment, so alright, I'll do that.

[ryao]

1 minute ago, JZStudios said:

 I've never done a system environment, so alright, I'll do that.

You did both. Also, it occurs to me that you might need to log out and log back in after setting it for it to take effect. Otherwise, while the library might be used, you won't have any indication to tell you that it is in use.

[JZStudios]

Okay, well I did the environment thing, and it worked this time. Didn't log out, just set it and went.

It's not looking good for DXVK in Win7 at least.

 

Age of Wonders 3             zoom 115 far 55        zoom 96.5 far 50

Dirt 2                                 avg 96.1 min 76        crashes, less FPS in menu

Halo Custom Edition         94                             60 offsets screen

Lego The Hobbit               170                           155

Satellite Reign                  32                              32

The Bureau                      103                            85

Torchlight                         195 500+ menu         230 rendering issues 370 menu

This War of Mine             144 framerate lock    118

Nvidia driver version        419.35

 

My results are a little messy, but to sum up, as a base I just loaded saves and eyeballed the average after awaiting for FPS to settle (30-60 sec.)

AOW3, loaded save, took average FPS at full zoom in and out.

Dirt 2 has a benchmark, DXVK causes crash in benchmark but oddly not in game menu. Removing DXVK and running another clean benchmark gave me figures nearer 101fps.

Halo CE, DXVK somehow, despite the game running in full screen, manages to push the image up and to the left, spilling over on second screen.

Torchlight, I didn't note the exact startup in-game menu FPS on a clean run. DXVK ran at 370. Once in game DXVK had shading issues.

TWOM has a framerate lock of screen refresh rate, and couldn't go above 144, so it's likely the performance dip is greater than actually visible.

[ryao]

2 hours ago, JZStudios said:

Okay, well I did the environment thing, and it worked this time. Didn't log out, just set it and went.

It's not looking good for DXVK in Win7 at least.

 

Age of Wonders 3             zoom 115 far 55        zoom 96.5 far 50

Dirt 2                                 avg 96.1 min 76        crashes, less FPS in menu

Halo Custom Edition         94                             60 offsets screen

Lego The Hobbit               170                           155

Satellite Reign                  32                              32

The Bureau                      103                            85

Torchlight                         195 500+ menu         230 rendering issues 370 menu

This War of Mine             144 framerate lock    118

Nvidia driver version        419.35

 

My results are a little messy, but to sum up, as a base I just loaded saves and eyeballed the average after awaiting for FPS to settle (30-60 sec.)

AOW3, loaded save, took average FPS at full zoom in and out.

Dirt 2 has a benchmark, DXVK causes crash in benchmark but oddly not in game menu. Removing DXVK and running another clean benchmark gave me figures nearer 101fps.

Halo CE, DXVK somehow, despite the game running in full screen, manages to push the image up and to the left, spilling over on second screen.

Torchlight, I didn't note the exact startup in-game menu FPS on a clean run. DXVK ran at 370. Once in game DXVK had shading issues.

TWOM has a framerate lock of screen refresh rate, and couldn't go above 144, so it's likely the performance dip is greater than actually visible.

It is D9VK, rather than DXVK. Reports were that it was doing better on CPU limited hardware and also AMD graphics (possibly also with Mesa-ACO) but scattered reports were being made that it was outperforming the Windows native library on Nvidia hardware too.

 

Thanks for doing the benchmarks. I had made this thread because I wanted to find out if what people actually experienced matched what was being reported. It would seem that is not the case.

 

By the way, what hardware did you use to test?

[trag1c]

7 hours ago, ryao said:

I heard that the benefits come from reducing CPU overhead. D3D9 games tend to be CPU bound, so lower CPU overhead increases performance.

In a sense they were but that doesn't necessarily mean that the CPU was getting hammered. The API it self was simply slow to use and execute. Operations on the CPU side may have been stupid fast but when it came to manipulation on the GPU the operations may have been slow for no particular reason. 

 

It was a mixture of being CPU bound and the fact the GPU wasn't being used to what we now know to be correctly.

 

The API it self was also highly unconfigurable as large portions of the function pipeline was fixed so you were reliant on somebody else code to do what you need it to do. Where as now there 3/10 stages are fixed function. These 3 stages are fixed since programming them would be a waste of time since what they do are very specific. Since most of the pipeline is programmable now you are in complete control as to whether your game runs great or like a piece of flaming dog shit.

[JZStudios]

3 hours ago, ryao said:

It is D9VK, rather than DXVK

Everything in the Github and the files it creates and references itself as DXVK.

3 hours ago, ryao said:

By the way, what hardware did you use to test?

A "last gen" system.

AMD FX 8350

Nvidia GTX 960 2gb

16gb DDR3

 

Running at... high on most games at 1080p.

Another thing I find interesting is some of the games are DX9 or DX11, but don't seem to have a clear indication of which is being used, I'm assuming it's using whatever the "best" the system is compatible with, so it may be for some games without DXVK it's running DX11. I don't really know.

[ryao]

33 minutes ago, JZStudios said:

Everything in the Github and the files it creates and references itself as DXVK.

A "last gen" system.

AMD FX 8350

Nvidia GTX 960 2gb

16gb DDR3

 

Running at... high on most games at 1080p.

Another thing I find interesting is some of the games are DX9 or DX11, but don't seem to have a clear indication of which is being used, I'm assuming it's using whatever the "best" the system is compatible with, so it may be for some games without DXVK it's running DX11. I don't really know.

The project that forked DXVK to make a version that includes D3D9 support is called D9VK (although I am not sure what it is called on the later D3D versions when the bundled DXVK libraries for D3D10 and D3D11 are used). When the D3D9 version is being used, it is called D9VK. You could set DXVK_HUD to “api,version” (without the quotes) to see what is being used. It will report D3D9 when D3D9 is being used.

 

Anyway, it is early code that is under active development. In the future, the rendering issues and crashes that you encountered will likely be fixed. Performance might go up somewhat too, although I do not expect that much there, barring compiler improvements from Nvidia. Remarks from others had made me wonder if it was beginning to do better than the native Windows code everywhere, but from your results, it is clear that is not the case.

[ryao]

On 8/4/2019 at 2:38 PM, JZStudios said:

On the Github it says it may cause VAC bans... so.. I'm going to skip Insurgency. The real issue is A. Most of the games I have aren't DX9, and B. half the ones I do have are like Hacknet or FTL and... what's the point? Some of the other ones have FPS limits in place that I pretty much already hit.

So current available games to me for testing are:

Age of Wonders 3

Dirt 2

Halo Custom Edition

Lego The Hobbit

Mount & Blade

Satellite Reign (FPS locked to 100, but I now only get 40-50)

The Bureau XCOM declassified

Torchlight

 

Seems like Splinter Cell is DX8... most of those are also not DX9,0c.

I have attached a screenshot of a statement from Valve regarding this. In short, you do not need to worry about being banned as long as you are not cheating.

 

Also, I have heard separately that the DXVK developer put that there because of bans that Destiny 2 does to people trying to play it in Wine using Linux in general. Most anticheat solutions won't ban you for using a third party Direct3D implementation. If they did, people would be banned simply for having corrupted files.

[JZStudios]

Okay, well good to know, but I'm not betting on DXVK making Insurgency run any better to go through the hassle of setting it up again.

[ryao]

1 hour ago, JZStudios said:

Okay, well good to know, but I'm not betting on DXVK making Insurgency run any better to go through the hassle of setting it up again.

The direct3d 9 fork is D9VK. Anyway, I don't expect it to make a difference for you if you didn't see an improvement in the other games that you tried.

[Kisai]

On 8/4/2019 at 8:47 AM, ryao said:

D9VK is a fork of DXVK that reimplements Direct3D 9 in Vulkan (DXVK does Direct3D 10/11). Its development is funded by Valve. It is not yet feature complete as the fixed function stuff used by older games is not yet implemented, but many games work on it. I have heard from the D9VK developer and others that D9VK is outperforming the native Windows Direct3D 9 implementation both in Wine on Linux and on Windows itself. A Hat In Time was explicitly named, but other games reportedly perform better with it too.

 

You can use D9VK on Windows by getting the DLLs and dropping them into the game directory before launching it. If you set the DXVK_HUD environment variable to 1 on your system, it will add a HUD to the game that will indicate that it is working:

 

https://www.techjunkie.com/environment-variables-windows-10/

 

I only run Linux, so I can not confirm those claims. Would someone playing Direct3D 9 games on Windows try it out to see if it really performs better? Here is a link to the downloads page for the binaries:

 

https://github.com/Joshua-Ashton/d9vk/releases

 

Using it requires a vulkan capable GPU such as the Radeon HD 77xx–7900 Series and later for AMD, a Kepler or later GPU for Nvidia or a Skylake or later iGPU for Intel. That is on Windows. In the case of Intel graphics on Linux, Broadwell should be compatible. You should make sure that you have the latest drivers before trying this.

 

Well I don't know if the claim is true, since you need a feature-complete D3D9 implementation to have a fair comparison.

 

However, It would never be as good as a native vulkan port of the game, because of how threading is handled, D3D9 and earlier games are effectively single-threaded on the rendering pipeline, and that will not change with the wrapper. What changes is how the resources are handled, so a large performance gain is theoretically possible if a game relies on a lot of fixed texture assets, as there won't be any c++ runtime memory management getting in the way. If it streams things to the card, or does a lot in software, I doubt the performance will see as much improvement.

 

I tested it against a known D3D9 game demo (FFXIV Exploration demo https://www.guru3d.com/files-details/final-fantasy-xiv-a-realm-reborn-pc-benchmark-download.html ) but it doesn't launch with this wrapper (dlls must be in the game subdirectory with the ffxiv.exe .) In instead tried the FFXIV original 1.0 benchmark ( http://http.download.nvidia.com/downloads/nZone/demos/FFXIVBenchmark.zip ), and the D3D9 VK wrapper is slower and glitchier (missing geometry every few frames) but I suppose if it was a playable game, it would at least be playable.

 

XIV V1.0 D3D9: 5353, load time 12928ms

XIV V1.0 D3D9VK: 5153, load time 12310ms

 

This is probably within the realm of error.

 

[ryao]

On 8/5/2019 at 10:48 PM, JZStudios said:

Okay, well good to know, but I'm not betting on DXVK making Insurgency run any better to go through the hassle of setting it up again.

I installed Windows 7 on a spare SSD and did my own testing with A Hat in Time. Jumping on the cheeseburger while looking at the room in the space ship does ~170 FPS with D9VK on my GeForce GTX 1070 with the 431.60 nvidia driver. It does ~150 FPS with the native implementation. There is some stutter introduced, but that disappears after the first time an effect is encountered thanks to the pipeline cache (even between runs). Looking at the planet from the cheese burger has a FPS drop from ~250 FPS to ~220 FPS, but I am more concerned about situations where FPS is low gaining FPS than situations where FPS is high losing FPS.

 

Anyway, the gains are there in certain titles.

[ryao]

On 8/6/2019 at 3:18 AM, Kisai said:

 

Well I don't know if the claim is true, since you need a feature-complete D3D9 implementation to have a fair comparison.

 

Adding features won't make a difference in performance if the code being executed remains the same. Support for additional features tends to not affect code execution unless the code being executed needs substantial changes to support additional features when the additional features are used.

[JZStudios]

3 hours ago, ryao said:

Jumping on the cheeseburger while looking at the room in the space ship. Looking at the planet from the cheese burger

I understand none of this.