random guess: You're running out of VRAM. 4GB is pretty much required on Nvidia GPUs for DXVK to run anything adequately, especially if you don't close literally every single background application.
Well I ran it this time in openbox so I can get the exact VRAM usage from nvidia-smi.
In both the "good" and "bad" states the VRAM usage was the same at 285 - 290 mb. (Note that VRAM usage will be significantly lower thanks to my 800x600 resolution)
The only difference was that in the "bad" state it used 760MB of RAM while in the good state it used 820MB (Doesn't seem like a big difference)
And yeah the original trend of lower CPU usage persisted. Using htop for monitoring the game used 197% in the "good" state 151% in the "bad" state.
Lower CPU usage happens whenever GPU usage is high, that's probably happening for... some reason. Please check DXVK_HUD=full and compare between good and bad runs.
Anyway, can't really do anything here. Also, note that driver support for Kepler is ending, so we won't be able to support it going forward (in the sense that DXVK should keep working, but if there are driver/performance issues we'll probably just ignore them).
GPU usage both states are 100% according to MangoHud. Like I have mentioned in the bad run the cpu usage matches to a single core workload and the good run it matches a two core workload.
And again the results say consistent no matter how many times I reopen the game until I reboot the PC. After which it may either be in the good or bad state.
And the fps different between both runs and significantly different and all observations are consistent.
Will observe the complete hud tomorrow
I just don't see a bug here, DXVK spawns a fixed number of threads of its own and the main load is going to be on the application side anyway for the most part. If CPU usage is low, it's because the GPU can't go any faster, why the GPU can't go any faster on certain boots on your system is not something we can diagnose.
It seems to be a dxvk issue since I have done Vulkan Benchmarks and run other games as sanity checks and they run at the same performance as they always do.
Plus yeah the thing about how on all good boots dxvk uses the buffer resolution 806x612 and on bad boots it chose 800x600. This is the only visible difference between boots on dxvk
Try wine virtual desktop or something to rule out window management weridness.
I don't know what the benchmark is doing (especially since we don't have an apitrace), and I'm inclined not to care as long as it is limited to one specific system with one specific game.
Anyway I seem to have found the problem. For some reason on bad boots the affinity for TestDrive2.exe is set to only use CPU3. The game probably assumes only one core is available so does dxvk and thus the low CPU usage.
Changing the affinity once the game is started doesn't change anything, still runs at low fps.
Using schedtool or taskset to set affinity at startup doesn't work.
Doesn't seem that the /affinity flag for start.exe in wine does nothing on any Windows Executable run with it.
Anyway will check for other ways to fix the problem. Doesn't seem to be related to dxvk but rather related to wine itself.
@doitsujin Thanks for your time :) <3
Changing the affinity once the game is started doesn't change anything, still runs at low fps. Using
schedtoolortasksetto set affinity at startup doesn't work. Doesn't seem that the/affinityflag forstart.exein wine does nothing on any Windows Executable run with it.
I haven't tried any of the TestDrive games, but I've had this issue in other cases. taskset 0xf on the running process (some seconds after the game has started, not on startup) should fix things. Some older games actually only work well using the first core (taskset 0x1) and slow down to slideshows on any other cores for some reason, so your mileage may vary. Anyway, hope this helps, and yes, it is a known Wine issue. Wine also doesn't handle process priorities, so yeah...
@WinterSnowfall I had already tried creating a while loop that finds the PID of the game and sets does taskset 0xf every 0.5 seconds. It didn't work.
@WinterSnowfall I had already tried creating a while loop that finds the PID of the game and sets does
taskset 0xfevery 0.5 seconds. It didn't work.
0xf will target CPU3 exclusively, so if that's what was giving you issues in this case, then clearly it's not the solution. It should work with a different mask like 0x1, or one that targets multiple cores maybe. You'll have to try until you find something that works for the game. See here: https://linuxhint.com/use-taskset-command/
DXVK_HUD=full`x1 2021-10
DXVK performs bad on some system boots and performs well on certain boots.
FPS during "bad" boot state : 20 - 30
FPS during "good" boot state : 60 - 80
Other observations:
dxvklog hadBuffer size: 806x612and during "bad" boots thedxvklog hadBuffer size: 800x600Sanity Checks Done:
Software information
Test Drive Unlimited 2
800x600 resolution
All low settings
System information
470.74-1wine-tkg-staging-fsync-git 6.19.r6.g688eeca0-326(Same results onwine-staging 6.16-1)asyncpatch)linux-zen-5.14.12.zen1-1(Same results onlinux-5.14.12.arch1-1)Apitrace file(s)
Log files
Sorry about the non raw log files.
The raw log file from a "good" boot state
The d3d11.log and dxgi.log were empty
I might test on other games later (when I get some)