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

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?

Is the game x32 or x64

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

made several quick tests with wine 5.0 (144 fps lock for my monitor), looks pretty good

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

Just for testing? :)

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.

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 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: #1281 (comment). If me setting up the build environment is faster than waiting for someone to build it, then I will get back with some results :)

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.

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.

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.

@AlexTMjugador

1. be sure that vulkan installed into your machine (with nvidia gpu just don't use too old nvidia-driver)
2. unpack x32/d3d9.dll into same folder with TmForever.exe and TmForeverLauncher.exe
3. 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)

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

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.

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

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

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

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


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

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.

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.

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.

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:

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?

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

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

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.

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

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

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.

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.

@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.

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

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.

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.

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: Winetricks/winetricks#1482 Winetricks/winetricks#1481

@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.

@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.

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

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

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