-
-
Notifications
You must be signed in to change notification settings - Fork 53
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Shader plugin support / Temporal processing support (Blur Busters has source code bounty (2K) for this) #35
Comments
I'm having difficulty with the labels; it's not letting me label this as "enhancement". P.S. I have an EV Code Signing Certificate, which I volunteer to use for betas/public-releases of this feature. EDIT: I sponsored @MolotovCherry $100 to show goodwill -- no commitment follow through. I'm very happy people are at least playing more often with virtualized display drivers (which the world badly needs, for the reasons above), and will inspire more and more indies to do the same. We indies want to produce stuff that enhances displays beyond what the manufacturers intended them to do. You can see how I overlap indies and business -- as a passionate indie-helping-manufacturers, I help manufacturers with some elements of the refresh rate race. Especially where 120-vs-240 is much more visible to mainstream on OLED than LCD, but drawbacks (e.g. strobing/BFI removed from OLED, plus bad ClearType, etc) -- where some of the pick-poisons that can be partially solved with a virtualized display driver with temporal filtering/reprocessing capabilities -- which also helps them to be convinced to add features to the actual hardware! (While concurrently, niche features continue to be added DIY by end users) P.S. Anybody who wants to learn more of the best content I've blogged, see Area 51 on Blur Busters for the curated best-articles. A more manageable read than Google Scolar. |
Hi! Thanks for the feature request! Also thanks for the goodwill sponsorship! This sounds very interesting! I never imagined that GPU shader plugin support in something like this would be a much desired feature. I will give this a serious lookover when I have some time and see if it's possible for me to implement such a shader system1. I'm still not sure at the moment how much of those items are possible to do with my current skill-set, but I will look into it. For non-sensitive discussion, I would like to let communication reside in this open issue if that's alright with you
Yes, I'm the sole developer and owner of this project (all the code was made by me, so there are no loose threads)
I'm not opposed to changing my license on the project to a more friendly one, or offering a special re-licenced version which is favorable to the interested party, on a case-by-case basis, if circumstances are favorable to me (of which this is an aforementioned favorable circumstance). My only real previous concern with my current driver was that I didn't want it to be taken and used with 0 credit / sharing of source code, since I put so much hard work into making it. Footnotes
|
Thank you for the follow up! Purpose / PrecedentsWhy does the world need this?Lots of people are doing lots of work in this sphere already! But most of them are FRAME BASED PROCESSING But there are a lot of algorithms that require REFRESH CYCLE BASED PROCESSING independent of frame rate, and also works outside of games. that can run on all refresh cycles independently of the underlying frame rate... Existing Precedents of FRAME-BASED processing Systems
Not suitable for REFRESH-CYCLE-BASED processingRefresh cycle based processing (independent of underlying frame rate) requires a virtual video driver -- like yours. That's why I posted here. While many could serve as plugins for a virtual display driver (to allow filters to be used outside of a game, for the whole Windows desktop) -- unfortunately, the majority of these don't support all algorithms that only works with REFRESH CYCLE BASED processing (independently of frame rate) Also some drivers for PCVR headsets (some of which actually connect as displays, but their specialized drivers "hide" the displays from becoming visible as regular monitors). Oculus Rift DK1 showed them as regular displays but by the time Oculus Rift CV1, they were hidden displays that could only be accessed through Oculus APIs. I realize you don't have time now, and maybe someone else needs to take the baton, but your software is the closest thing to a code skeleton that could be used for this sort of stuff! |
Interim "Specs" Discussion / Brainstorm For Temporal ProcessingI realize a lot of things need to be clarified, I'm happy to flesh it out, as I don't have enough skills to write a Windows driver (I'm not an expert), but I am full of display-processing ideas! (That's where I am an expert on) Some of these things MAY not be possible; this needs to be verified. Bounty Requirements need to be Spec'd/SimplifiedI realize that a lot of thinking is needed to see what is the simplest way to proceed, because we have a bunch of potential input/output settings. Most of which should be possible, and these values should be accessible to the shader processor. For example, simulated VRR might be removed from requirements, if VRR is too difficult to implement, and that alternative capabilities are implemented instead; Tentative/Unconfirmed RequirementsLoadable temporal shader filter modules
Possible Static Shader Variables
Possible Dynamic Shader VariablesBasically, shader variables that changes once a frame / once a refresh cycle.
Output should support Full Screen Exclusive (FSE)
ADVANCED NOTE (doesn't have to be part of bounty at first): If you have a Present() hook too and concurrently support both frame processing and refresh cycle processing, it is possible to have virtually lagless processing + VSYNC OFF mirroring! (VSYNC OFF on input Hz, VSYNC OFF on output Hz). In this case, the only lag is how fast the filter executes. Configurable constraints on a per-filter basis
Input data for shader processing
API for driver, for a settings application, and for screwup-recovery, etc.
Settings applet of some sort (whether in Windows CP or system tray, etc)
This is just a proposalOther possible workflows might be better and merit discussion; this is how I've visualized this so far; External filter supportYou can try testing SmoothVideoProject attachment support, maybe it already works out-of-the-box, because it can (in theory) attach to any DirectX framebuffer (Direct3D, DirectShow). If not enough compute, just use the crappy laggy interpolation as a validation test -- if that works, then the massively better AI-based interpolation might work okay.
Multiple GPU supportAlso given some filters (e.g. RIFE or future 10:1 reprojection algorithms) can be more compute-heavy than usual, might need to support 2-GPU systems -- so one GPU can be used for the game (primary) and a secondary GPU is used for the compute-heavy filter workloads. So architecturing decisions (long term) may need to (eventually) allow a "Select Preferred GPU to run Shaders/Filters On", even different from the rendering GPU. Multiple Video Output Support (Refresh Rate Combining):This will be useful for refresh rate multiplication Experiments. A virtual display driver can also support refresh rate multiplication (A Blur Busters breakthrough, which I'm still formulating a white paper for) through two methods:
So you can produce a 960Hz screen by combining four 240Hz, eight 120Hz or sixteen 60Hz projectors pointing to the same screen. A virtual windows driver driver virtualizes a higher refresh rate, and outputs the frames round-robin to multiple lower-Hz GPU outputs. There are some additional complicated techniques to projection map and or offset the VBI's that utilizes simulating fixed Hz via VRR, and using VRR as a software genlock to slew offsetted blanking intervals (but leave those details to me). To make it easier for multiple projectors pointing to the same screen, even a custom user-written shader can do projection mapping with settings adjustments (keystone/distortion correction) and specify which output the next framebuffer should go to (or something like that), but leave the details to the shader deets. What I need is a filter-supporting driver framework that makes it all possible at the end; which is part of the reason of the bounty. EpilogueIf only a subset can be supported, that's negotiable for the bounty (you can communicate with me privately at mark [at] blurbusters.com first, if necessary before discuss public here). Some of the above is easy, and some of the above is hard. A task breakdown might need to be brainstormed (stage 1, stage 2, stage 3...) Just putting some known factors down, to help brainstorming, and to help task-breakdown, and to help architecturing... You are welcome to continue to implement subsets of these ideas without doing a bounty. Basically you're welcome to using a subset of my ideas (less than bounty) if not able to -- at least I helped improve a project. But if a full shader-customizable driver is possible |
External Processors (As additional support other than plug-ins)Although it is desired to have built-in shader plugins, nominally, the framework should be able to support external processors (mostly spatial processors), and this does not necessarly have to be part of the bounty. But it is desirable to try to include support for popular external filter processors, which is usually simple API calls: Another purpose; add optional support for SmoothVideoProject filters -- there are some custom interpolation engines (e.g. RIFE 4.6 NN) that does near-flawless artificial-based interpolation for retrogaming; Currently it requires a HDMI capture card like an Elecard, but a virtual graphics driver supporting SmoothVideoProject and its most advanced interpolation plugins. Interpolation is not well liked by most gamers, but an RTX 4090 is able to do RIFE 4.6 NN in realtime to create 1080p/120 that looks really "native" (relatively artifact free and low latency) out of 1080p/60 content, while still having enough compute leftover to render the game itself.
So from this, possible additional ideas, not all unviersally part of the bounty, but nominal support (e.g. multiple-output support) that makes a shader-filter programming task possible. which I've edited into the previous posts;
|
https://eligao.com/enabling-freesync-on-unsupported-displays-f90ce7e8089346d2bbbe9275b21ba3ca
VRR seems to only need to modify the EDID? |
Depends. It requires the panel to be VRR-tolerant. I've seen VRR forced over DVI and VGA and old-HDMI versions before, through this ToastyX trick on AMD GPUs, as it's simply a variable-size blanking interval on a standard video signal, to vary the interval between refresh cycles (unchanged horizontal scanrate, varying vertical refresh rate). There are many panels that are intolerant of VRR forced upon it (goes blank). Also, panels with generic adaptive-sync with no compensations, will do a poor job of VRR quality. It usually won't have good overdrive compensation for VRR. This means you may have LCD ghosting artifacts at certain framerates/refreshrates, which is more problematic for motion quality than high-level FreeSync Premium & G-SYNC Native certifications. Example of asymmetric LCD ghosting artifact; this can appear/disappear, worsen/improve at different VRR frame rates; Motion-quality enthusiasts usually have a preference to pay extra for better/tested/premium certified VRR motion quality. But, yes, it's also nice to be able to add VRR as a bonus feature to a non-VRR panel; as long as expectations are tempered.
Unfortunately, virtual machines usually are incapable of VRR.
In other words, if you have to force VRR, you have to do it at the native-host-OS level. For example, a Windows VM on a Windows host, would work with this trick. As long as you successfully got the VM to show tearing in step 1, then you can trick the VM to convert the tearing into successfully working VRR. But would not work with a Windows VM on a Mac, even if you were able to create a custom EDID via SwitchResX (the Mac equivalent of ToastyX), because the M1/M2/M3 doesn't support tearing during VSYNC OFF. Technical Reason Why It Works: This is because the first step of tearing = good indicator if VRR will work when VRR is enabled at host OS + monitor level. Random tearing (as a temporary visual debugging method) means you've successfully disconnected frame-present timing from fixed Hz refresh rate. Tearing is simply mid-refresh-cycle splices of a new frame, indicating asynchronous attempts at delivering new frames to display, is now functioning. If that's solved, then making the refresh rate float (enable VRR in host drivers/host OS/host monitor) seamlessly "converts" the VSYNC OFF to VRR successfully, even if the VM software is VRR-unaware. The VRR-unaware software is configured as VSYNC OFF, something that existed for a long time pre-VRR, as a backwards compatibility technique. That's also happens to be how pre-VRR game software (e.g. 2004's Half Life 2 and the like) successfully worked with raster VRR (which arrived in the 2010s), you simply had to use VSYNC OFF at the game side, in order to get VRR working on a VRR-supported OS+GPU+display. The same is true for VRR-unaware VM software that still supports VSYNC OFF with visible tearing artifacts whenever VRR is turned off Sorry about the sidetrack, just Blur Busters (that I founded) knows this stuff; and I wanted to follow up; </Temporary Side Track> |
Basically I use a virtual machine with GPU passthrough to play games and have been using VRR for a while, so the issue doesn't seem to be there. |
Ah, GPU passthrough is different! That's easier. |
So for virtual displays, to achieve VRR, just edit EDID? |
In theory. There could be some gotchas, as virtual display drivers may do other behaviors that prevent VRR from working. |
Any update? I'd love to at least get access to a Apache/MIT codebase of a virtual display driver this year. May you contact me at [email protected] and we can negotiate -- I might have third party resources that may be able to help and I may be able to submit some improvements in due time. |
That's fine, I'll switch the license to a more permissive one soon.
I assume you were referring to the license when you said this, right? (So that should be covered by my above statement?) Or did you have something else in mind?
That does sound great! Contributions are most welcome. |
Either or both. I need maximum flexibility to figure out how to improve the codebase to meet multiple needs. As well as submit it back to the open source community (but also be able to use it in future proprietary Blur Busters software too). I'm open to many kinds of arrangement, but simply switching licenses would also be the simplest if you have no time to do the feature requests -- at least I'd have more options, whether via both funded developer and volunteer developer routes. I'd still want to contribute a bunch of changes back somehow (even if I used a funded software developer to do it), or make a forked open source project. Also, custom blur busting software is a very niche, with niche skills, so additional options are welcome! Obviously, if I am unable to find developer resources, then it may be a while, but the sooner it is Apache/MIT, the sooner I can find non-unobtainium developer options within the next several months. For those who want to contact me: For the actual work, I may have a modicum of funding available to an open source software developer, who's allowed to recontribute it back to any relevant opensource project (But only if it's on a MIT/Apache codebase -- I have simultaneous opensource & proprietary needs that I'm trying to make compatible). |
You can operate under the assumption that it's switched to MIT already (I'll get around to it soon, by the time you find anything, it'll already be switched, so it's not an issue). |
@mdrejhon It's switched now to MIT |
Fantastique! This just opened maybe three time as many developer options -- in a very difficult "nichengineering" project. Thank you! Keep in mind this is a self-funded passion project, so a bit of time may pass before I successfully move forward on getting the chess board setup. I will inform you when I do. |
I was just made aware of this bounty. Please be aware that any indirect display driver (IDD), by the design of the API, is taking captures of the desktop, which does, without a doubt impact latency and overall system performance of 3D workloads. See: Edit: As long as the goal isn't for bench-marking, this should be fine, but just throwing this out there as we see so many in the Looking Glass (also a capture application, but in a VM) community using variations on the Microsoft IDD Sample Driver (which is what this is) and not understanding why the performance tanks, or is unstable. |
Disambiguation: Performance benchmarking for maximum performance = no Some of the applications for this is black frame insertion for retro material (any emulator you wish to run), so that's low performance. Motion blur reduction via software means, ala beta.testufo.com/blackframes except works desktop wide in a way much more reliable (less erratic flicker) than DesktopBFI app. Another is to improve motion quality of low-CPU/low-GPU stuff on LCDs by adding IDD-based software overdrive (clone of ATI Radeon Overdrive from the early 00's). This includes even mere browser scrolling, since adding software-based overdrive to overdriveless laptop LCDs actually halves LCD GtG by more than half (yes, you can do it in a software shader!). The problem is that it mandatorily requires refresh-cycle precision independently of the frame rate of the underlying content, and needs to work on office/text/browser scrolling to improve motion quality benchmarks, so it's not practical to do with frame-injection. There are over 1000+ (very niche) use cases, but these are two examples. Possible more mainstream use cases would be filter injection (SweetFX, Reshade, NVIDIA FReestyle) but, those can be done by frame injection instead of refresh-cycle injection. On the other hand, it means you can apply effects Windows-wide, and in video playback, not just videogame frame buffers. For many esoteric use cases; Essentially, this is like "Every refresh cycle must be done and vetted by us" situation (much like VR, where it will automatically reproject if original frames are late). This may require extremely high thread priorities within the reprocessor. Degrading framerate is the lesser of evil in many specific use cases such as software-based custom overdrive curves for overdriveless mobile LCDs to improve motion clarity during LCD scrolling (scrolling often only uses 10% CPU and GPU anyway), things like that. I successfully implemented overdrive in a private TestUFO test, which I'll probably publish in 2025, so there's some internal precedents (newer than ATI Radeon Overdrive from twenty years ago). It's simply an A[B]=C thing where A is original subpixel greyshade, B is new subpixel greyshade, and C is overdive color, like using 220 to speed a pixel transition from 100 to 200 (dark grey to light grey, computed on a per-RGB channel basis). Easy shader work with a 256x256 overdrive lookup table. That's what display firmware software does (they actually cheap out on interpolated 17x17 overdrive lookup tables), but it also works GPU-side too. Only done whenever a pixel changes, and only for one refresh cycle after. Which means it's gotta be Hz-granularity, independent of underlying framerate. It can halve scrolling motion blur on the worst laptop LCDs (e.g. running TestUFO overdrive test on slow laptop LCDs like MacBook Pros or DELL/HP laptops). Shame I can't make this crossplatform, it even works in JavaScript at low overhead, so IDD should be doable. But doing it on PC can be done via IDD approaches. NOTE: While the earlier bounty has expired (I had a Dec 31 2023 deadline posted somewhere else but extended it into 2024) -- I am willing to extend it further but by invitation (e.g. a taker) for some delivery date in 2025. Please contact me mark [at] blurbusters.com to negotiate a possible new bounty. Or to simply donate the code, if you can only implement only a subset. Either way, biggest mandatory requirement is Apache/MIT or similar hobbyist+commercial permissive license, since it's too niche to be fully noncommercial only, and too niche to be fully commercial. It's something I've been trying to make happen for years. But it unlocks a lot of crazy-neat stuff! |
I'm Mark, the creator of Blur Busters and TestUFO.
I noticed you have a virtual display driver capable of custom refresh rates -- maybe you want to make minor modifications to meet an existing Blur Busters source code bounty?
For those not familiar with me -- I'm an indie-turned-business, and the Internet's biggest advocate for high refresh rates, and I am in over 25 peer reviewed research papers and I have an easier Coles Notes research portal Area 51 on BlurBusters.
TestUFO is my free display-testing/display-demoing website used by over 500 content creators (reviewers, youtubers, bloggers) that tests displays. Two of the biggest content creators are RTINGS (which uses my invention) and LinusTechTips (which used the pursuit camera in some tests).
I've been looking for a good open source virtual display driver as a base to produce drivers that can implement algorithms such as testufo.com/blackframes (software BFI) and testufo.com/vrr (simulated VRR on non-VRR displays), as well as hundreds of other fantastic temporal filters.
Even if not all filters are possible, a virtualized display driver with temporal-processing capabilities, would unlock a lot of neat capabilities for a lot of communities.
It could also be used to add subpixel-awareness for OLED displays (odd pixel structures) by scaling things in a custom-subpixel-pattern way, it was also posted here in ClearType improvement thread, but I'm posting here since I've now discovered this project:
$2K Bounty for a Virtual Display Driver capable of Temporal Filters
Which I crosspost here:
For qualifying for the bounty, some changes needed may include:
(legal if you're the only developer, or all devs/contributers of 100% of the source code retroactively agree)
Example (of hundreds) of possible benefits....
Some possible catches
Question: Are you the only developer, @MolotovCherry?
Note: It could even be a fork of this project if this is too dramatically different. The original project can remain GPL3, just the fork qualifying for the bounty would need to be one of the permissive licenses to support both the indies and businesses, as per above. Can even backport the Apache/MIT version to your GPL3 fork (one-way compatibility), if you want -- all good.
The text was updated successfully, but these errors were encountered: