OpenGL Frame Pacing Problem (not FPS related) - Triggerable #3571
Comments
|
Demonstration (30FPS gameplay): https://www.youtube.com/watch?v=zI0KN80Ccm4 See the description for time stamps. |
|
I updated my initial report, cleaned it up a lot. |
|
I know it probably won't fix it, but can you try dev built 426 or higher also? We did some changes which improve the frame pacing on PCSX2, however it may be unrelated to your issue, would be curious if it made a difference though. |
Nicholas-Steel
changed the title
|
For PCSX2 v1.7.0 Dev 426 and newer, pressing Tab to toggle between 30VI's and 60VI's is the best way to trigger the issue and to recover from it. |
|
I'm not sure I understand you, pressing tab will likely screw the frame pacing because you're basically uncapping your framerate, so you'll get the frames as fast as the emulator can serve them, which could be 14ms one frame and 10ms the next. Or am I just misunderstanding? |
|
For me, Tab doubles the FPS. The emulator gets locked to 200%. I have to go in to the Emulation Settings UI and disable the Frame Rate limiter to get it to increase beyond 200% (500+FPS depending on the situation). VI/s (Vertical Interrupts) is a term used by N64 emulators to help people understand when a game is running at an FPS that differs from the outputted FPS. Like when running a 30FPS game in PCSX2 it'll display 60FPS (which confuses some people in to thinking the game is running like shit at 60FPS) where as for an N64 emulator you'll see 30VI/s, 60FPS and it's a little clearer what is happening. |
|
Yeah I understand the VI thing, I'm just confused on how toggling between 60/120 VI's both cause and fix the issue. Can you explain each situation and what happens? For example 60 VI = framepacing is good Also is there any way you could use rivatuner statistics to monitor the frame pacing? If you could do this using the latest dev version, that'd be good |
|
Okay, so: Starting the game = good or bad It's a little inconsistent when triggering, but it's either excellent frame pacing for forever or bad frame pacing for forever and pressing tab can cycle between the behaviours. Another way of inducing the bad behaviour is to open Emulation Settings/Graphics Plugin UI and then clicking Okay, repeating this process however does not seem to be able to restore the good frame pacing. I'll get a video of it tomorrow and try to remember to use a Frame Pacing overlay. |
|
Huh, that's strange, Okay I'll take a look, see if I can improve it any, thanks for the response |
|
It looks dead on to me? I just tried messing around clicking on and off things, going in tot he graphics plugin settings, waiting a bit and clicking okay, nothing seemed to waver the framepacing. Here's a picture of my frame times (you can also see the FPS is 100% bang on 59.94 which it should be), the spikes are me opening/closing the GS plugin settings. Frametime variation is 0.3ms, which im sure you couldn't feel. |
|
As noted in my first message I reconfigure the emulator to operate at 60FPS instead of 59.94. This is because at 59.94 the emulator suffers frequent rolling bursts of stutter as a result of the FPS not matching the monitors 60Hz. You can adjust it in the PCSX2_VM.ini file within the inis folder. Would changing the FPS to 60 have any negative impact on the operation/stability of the FPS Limiter? Also try to induce it without something like Nvidia Shadowplay running. While it can still happen with that running the severity will be significantly lessened. |
|
wait, are you using the vsync option in PCSX2? If not then the FPS shouldn't matter |
|
I just tried with it forced to 60 FPS in the config and I tried with and without vsync enabled and also tried setting my monitor to different refresh rates (59, 60, 100, 120, 144hz) and in every setting it was pretty stable. |
|
With PCSX2 v1.6.0 (and older) Vsync is required for a reasonable experience. With v1.7.0 it's no longer needed because the FPS Limiter, when it works correctly, works considerably better than v1.6.0's implementation. In my initial test with MSI Afterburner & Rivatuner Statistics Server's OSD polling every 100ms, the Frame Pacing graph didn't reflect what I was seeing. The graph was flat while anomalous stuttering was going on. Maybe I need to increase polling frequency? While I have a video showing the experience before inducing the issue and after inducing the issue, it was recorded on a Samsung S5 phone and that phones camera is uh... not good for recording a display. While you can see what's going on it's very washed out, it was also recorded before I realized Tab could restore proper operation of the FPS Limiter. Because of this I'll prolly wait a while and use my dads Samsung S10e phone when he's no longer using it and get a much better recording. |
|
Yeah I mean, if you look at the frame rate in the top of the gs window, you can tell how much its varying by how much that number jumps about. I don't think the game is stuttering as such, it just feels like a 30fps game to me,or at least it seems to be doing that internally. Pcsx2 is serving you the frames with pretty good accuracy. I put the polling rate down to 16ms and didn't really notice any difference, I don't think the frame pacing graph works like that |
|
Here's the new video showing what the current situation is like in PCSX2 for me with the RTSS overlay active: https://www.youtube.com/watch?v=xRvyqrEFpWI (HD 60FPS video may take some time to process) Any time you see the FPS change from 60 (100%) to 120 (200%) and vice versa is a press of the Tab key. Vsync is disabled. 456.71 video drivers. |
|
Does it happen in fullscreen as well? Also, you might wanna enable the vertical bars in RTSS (Enable frame color indicator) in its settings. If there's no vsync, you should see the tearing in the bars. You can also see if there are problems preseting frames as well by how the bars flicker. |
|
It's really difficult to tell in that video, 120FPS actually looks worse on it, but then the video is 30fps and rn the quality is 360p(potato) |
|
1080p 60FPS processing has finished. The video is 4k resolution so there'll probably be an even higher quality encode available at some point. |
|
Okay well PCSX2 is outputting steady frames at 60, that looks for certain. Does moving the EE cycle rate slider to the right (try +3) in speed hacks make any difference at all? I mean that looks like internal stutter for some reason. |
|
https://www.youtube.com/watch?v=-n_PXtb1b38 here's another video on Dev 946, with 1:30 showing the worst case experience. This time around I let PCSX2 run at 120FPS which ffectively means the game is running at 60FPS and the higher FPS makes it easier to discern the anomalous behaviour. Again, I'm just using Tab to cycle the state of the FPS limiter between 60 and 120FPS with the first attempt at invoking the issue happening at 1:00. I also toggled an option to improve the RTSS overlay visibility and increased the size of the RTSS graph, poling rate is 100ms (the fastest allowed). @KrossX "Enable frame color indicator" doesn't exist in RTSS included with MSI Afterburner... |
|
You didn't answer my question. |
|
Whoops, sorry. Adjusting that setting to +3 has no improvement. To me it seems to be that the program can get stuck rendering in a way that the Windows DWM doesn't like, resulting in duplicate/skipped frames happening often. The Frame Time and FPS look good but the frames aren't being sent to the DWM properly. I'm curious if this PR solves the issue, but I dunno how to compile a build that includes it so I'll have to wait until that gets merged unless someone here makes a custom build (I seriously don't mean to pressure anyone by this statement, I'm happy to wait): #3549 |
|
That's possible, there's an issue with how DWM works and the framerates of the PS2, the two don't line up very well, we are tracking this in issue #2307 Oh you edited just as I was writing this, I was going to mention that comment :P I don't know what (if anything) we can do for OpenGL, i guess that's a discussion we're going to have to have. |
|
Snes9x v1.60 introduced a new option that resolves similar stutter I experienced in non-exclusive fullscreen mode and it may interest you. Currently it's a configuration file setting you can toggle in the program and not available in the UI. You can read when I first reported it and the entailing discussion here: https://www.snes9x.com/phpbb3/viewtopic.php?f=6&t=26299 More pertinently read from this comment for the solution: https://www.snes9x.com/phpbb3/viewtopic.php?p=59139#p59139 |
|
flushing DWM? That's.... one way around it I suppose. We'll look in to it :) Thanks |
|
Okay so I checked this out and this actually does nothing, I think it's completely placebo. The only thing that does help is where they changed full screen to use WS_POPUP for the window style which kinda forcefully disables DWM, PCSX2 used to do this but it introduces tearing so it was removed, it's kind of a nasty hack anyway. I'm not sure there's much hope for this with OGL since DWM cannot be disabled on Windows 8 or above and I don't think OpenGL supports variable refresh rate technologies such as GSync or Freesync (not that I could see anyway, Vulkan does), so yeah, for games which require smoothness, that Swap Chain PR and DirectX may be the future. |
|
Recent Nvidia drivers support Multiplane Overlay so programs can interact with the DWM independently, unsure if this is helpful to this situation (or any other situation, it's just something interesting that happened recently). You can read more here: https://nvidia.custhelp.com/app/answers/detail/a_id/5159/ I'm sensitive to screen tearing, so aside from the infrequent testing... I always have vsync forced on via the Nvidia Control Panel. If you're saying the Snes9x solution should cause screen tearing, that is not the case for me. In that topic, after the pertinent comment I link to I mention the various vsync and DWMSync option combinations and their results for OpenGL, Direct Draw and Direct 3D (while Vsync in Nvidia Control Panel is set to Application Controlled). |
|
Well the SNES9x solution didn't work for me because you can't disable DWM like that after Windows 8, the documentation says it does nothing now. I tried it and I had the same hitching issues as you normally get due to the difference in monitor refresh and the lower framerates the PS2 uses. VSync causes similar issues as the frame latency is around 3 frames, and a lot of people are complaining about input lag due to stuff like this. I think the future is going to be using DX with Flip model and VRR technology to sync up, that seems to work really well, but right now we're kinda being screwed over by the windows limitations and the differences in framerates. As for the new Nvidia thing, I don't know if that'll help or not, but if it works for AMD or not we need to know. I don't know if it's automatic or not, but I'm on 461.40 and I don't notice any difference and I have my settings as they suggest in that post. |
It works wonders for me under Windows 10, that being said I was annoyingly forgetting something important. In Snes9x the anomalous frame pacing is always present without the solution and never present with the solution, where as PCSX2 the issue is intermittent and with enough persistence can be intentionally invoked by doing various things like repeatedly toggling Fast Forward on/off in v1.7x or repeatedly removing focus from the rendering window by clicking the tasbar and restoring focus to it by clicking the rendering window in v1.6 etc. so... the behaviour is not identical so the Snes9x solution may, as you evidently suggest, not be a solution for PCSX2. I look forward to trying out the DirectX solution you've mentioned. |
|
#3549 fixes this issue as long as Note that if the refresh rate and frame limit do not match (e.g. limit at 59.94 and refresh at 60) there will occasionally be a visibly dropped frame roughly every 20 seconds or so. Fixing that would require resampling the output or setting the Test build attached below. |
Would setting FramerateNTSC=60.00 in pcsx2_vm.ini be sufficient? Or does adjusting the FPS in this manner introduce issues I'm unaware of? I've always found it odd that the value was displayed but not configurable in the UI. |
Disable preset on a recent build, it's been configurable since #4697. |
|
Can you see if this is still an issue? Frame pacing has been improved in several areas + |
|
I've tested a few games for about 30 minutes and didn't notice any stuttering, so the issue appears to be resolved. Tested with Software and Vulkan. Windows 11 |
|
If I remember I'll try to do some testing this week. |
|
Just like the other issue that some other PRs helped along with this specific issue: #5485 I'll wait till you check it out. |
|
This is not resolved, I've recorded some new footage (from a immobile camera this time, instead of hand held) which is in the process of being processed & uploaded. |
|
Well, Youtube is taking a loooooong time to process the 60FPS HD copy (and is still processing it)... in any case here it is with relevant time stamps in the description: https://www.youtube.com/watch?v=mt43dDgByLk You may notice there is periodically stutter happening when the issue this topic is discussing is not happening, that is a separate issue (also affects Vulkan) that I'm unsure of the cause of. |
|
An external recording of a display even at 60 FPS is not going to be helpful in identifying any issues. If anything, it will amplify whatever is happening. A proper screen capture is going to be the only way to do this. Ratchet games are a pretty poor choice of test case for this because the game itself can change its internal framerate in real time. Specifically on the opening level of the second game, there are a number of areas, that room included, where panning the camera five degrees can be the difference between full speed or slowdown. For a test case on this to be helpful, we need metrics. Ideally, having all the OSD attributes enabled on an up to date development build, and then RTSS on screen to show frame pace. It is worth noting all renderers have some slight variances, and this is due to frame presentation and emulator timing, not the render loop. |
|
When you apply settings I don't believe focus is given back to the game window. So unfocused frame pacing is expected to be poor. That's also out of pcsx2s control. |
|
@Nicholas-Steel Maybe you could give #5488 a try. It aimed to address pacing issues between framerate and refresh rate, though I don’t know if the benefit will apply to OpenGL or Vulkan. |
Is there a compiled build available? Windows, AVX, 64bit or whatever someone manages to compile. |
You can find builds via the checks section at the bottom of the PR page - click "Show all checks", click "Details" next to one of the checks for your OS, click "Summary" at top-left, and finally select one of the artifacts at lower-right. If you don't want to go through all of that: |
|
is this still an issue on master? |
|
No response for a month now. If the issue persists please comment here and we can re-open. |
PCSX2 version:
1.6.0
v1.7.0 dev 350
v1.7.0 dev 143 gf44f676cc
PCSX2 options:
EE/IOP: Chop/Full
VUs: Chop/Extra+Preserve Sign
GS: NTSC 60 (instead of 59.94)
Speedhacks: MTVU Multi-threaded (MicroVU1) enabled + default speed hacks
Game Fixes: Use software renderer for FMV.
Plug-ins used:
Default plug-ins
GSDX AVX2
OpenGL (Hardware)
Description of the issue:
Multi-tasking and then returning to the gameplay window of PCSX2 can induce Frame Pacing issues where it constantly frequently behaves very poor/stuttery/choppy while FPS and percentage remains excellent according to the programs title bar.
Steps to reproduce?
The problem can be easily toggled on/off with a high success rate of behaviour change by clicking back and forth between the Taskbar and PCSX2 Render window, repeating the action can resolve the problem (remains resolved for multiple hours at least, if you don't multi-task again). You may need to perform this more than once to switch the behaviour but you're likely to toggle the behaviour with only one click on the Taskbar and then one click on the Render window.
Mcd001.zip
KH2:FM & AI3:GP saves, KH Save is slightly busted but serviceable for reproducing the issue (it's a save made while the game was modded, I tested that it works well enough without the mod).
Last known version to work:
Unsure.
PC specifications:
Windows 10 - 2004 x64 | Ryzen 3700X | ASUS Crosshair VIII Hero (WiFi) | MSI 1070Ti | 16GB 3600MHz RAM
The text was updated successfully, but these errors were encountered: