Rpcs3: Linux abnormally high rsx thread usage under vulkan

[Whatcookie]

This issue is a bit weird.

I was doing some profiling of rpcs3 performance when I noticed that the rsx thread was spending a lot of time in libQt5.

Switching over to opengl quickly showed that it wasn't spending any time at all in Qt. First I tried downloading the appimage build to see if it was a problem with my qt libs, but the appimage showed the same issue.

I then did some digging and nailed it down to the "check_window_status" function in VKGSRender.cpp

Commenting out the function led to performance getting a massive boost under vulkan when the rsx thread was under load. Now next to no time is being spent in Qt and resizing the window still seems to work most of the time. (I did get it to bug out though with keyrepeat rate set to 1000 times a second while holding down alt+enter)

I then went to see if it was reproducible under windows. I launched into ninja gaiden sigma, and found the performance to be even lower than on linux. I then set out to install visual studio and comment out the function there as well. I had expected it to be a much bigger problem on windows since the function that gets called there is so much bigger.

In the end though, I couldn't see any performance gain from commenting it out under windows... it did make me unable to resize the window though, as expected. Launching it again with the visual studio profiler showed no real amount of time spent in Qt.

2 things were made evident though: windows performance on ninja gaiden sigma is not good enough in the demanding areas (small usleep values requiring too much overhead?), and linux spends way too much cpu time with "check_window_status" structured the way it is.

Some comparison images:

Windows no hack

Windows with hack

Linux no hack

Linux with hack

(This area was used because it was reproducible. Several other areas with combat perform worse but the AI makes it difficult to reproduce.)

Hardware/Software details

Archlinux 5.0.10

Radv 19.0.3
[email protected]
RX 570
+whatever the latest windows and amd driver are

Sorry for the giant wall of text. Should I open another issue for the low performance of ninja gaiden sigma under windows?

[kd-11]

To remove that you then need to set up a window notification system to pause /unpause if the window changes dimensions. To see the negative impact of this, just resize the game window when the game is running with the hack. Afaik there are no windowing notifications on Qt which sucks for us since vulkan is extremely sensitive to the underlying surface DC matching exactly with the swapchain under some drivers (NVIDIA). The other option is to disable all window resizing (this includes maximizing) and only have application-driven resizing allowed the way commercial games do this, but this is undesirable.
Not all is lost, I think that routine can be temporarily disabled when running in fullscreen since transition to/from fullscreen is application driven (i.e we are aware of it before it happens). It does require some refactoring in places though and is not straightforward. This mess is there because the nvidia windows driver is very finicky about window dimensions and often crashes if you don't completely stop rendering before touching the underlying window's properties.

[Whatcookie]

Sounds good.

Should I open another issue for the gap between windows and linux performance for ninja gaiden sigma? It doesn't manage to max out the rsx thread but still performs much worse than linux.

[kd-11]

I'm not too optimistic, timing on windows is a nightmare; its just an OS limitation. I'm not sure there is anything much that can be done about it unless you have an i9. Maybe after we close this one.
This issue is linked with https://github.com/RPCS3/rpcs3/issues/5351 with the code in question being a workaround for other bugs in the same subsystem.

[arabek]

The other option is to disable all window resizing (this includes maximizing) and only have application-driven resizing allowed the way commercial games do this, but this is undesirable.
Not all is lost, I think that routine can be temporarily disabled when running in fullscreen since transition to/from fullscreen is application driven (i.e we are aware of it before it happens).

Yes! Please! There is no valid use case for user to resize the window apart from switch to/from fullscreen
anyway. It could be that the debug options would allow setting the initial window w/h size, but nothing more.

[kd-11]

Ended up refactoring a bit and only aggressively polling on drivers that do not handle window reports correctly.