No, not the the moment, with Content FPS of 30 you are looking at a simulated "30 Hz CRT" which would be too slow for our eyes to experience full persistence of vision, hence the flicker. The shader doesn't currently workaround this in any way, perhaps that's something that could be added but I will have to defer to @mdrejhon .

BTW It's not a problem if your WGC captured FPS reports high, SB will only pick the frames it needs for the timing anyway.

Is that how it works? Oh man... That's kinda sad, since I can very clearly see how tack-sharp the motion is with the flickery "30Hz" setup, just that the flickering makes it unusable. There are a lot of games that are locked to 30fps for one reason or another, both on PC and emulated, so it would be so good to have an option to use these shader hacks for that motion smoothness. Everyone seems to focus on 60Hz, but obviously 30fps content on 60Hz CRTs neither flickered, nor displayed a double image, so it would be cool to see a fix to that some time in the future.

Thanks for your reply anyhow!

Is that how it works? Oh man... That's kinda sad, since I can very clearly see how tack-sharp the motion is with the flickery "30Hz" setup, just that the flickering makes it unusable. There are a lot of games that are locked to 30fps for one reason or another, both on PC and emulated, so it would be so good to have an option to use these shader hacks for that motion smoothness. Everyone seems to focus on 60Hz, but obviously 30fps content on 60Hz CRTs neither flickered, nor displayed a double image, so it would be cool to see a fix to that some time in the future.

Thanks for your reply anyhow!

Indeed, sadly, this image applies here:

It's best to try to find ways to unlock the game's frame rate because CRT only looks good at Framerate = Refreshrate = Flickerate .... So you want a Hz not too well below your flicker fusion threshold.

(and yes it's auto-disabled for OLEDs and non-even ratios).

Automatic detection of OLED? Wow. You are able to detect whether an OLED is connected? (detecting DisplayID and seeing "OLED" in monitor model?) ... And yes, definitely eventually add support for VRR via busywait-presentation. No rush, but it's definitely desirable to keep VRR enabled if possible to reduce the amount of user fiddling.

It's also pretty useful for accessing odd refresh rates in RetroArch (50Hz, 53Hz, 59.1Hz, 59.94Hz, 60Hz) without needing to create custom refresh rates.

No no it's just a user-selectable dropdown LCD/OLED to make it easy for users to disable slew (please redownload latest version if you can't see it).
I'd like to explore the VRR-like approach more, it does hold some promise.

Gotya.

VRR compatible mode would reduce the amount of user reconfiguring -- sometimes it's a big hoop jump through multiple screens just to turn off VRR.

For max Hz VRR -- You don't need a busyloop. You can run shader framerate flat out to simulate fixed-Hz, just Present() as fast as possible until it blocks, then it simulates a fixed Hz at max Hz. Or even detect the display max Hz (Tip: use the numerator/denominator method of detecting Hz to get exact floating point Hz) and use that as the target. Slight lag may appear if you do this due to VSYNC ON framebuffer backpressure lag, but you can manage it a bit by automatically detecting when Present() starts blocking.

For below max Hz VRR -- It can be a lot less lag than VSYNC OFF. You'll definitely need a busyloop because even a 1% variance in framepacing = 1% candlelight flicker (1% more/less photons). Flicker is astoundingly sensitive to timing variations. Even a 1ms vs 1.01ms flash = 1% difference in flicker. Nothing beats busyloop in framepacing precision on a full performance GPU. (You can also thrash the GPU with dummy draw calls about 1-2ms prior, to wake it up, then busyloop to your target, as a semi power management workaround, too).

For autodetect CRT Hz change feature -- You might also later have a mode for a spinning-flywheel-based averaging algorithm that detects when the content framerate stabilkizes again (e.g. 53.5fps) and automatically reconfigure the CRT simulator to the new divisors. This would be useful for emulators that use VRR-based output. When switching between NTSC 60fps and PAL 50fps, ShaderBeam would automatically switch CRT Hz to match. The CRT autodetect Hz feature should only fire when the framerate is mostly stable, like my Apache 2.0 open source RefreshRateCalculator.js algorithm running on the content frame rate via some kind of frame-counting hook (mind you, that can wreak havoc with anticheat, but there must be ways).

Also, @mausimus from my 200+ hours of modern-GPU beam racing experiments including https://www.pouet.net/topic.php?which=11422&page=1

• Busyloops are god for this sort of thing. Can't avoid it, but you can timer-till-(1-2ms)-prior
• Some artifacts during microseconds can become human visible. Some microseconds don't matter but others do (e.g. beam racing), like my 10microsecond-creating-1%-flicker example above.
• You don't have to beam-race mid refresh cycles, you can just "beam race" the VBI for precise control of frame presentation
• You can optionally use it as a trick to hide a VSYNC OFF tearline (for an ultra-low-lag VSYNC ON mode) by putting the tearline between rerfresh cycles;
• You can use it as a precise VRR framepacer (ultra precise Present() mode)
• While not mandatory (if you have all those registry tweaks), making them unnecessary is sometimes possible on some platforms: Dummy calls to a GPU to 'wake it up'. A GPU asleep for more than 1-2ms will have very jittery begins in Present()-to-photons. Use the power management tweaks is better, but you can improve reliability by shaking the GPU awake sometime 1-2ms prior to the crtiical Present() event.
• A block of a few scanlines in a refresh cycle (usually near top) is very jittery Present() timing because that's the region where Windows compositor is doing its once-a-refresh-cycle compositing. Avoid doing any timing-precision-accurate Present() feats during this "bad region". Like badlines on retro platform, this is the badregion on a modern GPU-driven Windows system in my modern-era beam racing experience.

Also more dev tips to @mausimus

"Microseconds = Human visible" Debugging Trick

And the biggest developer surprise (that RTSS Team and SpecialK Team learned) - I'm the one who taught both of them how to do Scanline Sync - the "Raster Jitter Tearline" debugging trick.

• Temporarily enabling VSYNC OFF mode (during non-VRR) as a framepacing debugger is lovely. Gigantically, titanically, humongously underused and underrated by real-time-Hz-deterministic developers. VSYNC OFF jitter = raster jitter = timing jitter. So if you staabilize tearline = you got good framepacing with your once-a-Hz busyloop. Learn this visual debugging trick is a humongous "oh wow, my framepacing improvement tweak worked, that tearline is much calmer!". Fun visual debugging trick.
• A 1440p 240Hz display = about 350KHz scan rate in video signal = 350000 scanlines per second = 1/350000sec delay = tearline moves down 1 pixel. Even DP/HDMI are glorified serialized raster delivery just like VGA/NTSC/PAL, and VSYNC OFF gives you the raster splices.
• Want to enjoy raster knowledge on modern GPUs again, from your retro developer days? Use this debug trick, and relive your 1980s raster interrupt knowledge with 2020s modern GPUs via VSYNC OFF raster-jitter visual debugging.
• Debugging workflow
  • Create your busyloop Presenter
  • Have VSYNC OFF non-VRR mode as a visual debugger (bonus: add a fast-horizontally-moving vertical line to shader, that steps every subframes, for easier tearline-position monitoring).
  • Tweak your busyloop presenter with various tricks
  • Once raster jitter is stabilized in VSYNC OFF tearline, suddenly stop using VSYNC OFF and turn on VRR or VSYNC ON and see VRR or VSYNC ON work much more beautifully.

I'm trying a dual gpu per recommended and am curious if i need x8 x8 bifurcation for it to not stutter? I know from experience that to use dual gpu past like 110hz on a crt you need x8x8 lanes to not stutter and I seem to be getting stutters here so suspect it might also apply. I was actually getting less stutter with one gpu. Besides that this is almost perfect with my 500hz oled. If I can fix this stutter, I'll probably start selling off all but one crt monitor once I can get 4k 480hz in the coming years. The contrast and no black crush is soo nice.

Usually a 2nd GPU stutters less, but some situations where suboptimal internal GPUs (slow memory bandwidth and/or with power management enabled) underperforms a single well-optimized GPU with good drivers. The problem is how the system multitasks a powerful game & a refresh-cycle-deterministic shader simultaneously.

Make sure you disable all your power management with all the registry tweaks.

Try both ways, and go with what is the most reliable!
I'm looking forward to Tandem OLEDs, the extra nits will help CRT simulator at large native:simulated ratios without going too dark.

Are you able to optimize it to the point of no stutter with primary gpu usage at like 70%? yeah it's too bad we can't get 480hz in tv sizes. I'm usually one for ppi but I'd prefer the brightness+ this shader over the higher ppi dimmer monitor.

@jman500 Could you post a screenshot of ShaderBeam UI when you are seeing the stutter, please (you'll need to use your phone)? It's not a problem if you see Captured FPS above Content FPS (capture API provides frames at VSync but ShaderBeam will pick them up according to its timing). If the capture isn't smooth, try experimenting with frame-limiting the game in RTSS to Content FPS or slightly (0.01 or so) below. The results of how to set up the game itself also vary (have the game itself VSync or not). I'm afraid experimentation is necessary here.

To reduce bandwidth, you can use a lower resolution or a lower refresh rate. That lightens bus bandwidth and memory workloads. So some manual tweaking is needed if you are hitting limitations.

It won't work. It's lag based not beam sim based. I can write a big scientific rabbit hole, but needless to say - nuances can be explained in conversation elsewhere to avoid an off topic variant of my famous wall of texts here. TL;DR: Beam simulation fixes blur but can't undo monitor lag, and can't simulate a beam down to exact microsecond for horizontal raster precision.

Thanks a lot, ShaderBeam does everything it can not to add any unnecessary lag so its source must be somewhere between drivers and OS; experimenting with those is the only way to track it down.

Checked the rest of my nvidia control panel settings, for the 3d settings page everything is default except

• Low Latency Mode -> On
• Power management mode -> Prefer max performance

I set vsync mode to "use application" as you suggested, and checked that no per program overrides are set.

Double checked dolphin emulator was using borderless fullscreen mode and that the mouse was hidden.

Also changed dolphin from Vulkan to DX11 since Vulkan is labelled as experimental. Lag didn't appear to change from the last post though.

SB set as before (4 subframes, blurbusters shader, Windows graphics capture)

Now SB with desktop duplication (Still 4 subframes and blurbusters shader)

Simple BFI with 1 subframe and windows graphics capture

Simple BFI, 1 subframe, desktop duplication

Finally, SB completely off

Hope this is helpful for you. Let me know if there's other configurations you'd like me to test.

Thanks a lot, if you don't mind turning off that Low Latency mode in NVIDIA panel as it's unclear how it could affect SB (repeat just one of the tests to see if there's any difference). I will try to see if I can set up some kind of latency testing this side.

No problem, this is Low latency off, 4 subframes, blurbusters shader, Windows graphics capture

I had a look through the numbers and I think I know what's going on, it's not really a problem with your setup. The issue is that lag is unstable due to SB not knowing when the game actually refreshes so for 60 fps content it can add up to extra 17 ms latency in the worst case (not frame-limiting content would lower this). There is also some display lag right now which is necessary to prevent desyncs but I can add a slider to control this (latency vs stability) as on beefier setups it might be possible to push it lower. I have some ideas how to improve things here, so keep an eye out for a new version.
Regarding testing using this tool with Beam Sim on, another issue is when is a frame actually displayed - Beam Sim shows the frame gradually over a 60 Hz cycle, so depending when this tool picks it up it can also add variance; but that's just testing methodology.
Thanks a lot for taking the time to help test!

Thanks a lot, it sure does help! But please study, the shaders will still be here!

• yes you should try adjusting Gamma to get rid of the bars, if you can't get rid of them completely or down to acceptable levels, try setting Scan Direction to 0 (might be slightly more flickery)
• it's expected you can't capture the screen using any tools, it's necessary for SB to be able to overlay on top of the game
• noted on DLAA, I will see if I can reproduce this
• it's a bit surprising your Rendered FPS is showing a red mark, what is the number compared to Display Hz (when you're in game and everything works without the UI, then press Ctrl+Shift+B to bring it up)?
• when you bring something on top of SB like taskbar to adjust brightness/volume indeed it can flash as Windows temporarily changes presentation mode for the screen (no known workaround so far)
• you can limit FPS with decimals in RTSS by double-clicking in the box, although that only affects capture smoothness and not flashing

It's unclear why you're getting these temporary flashes, I'm suspecting that triggering the UI/mouse in SB might be causing Windows presentation model switch, more often than necessary (you did try disabling MPO I believe?). Perhaps that has something to do with MUX, or some other overlay-type software you might have running. Let's see if other owners experience the same (don't have a machine like that to test myself).

Thanks, stacking with Reshade is a cool idea to add scanlines into the mix! Yes image retention on LCDs and even Hz ratios is definitely a thing.
ShaderBeam already tries to set GPU thread priority to a high value so hopefully no need to use SpecialK as well (can also use ProcessLasso, it has GPU priorities too).
I am considering adding frame-limiting into SB as this would allow for tighter timings and less lag, but will need to look into that more.

Thanks, I'd like to give it a shot eventually but I don't have much experience on Linux desktop, so no guarantees.

Thanks, that's great to hear! Interesting setup, technically speaking Microsoft docs state that for best performance Capture card should be one that your primary display is plugged into, but end result is all that matters 👍

Hey, thanks a lot for the report! I will add the same basic HDR support from SG/BFI to SB, no problem 👍

I am a bit surprised about game FPS drop when you run the Shader on iGPU, there's no obvious explanation as to why this would happen, it has to do with Windows GPU scheduling (do you mind checking if HAGS on/off makes a difference?). Also, how is stability/flashing for you? The only reason to use a second GPU is to avoid flashing/desync, but if you're not getting those then performance will always be best on a single GPU.

Yes frame limiting is a problem, to keep gameplay smooth you have to limit it perfectly in sync with SB, using 1/4 through SpecialK is actually a very good method. I am thinking about adding frame-limiting into SB but not sure I will be able to do it (sadly SpecialK is under GPL so I cannot reuse it).

I had HAGS off before, with it ON the FPS is the same in every scenario except Shader RTX 5090 + Capture iGPU 61 FPS now Vs 65 FPS from before.

I do not have any flashing at all, though like I said I am using quarter vsync, but yes in my case using the dGPU for everything seems to be the way, also thanks for bringing the basic HDR support back in some way with a later update, maybe in the future we can do something about the problem with passing certain brightnesslevels causing the green flickering, but I guess the framelimiting is more important together with whatever else is being cooked by you guys. :)

Yes HDR only works with Simple BFI, I noted that when it was ShaderGlass still, but it is a good workaround until everything works at some point in the future

Thanks a lot, let me know if you see the crash again, perhaps there will be a message box.
The pacing is touch & go, I get best results when using a refresh rate with no decimals (had to create using CRU), and RTSS. I tried SpecialK and the result was similar. And yes, please use Window Input as that generally works better.

Yes, I always used CRU to make my refreshrate "even", although that was always a OCD for me, so I always did since quite some years.

About limiters like RTSS, I really tried, the 3 limiters RTSS offers even with active waiting, but in the end 1/4 vsync was always the most smooth option. (no flashing problem on my end in any way by the way)

Thanks for the update! I think the input lag approximately halved compared to the previous version with or without window focus and with 1 frame queue. there's still ~20-30ms of additional latency compared to ~50-55 ms of previous version.

Thanks, I will continue tweaking the auto-sync mechanism. In perfect conditions I was able to get 3 output frames (in my case of 240 Hz, that's ~13 ms) total latency but a lot of things has to go right - the input needs to be borderless with no queued frames, well frame-limited, stable capture rate, plenty of GPU headroom, and auto-sync fully engaging, so result will vary depending on the input. Also for Beam Sim, since it scans the image progressively there will be lower perceived latency at the top than the bottom of the screen (for 60 fps input, that's up to 16 ms difference), less if you use Scan Direction 0.

Crossposting from the 0.2 thread -- continue discussion at #20

Single-GPU Flicker-Reliability Improvements

I also communicated with someone on Discord about single-dGPU tests, especially for non-esports use cases where the priority is framepacing reliability. Here are some best practices we discovered, to improve ShaderBeam reliability in single-GPU situations. The problem a single GPU has a hard time simultaneously reliably framepacing both ShaderBeam and Game, and tries to prioritize the foreground application. Here's the solution.

(1) SHADERBEAM = HIGH PRIORITY. Increase priority of ShaderBeam using external utilities

• Set ShaderBeam to "Prefer Maximum Performance" via NVIDIA Control Panel (IMPORTANT)
• Let ShaderBeam raise its own priority (thread & process priority); AND

(2) GAME = LOWER PRIORITY. Lower priority of your game using external utilities

• Set your game to "Normal" via NVIDIA Control Panel. Do not use "Prefer Maximum Preference" for game w/ShaderBeam
• Use Task Manager to configure game to "Normal" or "Below Normal" priority.

Yes, this is counterintuitive. But the reason is that if you want a framedrop somewhere, it MUST be ShaderBeam instead of the game. You need to trick the dGPU to prioritize the background application instead of the foreground application.

TL;DR: ShaderBeam = High Priority & Game = Low Priority

This reduces the "malfunctioning CRT tube" effect.

1. A framedrop in ShaderBeam = malfunctioning CRT tube
2. A framedrop in Game = nomal-looking framedrop

Therefore, prioritize ShaderBeam instead of foreground application. Anytime the GPU struggles, you prefer it to frametime-spike the game rather than ShaderBeam, because the erratic flickers are more annoying.

This also improves reliability if you prefer HAGS to be turned on because HAGS prioritizes the foreground application. One less item to keep reconfiguring whenever you turn on/off ShaderBeam for different games.

NOTE: These tips also still improves two-GPU situations too; but the improvements of the above tweaks tend to be somewhat more dramatic for single-GPU situations. This can be done in concurrent other tweaks such as DisableDynamicPState registry tweak, to prevent power management erratic flickers during low-CPU-utilization situations where the GPU falls asleep between frames