RSX: wait when emulation is paused (reduces CPU usage)

[Megamouse]

This decreases my cpu usage in GMPADTEST from ~9% to <1% during Emu.Pause() (together with the other pad_thread PR)

[Megamouse]

I'm sure there's a better way.
But at least this raises awareness. WAKE UP

[elad335]

Should be at rsx::thread::cpu_wait() while using the state value argument. (currently unused)

[kd-11]

Relates to #9641, specifically pausing this way will make that ticket unactionable. Maybe add fixes link for that to this PR then.

[Megamouse]

Maybe we can simply add a 16ms wait to the main loop instead.
I'll test the impact on CPU usage.

Maybe it's time to implement that pause screen 🤣

[kd-11]

You can do it the same as shader loading dialog, just create a custom interface with low opacity that is updated every 16ms and calls flip in the update method, then trigger update from inside the paused loop. Just remember to destroy it once the pause ends.

[Megamouse]

We can still pause rsx regardless of the issue ticket and the pause dialog though, until someone implements either.

I just don't see a reason to destroy the planet any more than we have to for no reason.

[kd-11]

That was my original argument in that other ticket, you either waste resources drawing a pause screen or you leave it empty. Since the choice is to conserve resources and you are the reporter of the other ticket, I really see no point in handling it. Or do you still want a pause screen? Remember it will literally undo some of the power savings here.

[Megamouse]

There are a couple of things to consider here:
For example once we have pause screen we can still pause RSX while the window is minimized.
And I still think it's weird that we can't access the last frame. Either through Qt shenanigans or by accessing some kind of framebuffer

[elad335]

Accessing last frame would be nice for savestates "start paused" loading mode as well, currently it just waits till one more frame is rendered then pause.

[kd-11]

The problem is how the OS handles painting the window - if you resize/minimize/move etc it is up to the application to handle the event, otherwise the window is just going to have garbage in it. Of course for this to happen would mean RSX thread has to be awake to repaint everything and this causes another hilarious problem - you cannot tell that the window size changed without polling unless you set up your own notification hooks.
Combine these 2 requirements and suddenly you cannot really keep RSX asleep, you have to keep waking it periodically to poll and handle events.

[kd-11]

I'm not saying its not doable or anything, just that it will eat up some system resources for visual consistency. I can set up the basic framework for it if it is decided to go that route, but RIP power savings is going to be the problem.

[Megamouse]

But if it's event based then you can just wake up the thread for a blip and do the necessary work in one iteration can't you?

[kd-11]

But if it's event based then you can just wake up the thread for a blip and do the necessary work in one iteration can't you?

It is not event based, I explained that above. It is event-based from the OS level (win32, X11) but not on our side (Qt, Vulkan)
e.g The easiest way to tell that you can safely resize your vulkan window is to try and draw something on it and the driver will return a code that tells you you need to refresh the swapchain. Or you can poll window size changes - again this depends on the driver. The way I see it, we will need some kind of periodic refresh going to trigger this, which will mean sending things to be rendered (you can just call flip(0) for the last flipped image)

[MSuih]

Can't we catch the event with Qt?

[kd-11]

Can't we catch the event with Qt?

I remember this does not work. Previously there was some Msq injection I had added to gsframe that allowed me to snoop on the win32 activity before the driver could start acting on it, but it ended up being really dangerous and it was removed. it has to do with timing, if you catch a QT event, wake up and do something, you must be sure the driver does not trash your decision immediately after. Things my have improved since then, though I haven't really checked.

[kd-11]

Since there is still a lot of discussion, let's keep the other ticket open then. I'll have to check later the best place to add the sleep.

[kd-11]

Ramblings:

1. rsx::thread now derives from cpu_thread which has some simpler ways of checking if paused without being stopped. You can just check if state & (cpu_flag::dbg_global_pause + cpu_flag::exit) == cpu_flag::dbg_global_pause to check if only pause is enabled. However, this isn't even necessary due to point 2...
2. As elad mentioned, we already have some logic to optionally pause things in cpu_wait() wich is called every iteration whenever test_stopped() is called. You should add your sleep in there based on the state value. You should even just sleep once (16ms) and let the system continue which allows RSX to keep operating in a low power mode and is able to react to other requests such as screen refreshes and such.

[Megamouse]

Updated PR with the suggested solution (hopefully correct).
Tested with pausing and also stopping while being paused.