Raster "Interrupts" / Beam Racing on GeForces/Radeons!

Talk to software developers and aspiring geeks. Programming tips. Improve motion fluidity. Reduce input lag. Come Present() yourself!
Post Reply
User avatar
Chief Blur Buster
Site Admin
Posts: 6509
Joined: 05 Dec 2013, 15:44

Raster "Interrupts" / Beam Racing on GeForces/Radeons!

Post by Chief Blur Buster » 09 Jun 2018, 23:09

Hello Blur Busters Forums readers!

Some of you may have noticed talks of "scanline based" and "raster based" or "lagless VSYNC" or "beam racing" recently in modern graphics programming -- as a method of reducing input lag for things like emulators, virtual reality, and other lag-critical applications. This is all raster-based stuff!
- Virtual reality beam racing programming (Android)
- Lagless VSYNC ON Mode in emulators -- WinUAE/GroovyMAME
- New RTSS frame capping via Scan Line
- Etc.

Before you read further, make sure you have at least a faint idea of the complex "raster programming" involved in the classic programming days -- Atari 2600 TIA, Commodore 64 raster interrupts, Amiga Copper, or any raster technique or "Racing The Beam".

Image
This book is on Amazon.

For those who have never heard of beam racing -- There is a great WIRED Magazine Article about this book.

One of its image is also peripherally useful useful to understand the crazy numbers stuff you see in Custom Resolution Utilities too:

Image
(For Custom Resolution Utility / ToastyX CRU users -- Porches/Sync is hidden offscreen signal data not too dissimilar to this. In reality, bottom overscan = "Vertical Front Porch" in Custom Resolution Utility, and "Horizontal Blank" is actually both the Horizontal Porches/Sync.)

So, now on the topic of beam racing....
VSYNC OFF tearlines are just rasters!
Every tear line created in humankind, are essentially rasters. It was not until roughly 10 years ago that modern computers became fast enough with precise clocks (e.g. RTDSC, QueryPerformanceCounter, etc) -- and this technique is still very little used until latency-critical applications came along. Today, look at what we all have accomplished!

So, with encouraging from me to several emulator authors (and the author of RTSS frame rate capper, too) -- emulator authors included, are now beginning to do modern-era beam racing as methods of reducing input lag (emulators, RTSS, etc). WinUAE now have frameslice based beamracing (synchronization of real raster with emulator raster), and there's also an experimental (unofficial) GroovyMAME patch available.

The Tearline Jedi Demo
(Written by me!)

Now, I'd like to introduce one Blur Busters projects that are currently in progress.
It's a cross-platform raster demo (Tearline Jedi Demo) -- World's first platform-independent rasterdemo -- that works on GeForces / Radeons / Intel / Android GPUs!

The software below compiles on PC and Mac (no #ifdefs in the main module!)

phpBB [video]


While raster-exactness is not needed for emulators due to jittermargin technique (hide tearlines in repeat-frameslicing), Tearline Jedi does require it, so I go above and beyond.

A few of you already saw my earlier "Use the mouse to drag tearline demo". That requires pretty demanding raster-exact precision, so I've wasted a lot of time researching how to pull that off. I needed this code for another project I am doing, so Tearline Jedi is a good raster-learning sandbox!

phpBB [video]


Recruiting Co-Credit

I haven't released the Tearline Jedi demo yet because I'm still debating whether to make it a submission to a demoscene party (e.g. Assembly 2018). Regardless, it will be open source afterwards. (Demoscene submissions allow opensource after demoscene submission).

If any volunteer programmer wants to help me improve Tearline Jedi Demo (the "VSYNC OFF Tearlines Are Just Rasters" concept) to more proper demoscene standards, contact me -- mark@blurbusters.com -- I'd put it up initially on a private git -- and obviously you'd get full credit as a co-programmer with all the creds.

phpBB [video]


The challenge is it is a hybrid between retro era (of raster interrupt era of 8-bit/16-bit platforms) and modern era (powerful GPUs), so if submitting for Assembly 2018 (Thursday August 2nd) as a remote outsider submission. According to rules, one doesn't have to attend. It would have to be a Realtime Demo entry (not Oldskool since it'd run on their modern high-end NVIDIA platform). https://www.assembly.org/summer18/demoscene/participate

And guess what... I think I am the first person to create a cross-platform raster-dependent Kefrens Bars demo that works on Radeons & NVIDIA on both PC and Mac!

Cross Platform Rasters Now Possible

Thanks to a technique that distilled rasters to three minimum requirements:
(1) Existence of precision counters (e.g. RTDSC instruction)
(2) Existence of VSYNC timestamps
(3) Existence of tearlines (aka VSYNC OFF)

With (1)+(2)+(3) it becomes unnecessary to poll a raster register. The position of a tearline is a precision time-based offset from a VSYNC timestamp. Thusly, with some creativity, rasters now becomes cross-platform (works on D3D, OpenGL, Mantle, Metal, Direct2D, etc) as long as the minimum requirements are successfully met. Then it becomes possible to guess the raster-exact scanline position of a tearline to a very accurate margin. (...Any refresh rate. We even found a way to make it work during variable refresh rates too, in the Emulator thread... The raster accuracy is within 1-2% without knowing the signal horizontal scanrate, and within 0.1% accuracy if knowing the signal horizontal scanrate -- minimally on any platform, all one needs is to listen to the VSYNC timestamps / VSYNC events -- the heartbeat of the blanking intervals is all you need to know -- and then using a precision counter to guess the current raster relatively accurately without needing a raster register -- all modern systems have microsecond precision counters available.)

So, here's a little surprise:
The world's first cross-platform raster-generated Kefrens Bars demo!
If you don't know what a Kefrens Bars is, it's a famous demo made back in the Amiga Copper days.. The effect is successfully replicated using raster beam raced VSYNC OFF.

Some of you already know this from private email, but I have decided to post this in this thread, to try and recruit a demoscene submission helper:

phpBB [video]


Yes, it's written in cross platform C# (open source MonoGame engine -- coding is similiar to older Microsoft XBox programming). I intentionally "glitch" the demo at the end by trying to launch software in the background (That messes up the timings, creating genuine rastery glitches), and it crashes near the end due to a bug. But it's really nice to see how the raster glitches with computer loading. 7000 frameslices per second generating Kefrens Bars in real time!

Over 100 frame slices per refresh cycle -- each frameslice is a "pixel row" generated raster-realtime in Kefrens Bars.

This demo is completely impossible to screenshot, given each "pixel row" (roughly ~14 pixel rows at 1080p 120Hz and roughly ~7 pixel rows at 1080p 60Hz -- the Kefrens Bars become higher resolution at lower refresh rates due to more frameslices per refresh cycles) of the Kefrens Bars is a completely separate VSYNC OFF frameslice that is currently being beamraced in realtime with a new custom Kefrens Bars position every frameslice.

The Kefrens Bars algorithm done pixel-row-at-a-time just like Amiga and Copper days, except timings are much more forgiving (timing errors simply manifest itself as pixel-row-height errors, as seen when pausing during the glitched section) -- but other than that, it's a true, bona-fide, fully-raster-generated Kefrens Bar demo. It's simply by sheer GPU brute force that we can now do this crossplatform, on PC and Mac, NVIDIA GeForce and AMD Radeon. (Intel GPUs also work, albiet at much lower frameslice rate).

Learning Experience Applicable to Emulators

Image

Image

For more information, see Beam-Raced Lagless VSYNC Technique For Emulators.
Programming General Practices of PC-based beamracing
- Use one core for a busysleep thread for near-microsecond accuracy of tearlines. Yes, not kosher to busysleep, but it improves beamrace accuracy.
- Use Flush() after Present() to improve beamracing sync accuracy. That kills performance, but doesn't matter for emulator context (even on mobile GPUs)
- Use High Performance Mode (use API to turn off power management for improved accuracy)
- More GPU is used up in the first few scanlines at top (Windows compositing thread), so render in advance (e.g. 1st frameslice of next refresh cycle can be rendered while scanning-out bottom of previous frame)
- If you use D3DKMTGetScanLine() rather than a temporal offset between VSYNC timestamps, put tiny busysleeps between polls, as D3DKMTGetScanLine is an expensive API
- Treat framebuffer height as a circular buffer (sweep-overwrite previous frame, rather than black) for better jittermargin overlapping refresh cycles.
- Keep in mind, debug mode may not always have accurate beam racing especially if outputting debug output simultaneously other screens such as consoles (multimonitor simultaneous updates creates beamracing issues). Rendering a debug text overlay on top of the framebuffer actually interferes less

Thinking: Submit To Demoscene Event?

If any one of you programmers want to help me refine/fancy/improve this "idea" & submit this to one of the demoscene events? (Email or PM me).

And then we'd make this open source right after. This is too simple graphics now, but these can be fancied up / polished more to something that is more appealing to modern audiences while still wowing 8-bit and 16-bit audiences.

I'll just open source eventually -- but I'm holding off to see if I can submit this to one of the demoscene events.

Comments welcome from raster-experienced programmers -- on this hobby side project.

Thank you!
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

       To support Blur Busters:
       • Official List of Best Gaming Monitors
       • List of G-SYNC Monitors
       • List of FreeSync Monitors
       • List of Ultrawide Monitors

User avatar
Chief Blur Buster
Site Admin
Posts: 6509
Joined: 05 Dec 2013, 15:44

Re: Raster "Interrupts" / Beam Racing on GeForces/Radeons!

Post by Chief Blur Buster » 10 Jun 2018, 14:43

My tweet on this has 25 Likes and over 10,000 views.
The author of the "Racing The Beam" book has retweeted.
Also have posted on the pouet.net forums too.

Even if you're not able to help out, I'm happy to hear suggestions/referrals to others -- email mark@blurbusters.com
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

       To support Blur Busters:
       • Official List of Best Gaming Monitors
       • List of G-SYNC Monitors
       • List of FreeSync Monitors
       • List of Ultrawide Monitors

User avatar
Chief Blur Buster
Site Admin
Posts: 6509
Joined: 05 Dec 2013, 15:44

Re: Raster "Interrupts" / Beam Racing on GeForces/Radeons!

Post by Chief Blur Buster » 12 Jun 2018, 14:57

OK, new video:

phpBB [video]


Higher frame slice rate than the earlier video, so better looking Kefrens Bars. And extra Kefrens Bars. I glitch it at the end by dragging around a window.
  • An audacious abuse of plain old standard VSYNC OFF
  • Standard GPUs. Standard Direct3D and OpenGL. Standard VSYNC OFF. Crossplatform. Radeon/GeForce. PC/Mac.
  • ~8000 frameslices per second
  • ~8000 tearlines per second
  • Over 100 tearlines per refresh cycle.
  • 1 pixel row per framebuffer
  • Each pixel row is separated by a tearline.
Those are real-time generated raster graphics of Atari TIA lore, with pixels hitting the graphics output in 1/8000sec after Present() or glutSwapBuffers() ;)

Obviously, a crude rasterdemo, but real-raster Kefrens Bars used to require assembly language. This is nerfy-scripty C#. I don't think a true real-raster Kefrens Bars have ever been done in a managed (garbage collected) programming language (C#) until I did this.
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

       To support Blur Busters:
       • Official List of Best Gaming Monitors
       • List of G-SYNC Monitors
       • List of FreeSync Monitors
       • List of Ultrawide Monitors

ad8e
Posts: 62
Joined: 18 Sep 2018, 00:29

Re: Raster "Interrupts" / Beam Racing on GeForces/Radeons!

Post by ad8e » 18 Sep 2018, 00:31

What license do you plan on releasing this code under?

User avatar
Chief Blur Buster
Site Admin
Posts: 6509
Joined: 05 Dec 2013, 15:44

Re: Raster "Interrupts" / Beam Racing on GeForces/Radeons!

Post by Chief Blur Buster » 18 Sep 2018, 12:46

Apache 2.0
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

       To support Blur Busters:
       • Official List of Best Gaming Monitors
       • List of G-SYNC Monitors
       • List of FreeSync Monitors
       • List of Ultrawide Monitors

ceztko
Posts: 2
Joined: 06 Aug 2018, 14:28

Re: Raster "Interrupts" / Beam Racing on GeForces/Radeons!

Post by ceztko » 11 Nov 2019, 10:39

Chief Blur Buster wrote:Apache 2.0
Am I correct to say that Tearline Jedi it's the same C# beam racing sample announced in this thread? Has the source code been released? If not, is it still the plan to release it eventually?

Cheers

User avatar
Chief Blur Buster
Site Admin
Posts: 6509
Joined: 05 Dec 2013, 15:44

Re: Raster "Interrupts" / Beam Racing on GeForces/Radeons!

Post by Chief Blur Buster » 14 Nov 2019, 23:14

ceztko wrote:
Chief Blur Buster wrote:Apache 2.0
Am I correct to say that Tearline Jedi it's the same C# beam racing sample announced in this thread? Has the source code been released? If not, is it still the plan to release it eventually?
Yes, eventually -- though wouldn't mind a private volunteer to help polish it up for a demoscene submission (inquire within to mark[at]blurbusters.com if you're an experienced C# developer with creds) before release. I've been busy on other very important Blur Busters projects so the codebase needs more polishing up.

More information in this pouet.net thread. I missed that demoscene deadline because of other projects, so would have to be the 2020 event. All developers who contributed can be in a credits scene. Then it can go opensource afterwards after the submission. Rules for many demoscene submissions is not to go opensource beforehand...
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

       To support Blur Busters:
       • Official List of Best Gaming Monitors
       • List of G-SYNC Monitors
       • List of FreeSync Monitors
       • List of Ultrawide Monitors

ceztko
Posts: 2
Joined: 06 Aug 2018, 14:28

Re: Raster "Interrupts" / Beam Racing on GeForces/Radeons!

Post by ceztko » 17 Nov 2019, 10:17

Chief Blur Buster wrote:Yes, eventually -- though wouldn't mind a private volunteer to help polish it up for a demoscene submission (inquire within to mark[at]blurbusters.com if you're an experienced C# developer with creds) before release. I've been busy on other very important Blur Busters projects so the codebase needs more polishing up.
It's a pitty...now I'm definetely too busy but I could be the guy: I worked in the render team of game developed in C# using a custom engine written in DX11, and I definetely love clean code (I'm a bit tired of cleaning other people code, though). If I have some free time during vacation I may contact you around Christmas, but don't hold breath.

If you let me go a bit off topic: I read the reaction of mame devs in the issue you opened suggesting implementing beam racing. They were quite harsh, but I actually understand their point. Instead, have you tried to contact Khronos to work on APIs to add in Vulkan to aid development of low input latency engines? For example I found the following in the comments of these old vulkan samples:

Code: Select all

WORK ITEMS
==========
[..]
- Implement an extension that provides accurate display refresh timing (WGL_NV_delay_before_swap, D3DKMTGetScanLine).
[..]
This confirms to me there could be interest in low input latency and this nvidia OpenGL extension WGL_NV_delay_before_swap could be an experimental attempt to solve the same issue, but it seems work stalled since WGL/NV means for Windows/Nvidia only. Maybe trying to work directly with Khronos providing your feedback on the topic could be the right way to work towards a proper cross-platform API. Be ready to evaluate other possible solutions because it's possibile D3DKMTGetScanLine didn't get into official OpenGL because it's just too heavy/burdensome to implement in native drivers.

User avatar
Chief Blur Buster
Site Admin
Posts: 6509
Joined: 05 Dec 2013, 15:44

Re: Raster "Interrupts" / Beam Racing on GeForces/Radeons!

Post by Chief Blur Buster » 20 Nov 2019, 18:11

ceztko wrote:
Chief Blur Buster wrote:Yes, eventually -- though wouldn't mind a private volunteer to help polish it up for a demoscene submission (inquire within to mark[at]blurbusters.com if you're an experienced C# developer with creds) before release. I've been busy on other very important Blur Busters projects so the codebase needs more polishing up.
It's a pitty...now I'm definetely too busy but I could be the guy: I worked in the render team of game developed in C# using a custom engine written in DX11, and I definetely love clean code (I'm a bit tired of cleaning other people code, though). If I have some free time during vacation I may contact you around Christmas, but don't hold breath.
Nice! Next Assembly demo is August 6th, 2020. Completion of Tearline Jedi codebase could easily be done prior to then.

At least, let's begin an email collaboration -- while this is a Blur Busters Back Burner project, appreciate the help.

I put a lot of work into the codebase, and want to open source after getting a useful achievement out of it (e.g. demoscene submission).
Any optional Mac experience? The same code tree also compiles and runs under Mac, but there is some help needed to create a proper Mac VSYNC listener, and also need to incorporate ad8e's work in a better VSYNC timestamp filter engine (simulating a raster register without a real raster register, simply using a temporal offset between de-noised VSYNC timestamps) -- he has already written the code in C++ and I need to find time to port it to C# (or help, of course).

Also there's still a BountySource for the RetroArch beam racing (realraster->emuraster synchronization). It peaked at $1142 but since there has been no takers, it's down to $492 after others pulled their bounty. But much of the remaining bounty is from my personal donations and is available if you wish to tackle that one. :) .... That said, Tear Line Jedi is a much easier project to begin with, it's kind of like a Kindergarten 101 Beam Racing -- you can create a beam raced splitscreen using only 50 to 100 lines of C# programming as a Tear Line Jedi module, so I suspect once I open source, it'll quickly become a great Beginner's Beam Racing sandbox!

Reach out to me privately anyway, with a short message, so at least we can stay in touch...
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

       To support Blur Busters:
       • Official List of Best Gaming Monitors
       • List of G-SYNC Monitors
       • List of FreeSync Monitors
       • List of Ultrawide Monitors

Post Reply