Do you use regular ShaderGlass and have Allow Tearing enabled by any chance? Pls disable.
EDIT: hotfixed to force tearing off

Understood, this an upcoming game? Please try something older perhaps to test the waters. Also please dbl-check you don't have any Background Application Max Frame Rate set in NVIDIA panel or anything like that (technically ShaderGlass is not the active application, the game is, so OS might choose to throttle it 😵‍💫 ).

Yes, this is upcoming UE 5.5 game, as you suggested I have tested Rocket League now and about the max frame rate thing, I don't use any of that.

Flickering is still there and GPU clocks drop again, I have even disabled VRR to be sure its not some windows finnicky but without a success.

Went to try with SpecialK overlay and it said that normally game with 60 fps lock has Hardware Independent Flip but once ShaderGlass is on top the Rocket League window then it goes to Composed Flip which may cause the GPU Clock drop and less smoother image.

Thanks, I will try some UE games, I don't have RL installed atm. I do have The Alters and after lowering display settings and enabling all aids (no HAGS, Process Lasso) it's stopped desyncing although gameplay is a little choppy (looks like capture lag).

Hey I did make some fixes in 1.2.0 around them, please check and open a GitHub issue with more detail where you see things being off, helps me a bunch.

Oh, thanks. I'll check it out.

Previously, when I used the Pixel Size x4, the image would be blurry in some areas, not across the entire screen, but the screen wouldn't be completely clear; the image would be unstable. This was regardless of the size of the monitor or game window.

The games mentioned in the comment above would be Pixel Art games. Ex: Real Bout 2, Marvel Super Heroes, Street Fighter Alpha 2 etc.

Thanks a lot! The crux of the matter is that Windows Capture doesn't consistently provide a frame every 16ms, sometimes it's 8, sometimes 20, resulting in stutter. I could buffer another frame, but that would mean more latency ("everyone disliked that"). I do need to experiment more here, there are still some options like trying Desktop Duplication API, or Window rather than Desktop capture, or just random things (capture on UI thread? on separate thread? will it make a difference?) to try to influence this. It's all just poking in the dark, there is no docs on how to make this work :/ Appreciate the offer, I might put together some tools to record timings so I have more samples.

Wow, thats quite a problem to solve when there's no documentation. How can there be no documentation!?

Yes, perhaps more frequent captures can be taken, timestamped, and the one closest to the expected/desired time is selected and passed through the next processing steps?

No. 120hz means you'll just get 120hz clarity even if your monitor is at a higher fps.
He doesn't need to do these. It's not really worth it. The maker of the shader is working on a vrr version which would make the baseline meaningless. Should come out within 2 years.
You dont need to worry about bandwitdh. It's not relevant. Either the display works or it doesn't. And even 10 year old ips displays seem to work.

No. 120hz means you'll just get 120hz clarity even if your monitor is at a higher fps.
He doesn't need to do these. It's not really worth it. The maker of the shader is working on a vrr version which would make the baseline meaningless. Should come out within 2 years.

ah, i see. thank you for clearing that up.

could you share the name of who is working on this, so i can follow the progress?

You dont need to worry about bandwitdh. It's not relevant. Either the display works or it doesn't. And even 10 year old ips displays seem to work.

i just ment that if you had say a 160hz monitor, and the software only supported 144hz and 165hz, you would be forced to leave some performance on the table. i didnt mean to imply it simply wouldnt work at all.

....actually, i dont suppose you'd happen to know if this works with monitors using mini-led backlights? that might actually not work at all, i could imagine local dimming having severe issues with rapid brightness changes.

small bug discovered: LCD anti retention's on/off switch is inverted.

The actual source of the shader is from here https://blurbusters.com/blur-busters-open-source-display-initiative-refresh-cycle-shaders/ you should still read this and other pages from the front page of the website. There is a lot of info.
The github is one of the hostings https://github.com/blurbusters/crt-beam-simulator

Interesting, does enabling Internal VSync (the old method) resolve this?

looks like it does thanks. otherwise it cuts it to 2/3 of the fps no matter what hz i set my monitor to

actually it still happens just not immediately and the only way to "reset it" is to minimize shaderglass and opening it again. i don't know what causes it. i'm assuming it's supposed to read 120/120 all the time right?

Wow, that's great to hear. I am full on massaging Capture API to try to get consistent input frame rates, it'll be the focus of alpha3.
For the colors, perhaps try adjusting some shader Parameters, for example Brightness/Clarity. You don't have any HDR-related settings enabled or anything like that? For me it's just a small brightness change when beam sim is enabled.

Thank you, peculiar. The black boxes are infuriating.
I'm actually still on 576.88, will update to the latest one and hopefully that won't be yet another variable in the mix.

I upgraded to 24H2, it seems WDDM 3.2 exposes "Max Capture Rate" as an option now. I didn't have it on WDDM 3.1.

I feel a bit silly in hindsight for not realizing this, and it's partly my own fault. It doesn't matter how stable my FPS is in the game, what matters is how much headroom my GPU has. It still seems to struggle even in much much older DX9 titles.

4K

I'll note I'm rendering at my monitor's native 4K for this part, I also neglected to mention that in my first comment.

I tried out STALKER Shadow of Chernobyl and noticed it was immediately smoother in the intro sequence in Sidorovich's bunker. Using Special K I saw that my GPU utilization was about 30%. At that level I noticed no issues at all, and it worked as intended. Great visual clarity.

Above ground in the Cordon rookie village I began to notice some issues. There is a slight flicker right under the center of my monitor when my GPU usage is around the 40-50% range. When I hit the 90% range everything goes awful and it introduces the god awful checkerboard tearing and stuttering/jerking.

The mouse escape issue I didn't notice in STALKER at all.

1080p

After noticing above I tried again, I forced the game to render at 1080p, and stretched it to my 4k native res:

Smoother and playable, but there was still that flickering even when not at the 40% threshold (0:23, right under the bottom | of the crosshair on screen). The insane frame smearing, tearing and hitching I experienced when I got up to 90% didn't happen, since well, I never got up to 90% at 1080p again.

I did notice any time I stood close to the fire it caused hitching and weird frame issues (02:27). I'm not sure why that is. My GPU utilization is about the same when doing that as it is when I was playing normally, fighting the bandits at the car park.
Sometimes it would stick after looking at the fire, and I'd have to toggle it on and off to fix it instantly.

Is there some sort of overhead when there is a lot of "noise" in a scene? What sprung to mind is bitrate starvation on video encoders when there's snow in a scene or lots of other small moving objects.

Perhaps helpful, I notice the checkerboard tearing that was in my Halo video, on my desktop if I rapidly move a window around. So it's definitely related to ShaderGlass in some form.

60 FPS STALKER Shadow of Chernobyl: https://pixeldrain.com/u/4DFRLezy

Thanks a lot for redoing the tests, it pretty much confirms that one needs a huge amount of GPU headroom to ensure GPU is shared fairly between the game and ShaderGlass... We're trying to find ways to influence this as it's outside our control and up to Windows and the driver. You could also try Process Lasso if you haven't yet, but it's just another shot in the dark. It's plausible that an additional effect in some scenes affects GPU usage pattern and influence how much is left for ShaderGlass.
It's impossible to know if we'll ever be able to fully solve this; one alternative is to use a second GPU for ShaderGlass if you have one lying around (doesn't have to be powerful, but more powerful than an integrated one). I would love to hear if it helps in cases like this.

one alternative is to use a second GPU for ShaderGlass if you have one lying around (doesn't have to be powerful, but more powerful than an integrated one).

I've thought about this for Lossless Scaling's frame generation before. I might be able to, I have some questions before I pursue it further.
I might ask something nonsensical or obvious, I don't know much about this type of stuff.

• Is there any manufacturer requirements: Intel, AMD, Nvidia? I was thinking drivers and HW level issues, no clue if it matters.

• Is there a bandwidth requirement I need for the bus between the two GPUs?

I'm assuming the rendered frame has to be passed to the 2nd GPU for processing, then displayed? It's relative to my display resolution and color space(?) I ask because I use HDR in any game I can, so it's 16 bit scRGB.

• Does the 2nd GPU need to handle passing the final output to the display?

In other words, do I plug the data cable from my monitor to the 2nd GPU if I were to do this? Any Windows gotchas I need to know about?

My main consideration would be an Intel B570 for this.

Hey sorry but you might be better off asking around in Lossless' community for recommendations since they had dual-GPU support for a while and might know these things better; in ShaderGlass this is still in its infancy.

Thanks a lot, great testing effort and decent results considering Windows 10 (where API progress has been frozen for long time now, no new features nor fixes are begin backported by Microsoft).
Consistency is going to be the final boss and I'm taking a more systematic approach to measuring the impact of various settings and implementation approaches, so it'll probably be a longer while before alpha3.
BTW I fixed the Device crash in mainline 1.2.1 (virtual capture devices were causing it), I will backport the fix to this branch.
Thanks again 👍