I can be eager, but I won't follow up on the Mamedev bug tracking again after that final followup I did. (Apologies)Calamity wrote:Hi Mark, I'll post back later if I have a chance, anyway I beg you not to harass MAMEdev about this, it won't work.
Sometimes I am too eager, I know!
Agreed.Calamity wrote:Hi Mark,
I didn't find that knowing vbi exactly was critical for the implementation. Just aligning slice #0 with vblank start works good enough for me.
Knowing VBI time only gives an approximately ~5% fudge factor.
A 480p signal has a 525 vertical total and a 1080p signal usually has a 1125 vertical total. The 480:525 ratio (45/525th of a refresh) or the 1080:1125 ratio (45/1080th of a refresh) is small enough that you don't really need to care about the VBI size. This is mostly cherrypicking a couple milliseconds at the most.
The VBI-time can default to a simple percentage constant of ~4% or thereabouts, but automatically optionally refined if the system is able to successfully detect the Vertical Total of the current video mode. This allows much tighter beam-chasing safety margins (shaving off up to a couple more milliseconds).
One question is which API's unblock at the beginning of vblank, or at the end of vblank.
I have to do further work to do confirmations, but for VSYNC ON Direct3D, it appears that the wait-for-vblank may unblock Present() at the bottom of the refresh cycle, so for a 1080p signal with VT1125, there's a mandatory pause of ~45/1125th of 1/60th of a second before the top scanline of a 1080p (a 0.666666 millisecond delay between the exit of Present() and the first scanline appearing). OpenGL would behave the same way.
The return from a VSYNC ON framebuffer flip provides a useful VBI heartbeat reference, that is accurate enough (with vsynctester.com filtering algorithms -- even with 10% jitter + 10% skipped VBI) to get a VSYNC heartbeat accurate enough to software-calculate a predicted raster scan line "register" variable with an accuracy of only ~1-2% error (VBI size known) or within ~5% error (VBI size unknown)! This provides a portable cross-platform method of emulating a scan line register as a fallback.
For simplicity, just use a constant based on an average realworld VBI, not emulated VBI -- so just use HDTV default....
Code: Select all
const double VBI_DEFAULT_PERCENTAGE = (45.0/1125.0);
This constant becomes your estimated VBI time (of a refresh cycle) between the last scanline of previous refresh, and first scanline of next refresh. If using blocking VSYNC ON calls (e.g. Present() ..) this returns at the beginning of the VBI, so you can use this to estimate the time before the raster begins visibly scanning.
No rush. I want to gel on this during the coming years to work with a few developers (that I've been privately-or-publicly messaging) -- possibly including you -- to create a generic open-source raster polling library for beam chasing applications.Calamity wrote:I'll follow later, it's a pain to write from the phone.
Basically it's just a raster discovery library:
-- Returns True/False if raster is pollable (Returns: Impossible, Software-Calculated & Hardware-Poll)
-- Returns current raster line (either hardware poll or software-calculated from a VBI heartbeat)
-- Returns current floating-point refresh rate (important for synchronization)
-- Returns current scanout direction (relative to current screen orientation)
-- Returns microsecond-accurate timestamp of last VBI event (de-jittered internally, maybe similar to vsynctester.com algorithm).
-- Returns True/False if exact video timings is pollable (optional, but improves beam-chasing accuracy)
-- Optional Current video timings in floating-point horizontal scanrate, floating-point vertical refreshrate, Vertical Total, VBI size, etc
(waterfall best-attempt to poll using standard APIs, via EDIDs, via modelines, etc)
-- Optional Current VBI size (floating-point percentage of a refresh cycle -- aka, how long "InVBlank" stays TRUE)
(The latter 3 is only necessary for near-scanline-exact beam chasing algorithms).
-- Other APIs (e.g. microsecondtimestamps, precision callback events for VBI or raster (raster interrupts!)) may be provided.
I have found collections of several APIs that can be rolled together into a multiplatform Mac/Linux/PC/Android library for making it much easier to do cross platform tile-based beam-chased rendering algorithms. Some VR software for Android is already using raster-synchronized apps, and it is possible to guess the smartphone scan position to a 5% accuracy without needing the native raster poll.
A waterfall cascade on the most-preferred APIs to the least-preferred APIs would be capable of providing sufficient data for accurate 10-tile beam chasing (90% lag reduction) on most platforms, and single-scanline beam chasing on a few platforms.
Even 4-tile beam chasing (75% input lag reduction) would be very doable in many existing emulator architecture, even if it means repeating the HLSL steps four times an emulator refresh.
By making a generic raster-poll library available, more (willing) emulator developers can start to implement optional beamchasing into their emulators with less difficulty, and with less odds of breaking existing architectures. It may take a year, but I already have some source code in Blur Busters Strobe Utility that I am willing to donate to this long-term cause of making beam chasing easier.
This library could potentially become popular in a few years from now with VR developers & emulator developers by hiding all the messy complexity. It could even potentially pressure graphics driver makers (NVIDIA, AMD) into making front-buffer rendering a standard API option again. (BlurBusters has influenced the gaming monitor industry with new testing techniques & influencing the widespread deployment of blur reduction backlights, so some of our eager advocacy do sometimes eventually stick -- after time -- though sometimes after a few years).
So, I feel, getting started on a generic cross-platform raster poll library will be an important world's first step.
I think, maybe we all (the developers I've been messaging) should start a github on this, and obviously maybe you have an interest on doing this.
No rush in reply, until you're back at a computer if you prefer, but once you do.... Let me know what you think about an open-source raster discovery library, to make beam-chasing programming easier for the eager developers who want to work on this.