Stuttering (seems to be due to WS_POPUP removal?)

[thatsage]

Build 1.5.0-dev-2285-gc23241c (latest as of today)

Settings OpenGL issue doesn't happen in DX11 Safe Preset /w vsync off or on (in pcsx2) Software or Hardware

Issue Games stutters every 15-20 seconds or so, for a few seconds, despite running in 60fps and exhibiting no slowdowns or issues with sound etc.

Fix After looking around I found issue https://github.com/PCSX2/pcsx2/issues/1437 and using the specific GS plugin provided there which from my understanding added a flag called 'WS_POPUP' seems to completely resolve the issue.

PC specifications: WINDOWS 10 64bit build 1709 NVIDIA GTX 970 driver version 390.77 8GB RAM i5-4690k

Note this issue persisted for me across truly many versions of drivers and windows 10 builds, until literally today when I stumbled upon that fix.

[vsub]

If I remember correctly,In my case the problem existed only while using OGL and exactly removing the WS_POP fixed the problem. This was while using Win7 but there was other people reporting that it also happens on Win10

And btw,I don't know if this is related but I recently installed some windows updates(cumilative january updates)and soon after that I notest some weird stuterring on a pc game I was playing(in window mode)before the update and that game can barely make the cpu\gpu break a sweat.

Windows 10 x64 nVidia GTX 1060 16GB Ram i7-6700HQ And no,the laptop is not working in some power saving mode

[MrCK1]

WS_POPUP was removed primarily because it caused tearing with Nvidia cards on OGL

Quotes from #2058 mirh said:

Yes it is. It was originally removed here because it was breaking v-sync [in our actually broken opengl implementation, in retrospect] ... Fast forward these last months of nvidia drivers maddens, it reportedly solves stuttering on nvidia driver - without passing through the headaches of DWMflush.

gregory38 said:

The removal of the WS_POPUP flag was done to avoid some tearings on Nvidia. I'm afraid that tearing will come back. However, users can still force vsync in the driver to avoid tearing.

[thatsage]

Yes indeed, but the issue shouldn't be left like that as it creates an even larger problem for some Nvidia users like me. And as said by gregory38 we can always force vsync through NVCP (not that I need to even with the flag). There's no other solution for the stutter it would seem other than using that flag, so I think it must be introduced back in some way. There was talk of making it a toggle option maybe, why not do that?

For example it could be called "alternate rendering window" with the description stating "use this if experiencing problems with normal fullscreen, for example stuttering. More relevant for Nvidia users. Warning: may cause issues with vsync (can still be forced through control panel)."

[mirh]

The thing is, nobody in their goddamn mind seems to have understood what's going on. With nvidia cards at least. I was hypothesizing lack of WS_POPUP had something "interfering" with exclusive fullscreen, yet turtleli here mentioned this was working. ... is tired and doesn't feel like to TL;DR the reminder of the thing In the current builds, right behavior should be enforceable with EnableVsyncWindowFlag=enabled

---

If you then are also in the mood of testing (a novelty across people affected by this problem, if I can say) then try to experiment with all the possible combinations of windows fullscreen optimizations, NVCP fullscreen optimizations and ws_popup flag. Also please note down windows build and gpu driver version.

[thatsage]

I updated OP with build and driver version numbers. I'll be happy to do testing, much better this is fixed rather than me staying on the same plugin as it becomes outdated. But, I'm no developer so I need a bit more directions if that's okay, I'll do what I can. Disabling windows fullscreen optimizations in properties doesn't change anything for me - tried with the "default" plugin of course, which comes with the latest SVN.

General things I tried before making this issue: limiting to 60fps with riviatuner, setting frames to render ahead to 1, combination of PCSX2 and NVCP vsync, also NVCP triple buffering - none of these fixed the issue.

[mirh]

Oh, god, that's the spirit. I swear I'm so pissed about people complaining but 0 will.

First: undo whatever you might have done. Does EnableVsyncWindowFlag=enabled (in pcsx2_ui iirc) in latest git equally fixes it?

[thatsage]

I re-downloaded latest git, set it up everything default and only set EnableVsyncWindowFlag=enabled as you said in the ini. It didn't fix the issue.

[mirh]

...... Can you please spam that in every .ini file then? I'm going to band my head in the meantime.

[thatsage]

I added that to every other .ini and it did't fix the issue. Seems like you were sure it would've?

[mirh]

It should be supposed to add ws_popup... Maybe try true, or 1? I'm loosing my mind over this.

[gregory38]

I think entry should exist (disabled by default). I think, from top of my mind, value are enabled/disabled

[mirh]

In mine too, but I don't know what else to think.

[FlatOutPS2]

Does it require Preset to be disabled?

[thatsage]

Well I gotta correct myself, the stutter actually doesn't happen in DX11, it happens with OpenGL only. At any rate, setting EnableVsyncWindowFlag to enabled or back to disabled (btw 1 changes to enabled after running pcsx2 automatically) doesn't fix the issue, again DX11 never had it, sorry about that...

[mirh]

Yes, we know it's opengl only. Now, can you please try to see if unticking the "preset" checkbox in the pcsx2 settings gui changes anything?

[thatsage]

I tried that too, before opening this issue but also after changing the .ini files. I also tried with pcsx2 vsync enabled in addition to just unticking the preset checkbox. Again, nothing made a difference.

[mirh]

Can you try setting zoom to 100%? Did you use fresh settings files?

[thatsage]

Zoom is on 100% and I never changed that, it's the default value.

Yes, I downloaded a new .rar and extracted it to a new separate folder. Only thing I copied was a save-state for Shadow Hearts. Just to be sure, I tried now without loading the save-state, still stutters.

[mirh]

Then the question is WTF there was of different in the dll yo.... WAIT A MOMENT Did you get the DWMFlush gsdx by chance?

[thatsage]

Terribly sorry I didn't just link the damn thing I was using as a fix in the first place...

https://github.com/PCSX2/pcsx2/issues/1437#issuecomment-301492954

It was actually your comment in the forum which took me to it lol.

[mirh]

... So.. I guess like.. That's what I had shunned with "I guess we could close this issue - if somebody still have stuttering, we can open another one - focused perhaps just on DWM issues"... ... So.. I'm tired of groping through the darkness, and I have an half idea. Could you please first test if stuttering is reproducible here with opengl? (and if it gets fixed by replacing the dll)

[turtleli]

So have you tried fullscreen with EnableVsyncWindowFlag=enabled in PCSX2_ui.ini (GSWindow section) and with Aspect Ratio set to "Fit To Window/Screen"?

[thatsage]

Could you please first test if stuttering is reproducible here with opengl? (and if it gets fixed by replacing the dll)

Using the plugin you provided and the .ini too, stutter happens. Switching to the dll I linked earlier fixes the stutter (but since the .ini is just defualt settigns and I'm using a diffrent gdsx.dll, that's not surprising right?)

So have you tried fullscreen with EnableVsyncWindowFlag=enabled in PCSX2_ui.ini (GSWindow section) and with Aspect Ratio set to "Fit To Window/Screen"?

No, actually, I tried with Aspect Ratio set to 4:3 standard until now. I changed to Fit to Window/Screen, and what do you know, first there was tearing - never before... Then I turned on PCSX2 vsync, no tearing anymore... And it seems no stutter anymore at all as well.

But soon as I switch to 4:3 standard, window or FS, I get the stutters creeping in every now and then.

[mirh]

So that explains why people might have been reporting conflicting reports.

And.. are you saying that "fit to window/screen" gets you tearing EVEN in windowed mode? And that just enabling pcsx2 vsync (plus the aforementioned) fixes both this and stuttering, even without ws_popup?

EDIT: ohhhhh, try to force disable g-sync

[thatsage]

And.. are you saying that "fit to window/screen" gets you tearing EVEN in windowed mode?

No no, in window mode no tearing no matter what.

just enabling pcsx2 vsync (plus the aforementioned) even without ws_popup?

Actually no, I meant to test without ws_popup too to see if it was needed, and thought it wasn't, but apparently the .ini didn't save changes and it was actually still enabled. After actually disabling it, the method no longer worked.

To summarize: to fix stutter for me, I first must edit .ini and set EnableVsyncWindowFlag=enabled and also must set Aspect Ratio in GS window to "fit to window/screen" OR to "16:9", meaning the actual issue is when it's set to 4:3 standard (but also, those two other options still need the .ini edit). Together, aspect ratio change and .ini change, these changes introduce good old screen tearing. Both pcsx2 Vsync and NVCP vsync can fix that tearing without causing any new stutter, I see no difference between either method. But if aspect ratio is back on 4:3, there's no tearing anymore (even without vsync), unlike 16:9 or fit to window/screen, and it stutters again.

EDIT: ohhhhh, try to force disable g-sync

I did :) at first I actually tested on my TV which is how I play emulators, but that got bothersome so I set my monitor to 60hz and disabled gsync, which pretty much matches the TV other than native resolution.

With g-sync enabled, I actually didn't get the "prolonged" stutter every now and then, but frame-pacing was all sorts of wrong lol so yeah I turn it off for emulators, or just use the TV.

[mirh]

Ok so.. WS_POPUP, plus FitToScreen, plus 100%zoom, plus v-sync fix it all. (which is kinda what we already know, except WTF even in windowed mode?) Just to be sure then:

• is v-sync needed just to solve tearing, or even stuttering (e.g. in windowed mode)
• with 4:3 there's no way whatsoever to get rid of stuttering (aside of the "DWMflush" dll)?

[thatsage]

with 4:3 there's no way whatsoever to get rid of stuttering (aside of the "DWMflush" dll)?

Yes.

is v-sync needed just to solve tearing, or even stuttering (e.g. in windowed mode)

Vsync is only needed to solve tearing which only happens in fullscreen mode. Vsync isn't needed to actually stop the stuttering, but it stops the tearing that WS_POPUP + FitToScreen/16:9 cause in fullscreen.

In window mode, there's no tearing, and it actually does stutter like normal, all the changes don't make a difference there. It was late yesterday, my mind was a bit jumbled yesterday sorry heh. Yes, it does stutter still in window mode.

[mirh]

Ok then (whatever fit to screen in windowed mode might be tampering with, I guess like that also explains why "zoom" was reported to be re-introducing stuttering) So, nonetheless since I so much hate magic, without further ado:

---

Mighty @Kaldaien I summon you. We have been hitting mysteries of the nvidia driver for the better part of the last two years. When using OpenGL renderer (unless you happen to meet the conditions for exclusive fullscreen mode*) you get loads of stuttering. We found out calling DWMFlush before presenting every frame fixes even the remainder of cases, but if possible we'd like to avoid that (it framelocks you) G-sync going wild might have explained windowed mode weirdness, but disabling it reportedly leads to nothing - and I don't know where else to bang the head. I guess like you don't have ps2 bios/games available, but you can readily check out this test case. Sources are here.

*which are WS_POPUP window style and surfaces size == window size (I once though these had to be in turn equal to screen size, but it doesn't seemingly matter whether you are in fullscreen mode or just windowed, for this problem to manifest)

[gregory38]

We should really update PCSX2 to always use a surface of the window size. But we must send the rendering size to the GS plugins. It will at least remove one parameter of the equation.

[mirh]

I wouldn't know how nicely that'd play with integer scaling.

[gregory38]

Why ? It shouldn't be an issue. Game size&mode are accessible in gs side

[mirh]

Yes but if you lock surface to window this way, and then you have surface that only expands by multiples.. Doesn't that also pass to window then? ...

Anyway, considering all of this oddness, an "nvidia anti-stutter paranoia" button that enable DWMFlush is the only possible fix that can manage to cover *all* the possible situations imo. I am sorry for all the wasted time my crawling for a "programmatic" solution caused.

[thatsage]

Just thought to update since I'm playing Rogue Galaxy atm. This is relevant on b6a73f6 (4 days old svn as of today).

Under normal circumstances OpenGL and DX11 both go into prolonged micro-stutter every 15-30 seconds, and the micro-stutter lasts a period of ~3 seconds. I am pretty sure that previously it didn't happen in DX11, not with Shadow Herats, but with Rogue Galaxy DX11 exhibits the same problem.

As expected changing EnableVsyncWindowFlag to enabled and then going full-screen 16:9 completely fixes the issue (both in DX11 and OpenGL).

I may be imagining this, but it feels like this change also increases input lag.

[mirh]

So, you are telling us that D3D11 here has no problem whatsoever, while here it lags stutters (without ws_popup)?

[thatsage]

If by lag you mean stutter, they both do. Both builds stutter on DX11 and OpenGL both without ws_popup. I think back then when I tested the ws_popup flag first what might've happened is that I probably forget to reset it to disabled when I tried DX11 and that's why I thought DX11 didn't have this problem.

I'm sorry for making it so confusing.

To summarize: both builds exhibit the same problem which can be fixed the same way. Regardless of DX11 or OpenGL, without the ws_popup flag (and playing in fullscreen 16:9 or streched) games stutter. This change does also introduces tearing, which NVCP or PCSX2 forced vsync resolves.

To my amateurish self it just seems like when DWM "takes over" and applies its own vsync solution to the end result (which ws_popup and full-screen seem to forbid it) it's fucking up the frame-pacing of what's being displayed. I think it's important to note that without this change, it's impossible to get tearing no matter what, further showing that it's DWM messing things up by forcing it on the end result.

Let's say I turn off the frame-limiter, and since there's no vsync or anything like it, like with any game then normally we will get tearing in full-screen. But in window mode because of DWM choosing which frames to display, throwing the others to the trash, we get visual stutter because it doesn't seem to care what goes on in that window (in terms of its frame-rate or frame-pacing).

[mirh]

Is stuttering also a thing in dx9? And could you try 1.4.0 (aside of fullscreen, which should trigger there afaik)?

[thatsage]

dx9 stutters the same

1.4.0 - OpenGL doesn't stutter. dx9 and dx11 do.

nothing changes between windowed and full-screen

[mirh]

So.. to clear again: d3d stutters everywhere. Opengl is either working specifically if you met all the criteria (WS_POPUP, fit-to-screen, fullscreen) in latest git .. Or unconditionally always in 1.4.0?

[thatsage]

Almost hehe.

The fix works for D3D too, everywhere. But as you said, OpenGL on 1.4.0 doesn't require the fix and is working fine unconditionally.

[mirh]

Can you try this?

[thatsage]

Stutters like the other revisions (besides the 1.4 one on OpenGL).

Thank you for trying to get behind this so much btw :) I hope we get to the bottom of it.

[mirh]

Problem is, we are screwed now. I was as always hoping some dumb blind bisecting could be done, but there is this sea of commits that one has to build oneself too now.

Unless you are.. Cool with using VS, I guess I'll have to put on hold ideas for the moment.

[mirh]

Could you please try driver 375.63/disable telemetry/clean standby memory? https://www.askwoody.com/2018/stuttering-reported-with-win10-nvidia-geforce-gtx-10xx-cards/

[thatsage]

Are you sure this can be relevant? I have a Maxwell card (970) and the stutter isn't system wide, and we found ways to resolve it completely by changing pcsx2 configuration while nothing in windows or drivers mattered. With 1.4.0, OpenGL didn't have the problem at all too, so it really seems to be PCSX2 related

[mirh]

It *clearly* is something nvidia-driver-related, if a totally innocent flag triggers stuttering. We (kind of) understand what's the trigger on the application side, but dreaming of a precise answer from nvidia devs, I'd like some analysis on their side now.

[mirh]

@thatsage great news boi I just now realized, the wayback machine has all the old names archived. And the links are still live and all. Could you therefore try to bisect which 2016 release changed everything?

[aidenn]

Hi, user side here. Does this flag (EnableVsyncWindowFlag=enabled) actually make anything worse for AMD users? If not, then maybe, for the time being, it should be on by default?

I had a clean Windows 10 reinstall the other day, booted up pcsx2 and whoah, stuttering. WAIT, I REMEMBER SOMETHING ABOUT VSYNC AND 16:9. Nothing. After 30 minutes I remembered, wait, wasn't there a flag in the ini or something?

I know that this is a driver issue (actually, last year, even this flag couldn't help me until I updated the drivers, so nothing helps if you're using drivers older than ~summer 2017), but if the flag isn't making things worse, then maybe it's better to enable it by default?

PS. Did you hear about that latest craze called beam racing? Is it possible to implement it efficiently in pcsx2?

[mirh]

No, it doesn't have any downside at all with amd. The problem for the thing not being enabled by default is that: 1) the exclusive fullscreen you hence trigger, causes us some headache 2) it still seems like we are missing something of the bigger picture.. I mean, what to do with windowed mode then? 3) 0.01% OF PEOPLE ACTUALLY HELP WITH TESTING

... So, long story short, for the moment the only thing I'd advise nvidia users to do, is to roughly bisect this range of commits from the releases named here - and report back where you find this bad behavior was introduced. (protip: copy paste the urls of the releases, and remove anything before https://buildbot.orphis.net for faster downloads)

[aidenn]

Thanks for that issue you linked, it was a missing link in my understanding of the case. And 3) I am quite helpful, if you want, I can test anything you send me (2500k@4Ghz, 760 gtx, win10). And that means that I will test these commits, But that will have to wait until two days from now (work reasons), but I did encode it both in my brain and in my schedule and it isn't any kind of difficult, so please give me a couple of days (+2) and I'll check exacty which commit did this.

I can also test linux, because that's my system of choice on my laptop, but it can't hold 60 fps in even the simplest of games, so I doubt it would be useful in this case.

[aidenn]

Okay, a couple of days turned into a month, damn that RL, but I finally sat down to check this out. It only took 32 builds to find, so it wasn't that bad.

Methodology: run Legend of Saiyuki AKA Heavenly Guardian (since it's 60 fps, not demanding and loads fast) and run left and right for a few minutes.

The last build with smooth scrolling is 375 (although 4:3 stutters in all builds, so stretch to window/screen is mandatory). The next available build (379) stutters no matter what I set.

I guess it's just this commit after all: https://github.com/PCSX2/pcsx2/commit/234bf8af34f1f88be275deb3a4a0673006caaccb

-- edit --

And no, there's no tearing either beginning with 1.4.0 and ending with 375. Maybe whatever caused the tearing before was due to older nvidia drivers?