Hello,
API Requirements
For an automated benchmarking app, doing separate tasks, and sometimes in combination
-
API to set scanline number during Latent Sync.
ARGS (1): Raster scan line number (integer)
Not timing critical as long as I eventually have timestamp of eventual first frame that this executes upon
-
API to set frame rate cap (non Latent Sync)
ARGS (1): Frame rate cap number (float)
Not timing critical as long as I eventually have timestamp of eventual first frame that this executes upon
-
API to enable/disable always doing Flush() after Present(), this stabilizes tearlines.
ARGS (1): true or false (boolean)
Not timing critical as long as I eventually have timestamp of eventual first frame that this executes upon
-
API to set flag to trigger a white flash (or specified color flash) in the SK's next scheduled frame presentation. Should be at one edge of screen, either left or right edge, enough room for a photodiode tester
ARGS (2):
...edge color of frame flash in RGB value (integer)
...whether I want that frame to Flush() even if I didn't do step four (boolean)
Not timing critical as long as I eventually have two timestamps: (A) of time of flag-set, and (B) of post-Present()
-
API to set a callback function to send me RTDSC/QPC timestamps of all the various timestamps above.
ARGS (1): Callback function. SK would call my callback to give me a timestamp and what it was for (you could use enums such as TIMESTAMP_CAP_CHANGE, TIMESTAMP_FLUSH_CHANGE, TIMESTAMP_POST_PRESENT, etc)
Not timing critical for API call timing or callback timing
-
API to set a non-flash color (prevent false alarms with in-app/in-game content)
ARGS (1): Edge RGB color to draw for frames that are not flashed, or -1 to disable (signed integer)
Not timing critical as long as I eventually have timestamp of eventual first frame that this executes upon
Immediacy of Item 4
The goal is I need item 4 to be able to tell SK's next frame presentation event (whenever it may be, at its existing schedule) to do a "draw flash + Present() + Flush() + immediately timestamp".
As long as a boolean flag in Item 4 can be set anytime randomly during the previous frametime, right up to roughly ~0.1ms (100us) prior SK's next scheduled frame presentation event -- I am happy. Timestamps provide the data that I need for my mathematics. It just simply needs to be a thread-safe boolean variable that the frame-presentation thread can check. And the same thread will also draw the white rectangle immediately before Present()+Flush().
SK does not need to touch/modify frame timing AT ALL. I was able to figure out I can use timestamps to solve my problem.
Flush() is important for certain things like stabilizing tearlines. It kills GPU performance, but it improves lag-test numbers for the purposes of determining display-only latency (GPU-port-to-photons) by nigh completely filtering the computer out of the lag number.
Timestamps Requirement
To eliminate timing-precision requirements from API calling, I have worked very hard to eliminate timing-precision requirements for SK, by simply requiring timestamps. Timestamps should be of a microsecond counter such as QueryPerformanceCounter() or RTDSC.
Except where additional timestamps are specified, timestamps are grabbed immediately after the Present() event, or immediately after the Present()+Flush() event corresponding to the said frame in item 1/2/3/4
I just want to be signalled of the timestamps, so I know to mathout/validate/invalidate my test results based on the stream of timestamps.
Goal: Beamracing to filter display lag from GPU/software lag
With all of this data, I have Blur Busters invented algorithms to successfully filter display lag away from GPU/software lag, during lag testing too. (This is called the "Blur Busters beam raced display latency filter algorithm").
"beam raced latency measurements" is an algorithm we've invented to be able to filter display latency separately of GPU/software latency). I would just lag-test all scanline numbers one by one (or binary search towards). After algorithming it all out (on the timestamps), the lowest lag number would be the display-latency only.
Blur Busters plans to open-source this algorithm for all photodiode testers, but we are successfully doing this with our in-house photodiode tester to filter display lag numbers away from GPU/software lag. (IMPORTANT: Credit to Blur Busters is mandatory,
Open to alternatives
I'm open to using RTSS or SpecialK, just need programmatic control of the scanline number from a background analyzer app if possible -- this won't be used in production gaming, but only during benchmarking sessions.
I realize RTSS might be "Right Tool For Right Job" since it currently has more API capabilities (at the moment) but I like SK's superior scanline sync, so, kind of trying to figure out how to have cake and eat it too.
If SK can do something like this, even as an undocumented setting, I'd be happy! I realize that this might be a big ask, but I bet this will be a big help to a ton of websites including ourselves.
Free Blur Busters Invention
If any lagtest vendors such as OSRTT, LDAT, etc implements beamracing in latency testing, as a method of filtering display lag from GPU/software lag, then please credit Blur Busters. If implementing this algorithm in your photodiode tester software or whatever open source Arduino tester you've homebrew'd. Thank you!
Alternatively, wait for us to publish a white paper on this (preferred), but this is revolutionary for a PC to be able to self-filter its own latencies completely, isolating GPU-output-to-photons latency (aka display lag), for certain kinds of benchmarking, or to colorcode latency bars, or other future visualizations (like framerate-vs-lag graphs for testing all VRR framerates, etc).