NVIDIAGameWorks
[Runtime Bug]: Regression in Perf, Input Response, and Stability Between Bridge Versions - Star Wars Republic Commando
Describe the bug
A bug happened where... the game runs with unresponsive keyboard inputs, significantly reduced performance, and a consistent crash after two or three minutes of play. (Note: This is a separate issue to my previous Bridge regression report).
Unresponsive Inputs: Keyboard input for all in-game actions has either significant input delay, or the key doesn't register at all, requiring multiple keypresses to work. The delay mentioned is long enough that the game isn't close to reasonably playable. I want to say it's over 600ms (yes, six hundred) at the absolute bare minimum. Combine that with inputs sometimes not registering, and the game is a no-go to play with Remix. Mouse input works fine.
Significantly Reduced Performance: Performance vs previous Bridge versions is significantly reduced. When using a bridge version without these issues, 90-120fps is common on my hardware/settings. Using this Bridge version, it's roughly in the mid to upper 40fps range with framepacing issues/stutters. The performance seems to decline until the game crashes, though I'm not as confident on that claim.
Consistent Crash: After two to three minutes of play, performance is well below reasonable levels and the game will crash. This happens every time without fail.
How do you reproduce the bug?
Using commit 0037ec6 of the Remix Bridge, the issues are consistently reproducible after loading into a level. These issues are not present one Bridge version prior, that being commit c099b40.
What is the expected behavior?
The runtime should... have reasonable performance roughly in line with previous versions of the Bridge. The game should also have responsive controls to make for a playable experience. Crashing should not occur after just a couple minutes of play. The issues aren't present in the prior version as stated in the reproduce bug section.
Version
0.5.1 - Bridge manually updated
Logs
Crash dumps
NvRemixBridge.exe_20240615_235058.dmp
Media
No response
REMIX-3328 for tracking
@NV-LL I found more info relating to this issue. It seems to be based on input. When moving my mouse, the WASD/keyboard inputs in-game suffer from either massive delays or there's no input registered at all. When not moving my mouse, WASD/keyboard input works perfectly. The performance degrading over time also seems to be input related, as performance degrades over time with more inputs AND when I let go of the controls and sit there idle, even with gunfire and explosions going off over and over, my framerate shoots back up to a comfortable 120. Once I use my inputs again, fps drops as low as it was before I started standing still and the crashing issue occurs shortly after. Game never crashes when I let go of the inputs and wait. I think this is critical to discovering the underlying cause of the issue so please take this into account :)
EDIT: The massive performance dips also fall in line with CPU usage. When idle in an active game scene, my 7800X3D is around 45% utilization. When I start using inputs again it raises up to 55%. When letting go, it drops back into the mid 40s. As you might expect this is also dramatically dropping GPU utilization at the same time. Normally in the high 90s, it drops several dozen percentage points as the CPU usage goes up from inputs
@automata-rtx
We were not able to repro the issue reported with the binaries specific to the version mentioned. To further debug, we have built some custom binaries that would give us more insight into the issue being faced. Could you please test the game with both versions of attached binaries and update us with logs?
Note: Attached binaries only contain bridge-remix binaries ( Existing dxvk-remix binaries for the version reported in the bug should work with these) .
InputTest-Bridge-Binary-v2.zip InputTest-Bridge-Binary-v3.zip
CT_d3d9.log d3d9.log NvRemixBridge.log
^here are the logs of the "v2" bridge binary you provided. Issue remains and is exactly how I remember it
CT_d3d9.log d3d9.log NvRemixBridge.log
^ v3 binaries. same issue.
Thanks this helped in isolating the issue a bit.
Could you try with this attached binary to verify if it makes a difference? InputTest-Bridge-Binary-v4.zip
@lvengesanam
So sorry for the delay! Great news though, arguably the biggest issue (for the development of my mod at least) has been resolved. After a few minutes of play my performance level stayed about as expected.
Logs: CT_d3d9.log d3d9.log NvRemixBridge.log
However the issue of input responsiveness remains. That is, when my mouse is active my keyboard inputs are delayed and/or don't register at all. When my mouse is idle (not moving) then the keyboard inputs work as expected. If this can be resolved then the issue as a whole should be fixed. Thanks for your help so far and sorry again for that delay.
@automata-rtx
No issues. Thanks for the update. Glad performance issue was resolved.
Could you please test with attached binaries to see if it makes a difference wrt keyboard issue and update us with logs from both the binaries? InputTest-Bridge-Binary-v6.zip InputTest-Bridge-Binary-v5.zip
Additionally with mouse input, do you notice the issue with any mouse movement or just with mouse button clicks?
While testing could you see if mouse movement or mouse clicks alone cause the issue you are facing?
@lvengesanam
To clarify regarding the mouse input, the delayed/failed keyboard inputs issue only occurs with concurrent mouse movement. If I spam click or hold click, the keyboard inputs are still fully responsive. So if the mouse isn't moving, there are no problems. Behavior is unchanged on the v5 build.
V5 Logs:
CT_d3d9.log d3d9.log NvRemixBridge.log
More good news, V6 appears to have fixed the issue. There is no performance degradation over time or crashing, and keyboard input stays about as responsive as expected even with concurrent mouse movement input.
V6 Logs: CT_d3d9.log d3d9.log NvRemixBridge.log
Only reason I use the word "appears" is because it's still not especially responsive, but I believe how it's working now is representative of the underlying game's KBM controls.
For both tests I loaded up a save at the start of a level and played to about 1 minute into the following level.
@automata-rtx
That is great! Thanks for testing it.
I have attached two additional binaries. One is with the fix on the branch you had seen the issue and the other one is with the fix made on TOT. With TOT bridge binary, you should use TOT remix binaries from - https://github.com/NVIDIAGameWorks/dxvk-remix. InputTest-Bridge-Binary-TOT-Branch.zip InputTest-Bridge-Binary-Old-Branch.zip
Could you test them both extensively to make sure the fix works for you on TOT too?
@lvengesanam did a few hours of playtesting between each build. The fixes are still working, the issues aren't present. The TOT bridge test version even works perfectly with the Remix API part of my project which is great to see, when configuring the bridge.conf to expose the API.
However due to simple oversight I only have logs for the TOT test version, in which I used the latest remix dxvk alongside it. Here are those logs:
CT_d3d9.log d3d9.log NvRemixBridge.log
I did notice a new issue relating to mouse input in the runtime overlay but I believe I've resolved this previously via bridge.conf settings changes, so I don't think it's anything to worry about for this specific case. If you need anything else let me know, but as far as I can tell everything's working as it should in regards to the issue I originally reported. 😊
@automata-rtx
No issues with the missing logs. TOT was the critical one. Great to hear that TOT works fine too! Thanks for all the help with testing!
We will push this fix soon and will update this bug once its done.
@automata-rtx
Fix has been pushed - https://github.com/NVIDIAGameWorks/bridge-remix/actions/runs/11240816667.
Could you close the bug if everything works as expected?
@lvengesanam Glad to report that the fix still works perfectly. Thanks for everything! Closing