[Feature]: Support Refresh Cycle Shader Processing -- Blur Busters Open Source Display Shader such as CRT Simulator

[mdrejhon]

Is the feature related to a "problem"?

This is a feature enhancement, submitted by the founder of Blur Busters / TestUFO.

Your suggestion

Add refresh cycle shader processing support

Example: Simulate an "X" Hz display onto a "Y" Hz display, while running a provided shader repeatedly on the original X frames, for each different Y refresh cycles. Such as 60Hz virtualized onto a real 240Hz display, with 4 different shader executions on the virtualized 60Hz framebuffer, which is output to the 4 different native 240Hz refresh cycles.

More info

I'm the co-creator of the world's first open source CRT electron beam simulator shader that successfully reduces display motion blur.

https://github.com/blurbusters/crt-beam-simulator

When running in realtime, it (much more than average) realistically simulates a CRT tube with less annoying flicker than standard BFI (Black Frame Insertion). The CRT simulator is now part of Retroarch emulator, to reduce display motion blur via software-based means in a way that is less flickery than BFI (due to simulated CRT phosphor + soft rolling scan instead of harsh global flash).

With it;

• 120Hz displays reduce 60fps motion blur by 50%
• 240Hz displays reduce 60fps motion blur by 75%
• 480Hz displays reduce 60fps motion blur by 87.5%

In addition, I've created the Blur Busters Open Source Display initiative (v1.01 specification), where I plan to release multiple display simulators over the next several years. The CRT simulator shader is just the first.

Example modification for Virtual Display Driver:

• Virtual Display Driver simulates a target display of X Hz (e.g. 60Hz)
• Virtual Display Driver runs the shader at native Hz frequency on the framebuffer at X times
• Output real display can be a 120Hz, 240Hz or 480Hz display.

Then refresh cycle display shaders can work successfully, if your Virtual Display Driver can become at least partially compliant with v1.01 of the Blur Busters Open Source Display Shaders spec;

Be noted, my CRT simulator doesn't require an integer divisible native:simulated Hz ratio, and CRT-VRR is actually possible via temporal scaling algorithm (I already have a software-based VRR simulator in TestUFO via temporal scaling so theoretically I can simulate VRR to a fixed Hz display too (would need refreshtimes & frametimes in shader uniforms though).

Also, there is a lot of other mainstream benefits of refresh cycle shaders, other than CRT simulator, too.

Contact Details

www.blurbusters.com/about/contact

[mdrejhon]

Crossposting some useful use cases for supporting refresh cycle shader processing in a virtual display driver for system-wide display virtualization.

Blur Busters Open Source Display Shader Initiative

DRAFT Specification v1.01 – Refresh Cycle Shader

Target Audience for Specification

• Operating Systems (e.g. Valve SteamOS, Microsoft Windows, Apple MacOS/iOS, Linux);
• GPU driver vendors (e.g. NVIDIA, AMD, Intel, Qualcomm);
• Display manufacturers (the whole industry);
• Video Processor Vendors and Video Capture Vendors (e.g. Retrotink, Elecard);
• Independent Software Vendors (e.g. RetroArch, Reshade, Virtual display drivers)

Possible Use Cases of Refresh Cycle Shaders

There are mainstream and niche use cases.

• Display simulators (CRT simulator, plasma simulator, etc);
• Adjustable pixel response and overdrive (shader-based overdrive algorithm, better LCD overdrive, etc);
• Ergonomic features (deflickering features, destuttering features, etc);
• Motion blur reduction features (softer impulsing-based simulators using phosphor simulators);
• Improved gaming and de-stuttering features (simulated VRR, de-jittering gametimes, etc);
• Improved home theater (Simulating 35mm projector / simulated LCD GtG, less harsh for 24fps OLED);
• Video processor features (3:2 pulldown dejuddering, etc);
• Videophile ISF-league features (Color adjustment hooks and preferred-tonemapping hooks);
• Global subpixel rendering for odd pixel layouts (e.g. QD-OLED, WOLED, etc) similar to ClearType;
• High-end esports gaming (Some, not all, algorithms are less lag in refresh cycle shader);
• Integration into multiple third party framegen engines (e.g. Lossless Scaling);
• Simulation of VRR on fixed-Hz displays via temporal scaling (e.g. CRT-VRR on 500-1000Hz OLED);
• Easier 3D shutter glasses on ANY 240Hz+ generic display with NO crosstalk;
  (Most 240Hz displays works with generic shutter glasses via LEFT/BFI/RIGHT/BFI sequence)
• Geometry/de-chroma-aberration shaders used by virtual reality headsets (direct or casting based);
• Etc, etc, etc.

While the big vendors ideally should support it, I'm contributing advisory help to independent software vendors because there's so much inertia in the big companies, that makes it difficult to convince them to support refresh cycle shaders. Which is frustrating -- however this is something that can be done in a virtual display driver framework too!

So I'm reaching out to figure out how I can help indies implement support for refresh cycle shaders that enables an explosion of important algorithms that needs to run at full Hz independently of underlying game framerate.

[mdrejhon]

+cc: @rickbrew