I have no idea how you even use DXVK D3D9 in VR and I don't own the game, so we need you to bisect the performance regression down to a commit.
Thanks for your response. That's the problem, I use slightly modified DXVK that I build myself, it's not exactly the same as main branch (it adds VR API and exposes few additional settings via .conf). That's why I did not provide logs (yet)
I want to help, I am just not sure given that I am running Windows and my own fork is it even worth collecting stuff? Will apitrace still help or am I on my own here?
EDIT: ok I see your edit, so bisect is the only way. I'll see what I can do...
I somehow strongly doubt the lockless stuff itself can be responsible here since it's just traversing a list that's always uncontested during actual gameplay anyway. Only thing I could imagine is that the game compiles hundreds of variants of certain pipelines and doesn't like that the order of those is reversed now, but yeah, we'll either need an easy way to reproduce the regression or some debugging from your end.
I agree with you, there have been a lot of changes and it's possible I made a mistake on rebuilding/merging.
Yesterday I realized that I need to reproduce regression in 2D, based on main branch binary and if I can still detect it I'll get apitrace, I'll try that next week. Thanks for your time.
EDIT: managed to do some quick testing, it is not my rebuild mistake. I have two branches one of them contains merge of everything up to 2/18, another has changes from 2/19 on top (up to 80f744549f1c8051bf). I still can repro regression. Not sure what constitutes as a lot of pipelines, but scene reports 9000 pipelines. I know that game renders same stuff mutlitple times: cars, shadows, rain reflections, headlights each does pretty much a full pass...
I see regression even in 2D (130FPS vs 110FPS) so I guess next is apitrace. Would you accept apitrace from my binaries (does it work with fully optimized stripped binaries?), or you need them strictly from master? My build is very similar, it's just additional interface exposed (used only in VR) and 2 extra settings exposed: brute force sample shading and force 32bit float depth.
I got a chance to capture a trace. I was also able to confirm regression repros in 2D with code without my changes at all, master, and is caused by commit(s) between 8e116303704a4e07179 and 80f744549f1c8.
Trace: https://1drv.ms/u/s!ApNCoFDyNnCJhMtq1EBazaktQe1nRA?e=4nKZCQ
Log: https://1drv.ms/u/s!ApNCoFDyNnCJhMtrMXD42-yDk1JEHw?e=zibKB2
Might be related, I also think that with latest changes message "Compiling shaders" stays in HUD longer, but I need to test much more... I guess next is to find the exact commit :)
I can't open the archive, what software was used to create it?
Looks like I uploaded incomplete archive, sorry, re-uploading (it's .zip created by 7z)
Here it is: https://1drv.ms/u/s!ApNCoFDyNnCJhMtq1EBazaktQe1nRA?e=4IGeSf
BTW, trace is not related to DXVK, it is independent, right?
Thanks, this one works. And yeah, apitrace is its own thing.
Please, let me know how I can help further (although I may not have time till Thursday).
my effort is a mess - game is old and outdated, it has hard time even starting in regular DX9 mode. I have plugin that fixes several startup issues, and part of that plugin is in d3d9.dll proxy. So, apitrace is not exactly how game is used (because I can't use my proxy), but hopefully it helps. And, thank You All very much for DXVK, it is amazing and will allow to keep GTR2 alive for years to come.
I'm seeing up to 27 variants being created for a single pipeline, so yeah, there might be extra overhead when the game wants specific variants more often than others. Can you verify whether it really is 67e2ee1b2635f6867d3c92a14192bffb1c026d33 that's causing the issue?
Thanks for looking. Yes, i will revert that commit when i get a chance and get back to you.
Btw this same graphics engine is used in dozen of racing simulators. Based on what you seen in the trace, do you have any suggestions on how can I tweak dxvk to speed up that family of games?
I'm still trying to work out if the thing that I think might be causing a perf loss actually does so.
Ok, this can't really be it. The average number of lookups is higher with the previous code, at least during the actual gameplay segment. Only reason why it could still potentially be slower is CPU caching effects, but that's... more or less impossible to improve upon with the lock-free approach, and should not really be an issue anyway if the same few pipelines are used over and over again.
Also worth noting that I haven't seen any performance regressions in D3D11 titles yet.
Thanks for looking. The scene I am using to test is very much CPU bound. Luckily I have only handful of commits to try, I'll let you know if I find anything.
I can confirm that performance drops ~20% as soon as I cherry pick 67e2ee1b2635f
My processor is 10900K with HT on.
Yes, it fixes the drop! (is it faster because loop is gone in insert*)?
I am closing this issue. I understand that you may not be interested in making a change to please one game engine (gMotor in this case). I will have to maintain a tweaked version in my fork. Thank you for crafting a fix (I am not experienced with lockless programming much, so this is new to me). Much appreciated.
d3d9.dllx1 2022-02
I have been testing changes done on master between 2/18 and 2/19 (lockless stuff) merged into my fork, to my surprise I am seeing regression in my scenario where I am using DXVK in DX9 mode in VR. In heavy CPU intense scene framerate dropped from 58FPS to 47FPS. Before I collect more data I need to know if it is needed, because I am on Win10 and very convoluted setup.
Reports with no log files will be ignored.
Software information
GTR2 x86, Win10 x64, SteamVR/OpenVR
System information
Apitrace file(s)
Log files