[d3d9] TrackMania United Forever: almost half perfomance compared to Windows 10 native

AlexTMjugador commented 4 years ago

Software information

Under Debian Bullseye, kernel version 5.3.0-3-amd64 #1 SMP Debian 5.3.15-1 (2019-12-07) x86_64 GNU/Linux, with DXVK 1.5.1, TrackMania United Forever version 2.11.26 has almost half of the performance than Windows 10 (version 10.0.18362.592), on the same hardware, track and graphic settings. The achieved performance is on par with WineD3D (≈60 FPS), while on Windows, using the NVIDIA 440.41 driver, I get ≈100 FPS. Other than that, the game plays fine and frametime graphs follow almost the same curve (there are some minor frametime differences due to shader compilation, but I didn't notice them while playing).

I've tried running DXVK 1.5.1 under Windows for comparison, but the game fails to launch with a 0x0000022 error, no matter if it is run with administrator privileges or not. For some reason, the game also fails to launch under Windows with that same error if it doesn't have administrator privileges. I've used the workaround mentioned in issue #1278.

The attached apitrace traces opening the game, selecting the A1 track, playing it until the finish line on the first try, and then closing the game.

The performance loss is the same across tracks and environments.

System information

CPU: Intel Core i3-2100 @ 3209 MHz (BCLK overclocked to 103.5 MHz from 100 MHz. Worked fine since 2012, and I highly doubt this has anything to do with the issue, but I mention it anyway).
GPU: NVIDIA, MSI GeForce GTX 1650 Ventus XS.
Driver: Debian Bullseye NVIDIA propietary driver, 430.64 (package version 430.64-5).
Wine version: wine-4.21 (Debian 4.21-2).
DXVK version: 1.5.1. I haven't tried with master; should I in this case?

Apitrace file(s)

TmForever.trace.tar.xz (233.7 MiB): https://mega.nz/#!jU122aZQ!YUh7PvjfcS1l7Ov0SJe-l0Mlq_f7KJYSToj74oXFFDE

Log files

d3d9.log: https://pastebin.com/egzg5BH9 (debug level).
d3d11.log: DX9 game, not applicable.
dxgi.log: DX9 game, not applicable.

Screenshots

Windows 10 DX9 (MSI Afterburner overlay)

GNU/Linux DXVK 1.5.1

GNU/Linux WineD3D

misyltoad commented 4 years ago

You can't compare across Windows/Wine for DXVK performance comparisons.

It'd need to both be compared on Windows 10 for me to actually know if this is my issue or not.

As for why that doesn't work? I have no idea. If it needs Windows compat modes to run then youll need an MSVC build

AlexTMjugador commented 4 years ago

Sure, I can try out that MSVC build. Thank you for the prompt response. However, where am I supposed to download it from? I've tried with https://github.com/doitsujin/dxvk/releases/download/v1.5.1/dxvk-1.5.1.tar.gz, both x32 and x64 DLLs, but neither of them work. Should I compile this from source?

misyltoad commented 4 years ago

Is the game x32 or x64

Iglu47 commented 4 years ago

file TmForever*
TmForever.exe:         PE32 executable (GUI) Intel 80386, for MS Windows
TmForeverLauncher.exe: PE32 executable (GUI) Intel 80386, for MS Windows

game fully x32

Iglu47 commented 4 years ago

made several quick tests with wine 5.0 (144 fps lock for my monitor), looks pretty good 2020-01-23_08-56-10

SveSop commented 4 years ago

@AlexTMjugador Somewhat old driver tho? 430.64 440.44 is latest released driver, and 440.48.02 is latest "Vulkan" driver.

Just for testing? :)

leucome commented 4 years ago

Just to be sure are you aware that your screenshot for windows is 900p while the linux one is 1080p. 1.4 megapixel vs 2 megapixel can account for 30% performance. Add to this number about a 10% loss from DXVK and Proton you get about 40% slower.

If these screenshot resolution are true this lower FPS is likely be close to expectation.

doitsujin commented 4 years ago

The game is completely CPU-bound so resolution should have no impact on performance whatsoever.

Also I'd argue that 50% of Windows performance while using an Nvidia GPU, a fairly weak CPU and on an old Debian system that's probably not at all optimized for gaming workloads and might easily be 20% slower than necessary isn't really a bug but expected.

AlexTMjugador commented 4 years ago

@AlexTMjugador Somewhat old driver tho? 430.64 440.44 is latest released driver, and 440.48.02 is latest "Vulkan" driver.

Just for testing? :)

Indeed it's a bit old, but installing the latest drivers from the NVIDIA website has proven to be a pain for me in the past, and I don't think that a game so old as this got much attention recently from the NVIDIA drivers. I prefer letting the distribution handle the X server configuration, module blacklisting and so on in a neat package. But I will test more recent versions soon anyway :)

If these screenshot resolution are true this lower FPS is likely be close to expectation.

Thank you for pointing that out. I guess I resized the screenshot without really meaning it before uploading, so that's why they're different. The game was actually played at the same resolution in both OS, 1080p fullscreen.

Also I'd argue that 50% of Windows performance while using an Nvidia GPU, a fairly weak CPU and on an old Debian system that's probably not at all optimized for gaming workloads and might easily be 20% slower than necessary isn't really a bug but expected.

My experience with my GNU/Linux installation is that it is really good at managing CPU and I/O resources, better than Windows. I get a tiny better performance under some CPU-bond workloads. And, from a naive point of view, that should translate to more on-par performance. But gaming is another thing, and who knows. Debian is not the first distro that comes to mind for gaming, admittely; it's more security and stability focused, so maybe there's some patch somewhere in the chain responsible for that.

Anyhow, I'd like to try DXVK on Windows, so we can rule out DXVK being responsible for that, but I'm still not able to due to the reasons I stated before. A tip, anyone?

Edit: I've just found some instructions on other issue about how to compile DXVK under Visual Studio: https://github.com/doitsujin/dxvk/issues/1281#issuecomment-566344295. If me setting up the build environment is faster than waiting for someone to build it, then I will get back with some results :)

leucome commented 4 years ago

I found something... Go in the game setting advanced /compatibility and change CPU/GPU synchro from immediate to 1 frame. I got about a 30% FPS improvement in the benchmark with that option, it went from 80 to 105FPS.

I do not know if that option would also improve FPS on windows but it give a pretty good boost in Proton.

Edit: Also by unchecking the "render read back' option I get 117FPS ... I did not see any visual impact but guess this may be used by an effect or something.

The biggest bottleneck seem to be GPU to CPU communication.

leucome commented 4 years ago

Actually I made a mistake. I forgot to use PROTON_USE_D9VK=1 . So it was running with wineD3D.

With PROTON_USE_D9VK=1 I get 55 fps in the benchmark instead of 117.... SO there is really something not working right. I'll install it in wine to try multiple version of Wine/Proton/DXVK/D9VK.

leucome commented 4 years ago

There is an hidden option that kill the fps. If I chose minimum quality preset I get 596 FPS. If i put it back to "preset" "none"l and keep all the same option as minimum the fps drop to 80.
I can not see any visual change between the two.

Benchmark with 1080p resolution with no AA. DXVK... Manual setting at minimum 80fps minimum preset 596FPS medium preset 346FPS Veryhigh preset 30FPS

wineD3D... Manual setting at minimum 171 Minimum preset 290FPS Medium preset 189FPS Veryhigh preset 117FPS

The drop is a really huge with DXVK... It's twice as fast at minimum and 3 time slower at very high.

I'll go look if I can manually edit setting to find what option kill the fps that much with DXVK.

Test done with Manjaro tkg-pds-fsync kernel 5.4.13 mesa 20 aco on a Ryzen 1600 with RX480.

Iglu47 commented 4 years ago

@AlexTMjugador

be sure that vulkan installed into your machine (with nvidia gpu just don't use too old nvidia-driver)
unpack x32/d3d9.dll into same folder with TmForever.exe and TmForeverLauncher.exe
add some environment variables, at the beginning, DXVK_LOG_LEVEL=none (for performance test) or info (for log) and DXVK_HUD=fps,frametimes,gpuload,compiler,devinfo,memory,version,api (for example) - all this variables are described on main page this project. some video here if add into not user variable (how system variable), i guess, need reboot after every edit. but i believe that user variable will be enough

I guess, you will see ~90-95% (maybe less) same fps (if additional hardware resource will be enough)

misyltoad commented 4 years ago

The game appears to be calling GetRenderTargetData every frame which is normally used to take a screenshot.

The problem with that is that it's a blocking call... Howeverrrrr, I think we could app profile this perhaps.

Could you try with this DLL and tell me if it fixes the problem?

d3d9.zip

misyltoad commented 4 years ago

diff --git a/src/d3d9/d3d9_device.cpp b/src/d3d9/d3d9_device.cpp
index f441cf87..eb3160b7 100644
--- a/src/d3d9/d3d9_device.cpp
+++ b/src/d3d9/d3d9_device.cpp
@@ -818,7 +818,8 @@ namespace dxvk {
     // DO_NOT_WAIT not applying after
     // this has happened.
     // (this is a blocking call)
-    WaitForResource(dstBuffer, 0);
+    dstTexInfo->SetDirty(dst->GetSubresource(), true);
+    //WaitForResource(dstBuffer, 0);

     return D3D_OK;
   }

misyltoad commented 4 years ago

Hm, I wonder if perhaps DO_NOT_WAIT maybe just doesn't apply on the pool that was being used before and it isn't meant to block... Anyway, let me know what happens with that.

leucome commented 4 years ago

Yes, Thanks ! It fixed the issue the benchmark result is 130fps with the Very High preset. It literally quadrupled the frame rate.

leucome commented 4 years ago

I lowered the shadow option a little switched to 2844x1600 and added VKbasalt effect cas:fxaa:magicbloom:vignette and still get 175FPS

Screenshot_20200124_001116

misyltoad commented 4 years ago

Hi there, I have a proper solution that I want to push to master.

Can you try this out to make sure everything is still working?

d3d9.zip

Iglu47 commented 4 years ago

diff --git a/src/d3d9/d3d9_device.cpp b/src/d3d9/d3d9_device.cpp
index f441cf87..eb3160b7 100644
--- a/src/d3d9/d3d9_device.cpp
+++ b/src/d3d9/d3d9_device.cpp
@@ -818,7 +818,8 @@ namespace dxvk {
     // DO_NOT_WAIT not applying after
     // this has happened.
     // (this is a blocking call)
-    WaitForResource(dstBuffer, 0);
+    dstTexInfo->SetDirty(dst->GetSubresource(), true);
+    //WaitForResource(dstBuffer, 0);

     return D3D_OK;
   }

i check patch. at first look no big diff xD without_patch with_patch but later i made few ingame bench at highest preset: before patch: 161 157 164 163 fps ~161,25 fps with patch: 162 171 169 166 fps ~167 fps i don't have special program for confirm but looks like minimal fps up too

leucome commented 4 years ago

e

Hi there, I have a proper solution that I want to push to master.

Can you try this out to make sure everything is still working?

d3d9.zip

This one work fine too.

leucome commented 4 years ago

i don't have special program for confirm but looks like minimal fps up too Maybe it's about vulkan 1.2. The RADV driver that I use is vulkan 1.1.107 AlexTMjugador had a vulkan 1.1.99

Maybe it's about using vulkan 1.2. The RADV driver that I use is vulkan 1.1.107 AlexTMjugador had a vulkan 1.1.99.

NorbertHarangozo commented 4 years ago

Hi there, I have a proper solution that I want to push to master.

Can you try this out to make sure everything is still working?

d3d9.zip

This seems to cause crashes for me on Stadium levels, right after the loading screen. TmForever_d3d9.log The first dll worked fine, but the game also worked fine for me on master. Performance was about 50% faster than native, as long as I didn't turn MSAA on.

Settings: Very High preset with all the post process effects enabled.

Specs:

RX 580 4GB
RADV ACO Git (crashes with ACO, LLVM and AMDVLK as well)
Wine-TkG 5.0
Arch

Here's a trace with AMD's d3d9 driver. Neither this one or the one above trigger the crash, but maybe you can find something that's wrong.

AlexTMjugador commented 4 years ago

Wow, I didn't expect this issue would get so many comments overnight. This is definitely some good support!

Back on topic, I can reproduce the results of @ThisNameIsntTaken with both DLL. The first one works and gives a 10 FPS increase on GNU/Linux, so the game plays at ≈70 FPS, which is good. The second one also crashes for me just after the first frame of the stadium track is shown. Both DLL still don't load under Windows, so I can't compare performance between DX implementations on Windows.

Also, speaking of that comment, enabling antialiasing or not in the game settings makes no performance difference for me. I think that's because my old CPU is bottlenecking my GPU hardly, so the GPU has plenty of time to spare doing AA without that actually affecting performance.

I found something... Go in the game setting advanced /compatibility and change CPU/GPU synchro from immediate to 1 frame. I got about a 30% FPS improvement in the benchmark with that option, it went from 80 to 105FPS.

I can reproduce this, too. Setting that advanced option to 1 frame under GNU/Linux, while using the first DLL @Joshua-Ashton posted, boosted the performance to ≈100 FPS, so now it's on par with Windows on default settings! Native Windows DX9 with that setting changed also improves to ≈120 FPS, but the difference is, relatively speaking, narrower and closer to my expectations. Raising the CPU/GPU synchronization to 2 frames doesn’t improve maximum FPS in neither platform, but it has a positive effect in worst frame times (IOW, the game has more smooth FPS).

Also, I'd like to mention I'm not using the preset settings for the game. I chose no present, and then manually pump every non-advanced setting in the configuration window to the maximum (except dynamic colours and motion blur, because I personally don't like them). For reference, these are the settings:

TMUF settings

Someone mentioned things about my Vulkan version, and I realized I didn't provide any explicit, verbose information about it, so here it is the output of the vulkaninfo command: https://pastebin.com/PjGyNyp4

Edit: after trying out the game more, it freezes for me on a Nadeo bay track, with both the provided DLL and DXVK 1.5.1, just after choosing a medal ghost. But not all bay tracks are affected. Maybe that has something to do with the crash exposed by the second DLL?

Iglu47 commented 4 years ago

confirm freeze after choosing a medal ghost track: united => race => bayA1 i checked master-git, dxvk 1.5.1 and d9vk 0.22 version - all 3 freezes and no freezes on default wineD3D first i think that problem with my custom wine, but @AlexTMjugador @ThisNameIsntTaken looks like have a same trouble. need d3d9.log and apitrace^Google Drive...

nvidia proprietary driver: 440.48.2; gtx nvidia 1080ti
Arch Linux, liquorix-5.4.13
Wine-TkG 5.0.r2
DXVK 1.5.1-53-g38a0d2c5

misyltoad commented 4 years ago

I have no way of opening .zst archives on Windows.

AlexTMjugador commented 4 years ago

I've just tested 13792df: the performance increase it's still there, while the crash introduced in the second DLL Joshua attached is fixed for me. I consider this issue resolved, but due to the ongoing discussion about the bay environment crash (which still happens to me) I won't close it yet.

leucome commented 4 years ago

I cant replicate the crash.

But these some additional information... I had the low res texture glitch and fixed it by installing an update over my steam install. And one of the track tat had really big texture issue was bay01. So there may be something related. Or maybe not.

The trick was to set Distro=MILIN in Nadeo.ini . After start the setting and click update it will start the download of the update setup. There the setup in question... http://files2.trackmaniaforever.com/TmUnitedForever_Update_2010-03-15_Setup.exe

NorbertHarangozo commented 4 years ago

I still have crashes on Stadium levels after the first frame as of 6fa28bf.

leucome commented 4 years ago

I still have crashes on Stadium levels after the first frame as of 6fa28bf.

I've been able to get a crash.

It's a Visual C++ error while rendering the lightmap and or shadowmap. If the rendering succeed it wont crash again.

Every track I already played are working whatever the dll. I noticed by trying an other stadium track I had never tried before. And stadiums track really seem to trigger the crash the most it even crash DXVK 1.5.1. So maybe it's not related to change about FPS issue.

A temporary fix is to set light compute to NoShadows or lightmap quality to none in compatibility setting. This way there is no crash but it impact the graphic quality.

And other possible fix lunch the track with wineD3D at least one time.

leucome commented 4 years ago

I tried DXVK 1.5.2 and I do not get any FPS improvement like the earlier test DLL. It's in the description of the new feature still I'm wondering if the change is really there.

Iglu47 commented 4 years ago

@leucome yes, steam (how usually) provides not-latest version game. or can just use standalone edition (2.11.26) link available after authorization in the lower left corner (some add info here). 2.11.26 also no have audio issue through wine, so that makes sense

leucome commented 4 years ago

@leucome yes, steam (how usually) provides not-latest version game. or can just use standalone edition (2.11.26) link available after authorization in the lower left corner (some add info here). 2.11.26 also no have audio issue through wine, so that makes sense

Edit: Fist I thought you it was about steam not providing that latest version of DXVK. But you were talking about the game .

What I meant is that the change is not there in 1.5.2. I manually installed it and the hud report that the version 1.5.2 is running.

I'm reading the change in the code and I think it's only applied to trackmania nation but not track mania united. I need to test this but I'm already 99% sure that track-mania nation will run fast with high fps.

Edit: finally I tested 1.5.2 with Trackmania nation and it's also not better. Maybe there something that prevent the feature to turn on.

Iglu47 commented 4 years ago

i checked more diff wine version for reproduce 'freeze after choosing a medal ghost' need set shader quality to PC3 High or PC3 Low and run some specific track track example: solo => united => race => bayA1

nvidia proprietary driver: 440.48.2; gtx nvidia 1080ti
Arch Linux, liquorix-5.4.13
wine-TkG 5.0.r3, wine 5.0 archlinux binary and Proton-4.15-GE-4
dxvk-git-1.5.2.r2.g9b486515

looks like one more nvidia exclusive bug.

upd2. shader PC3 High - look at the dust from under/after the wheels dxvk-1.5.1-bin no have this ussue with color upd3. i checked for issue like on screenshot - first problem commit - dxvk-git-1.5.1.r55.g6fa28bf9 PC2 no have this issue and freeze issue - so game still good playble

NorbertHarangozo commented 4 years ago

Can confirm. It doesn't crash with Shader Quality set to PC2, I only get the crash when it's set to PC3 Low or High as of 6fa28bf. BayA1 seems to work fine here, regardless of the shader quality setting.

NorbertHarangozo commented 4 years ago

Okay, this is weird. I just updated my Wine-TkG version from 5.0.r0.g3ac1519f to 5.0.r4.g07ef9c93 and it's working fine now. I also tested on Windows and it still crashes there, just like on the older Wine version.

By setting CPU/GPU synchronization to 1 frame on both native and DXVK, DXVK is now ~100% faster than native.

AlexTMjugador commented 4 years ago

It's a Visual C++ error while rendering the lightmap and or shadowmap. If the rendering succeed it wont crash again.

For reference, I'd like to mention that I tested the three DXVK versions for that crash on the stadium A1 track, which I've played before opening this issue. So I think there's more to it than just having played it before. I suspect some kind of race condition?

Edit: I've opened some pull requests in Winetricks for the latest DXVK version, and I have also fixed the master DXVK verb not actually installing master. Feel free to use them if that allows for testing these issues more easily: https://github.com/Winetricks/winetricks/pull/1482 https://github.com/Winetricks/winetricks/pull/1481

leucome commented 4 years ago

@AlexTMjugador Did you try with compatibility setting NoShadows or lightmap quality none ? To confirm that it's not related with generating or loading already lightmap.

AlexTMjugador commented 4 years ago

@leucome I've tried the versions without setting any compatibility setting to a non default value, except setting CPU/GPU synchronization to 1 frame. So lightmaps and shadows were generated in a previous execution, and then applied ingame. But if it didn't crash for me with the latest version, then the crash can't be caused just by applying lightmaps alone. Maybe the commit exposes that crash as a side effect, but applying lightmaps by itself is not the (only?) cause.

About the red dirt smoke on stadium tracks, in my case the smoke doesn't display at all, on DXVK 1.5.2.

Anyhow, although I want to provide useful information to allow debugging the issue, I don't really know if this information is actually useful. And, more importantly, I don't know if it's appropriate to continue this discussion on this issue. It seems so offtopic, considering that the original topic was about performance. What about if we open a issue for the ghost medal freezes, the dirt smoke colour and the stadium crash? Perhaps @Joshua-Ashton and @doitsujin would appreciate it.

leucome commented 4 years ago

Yes there could be a topic crated for the other issue as they are likely to not be directly related.

AlexTMjugador commented 4 years ago

Okay, I've just reported each issue separatedly, so I guess it'd be easier to track their progress, discussion and so on. I'm closing this one as I believe that its original purpose has been fulfilled, but of course I have no problem reopening it if something's wrong about the performance. Thank you all for the insightful comments, and see you in the other issues :D

MatheusFelipe1988 commented 8 months ago

Achei alguma coisa... Vá na configuração avançada do jogo /compatibilidade e altere a sincronização CPU/GPU de imediato para 1 quadro. Eu consegui uma melhoria de cerca de 30% no FPS no benchmark com essa opção, passou de 80 para 105FPS.

Não sei se essa opção também melhoraria o FPS no Windows, mas dá um bom impulso no Proton.

Editar: Também desmarcando a opção "render read back" eu recebo 117FPS ... Eu não vi nenhum impacto visual, mas acho que isso pode ser usado por um efeito ou algo assim.

O maior gargalo parece ser a comunicação GPU para CPU.

I'm now testing these 2 settings and so far it's proving correct, before I couldn't use high shadows due to bottlenecks, i use Windows 11 Single Language :D

doitsujin / dxvk