DK2's internal latency tester

There's not a ton of details, it seems, but here is what is in OVR_CAPI.h:

/// Does latency test processing and returns 'TRUE' if specified rgb color should
/// be used to clear the screen.
OVR_EXPORT ovrBool      ovrHmd_ProcessLatencyTest(ovrHmd hmd, unsigned char rgbColorOut[3]);

/// Returns non-null string once with latency test result, when it is available.
/// Buffer is valid until next call.
OVR_EXPORT const char*  ovrHmd_GetLatencyTestResult(ovrHmd hmd);

Additionally, there are two other functions implemented that are missing from OVR_CAPI.h that I belive were intended to go there:

OVR_EXPORT ovrBool ovrHmd_GetLatencyTestDrawColor(ovrHmd hmddesc, unsigned char rgbColorOut[3]);
OVR_EXPORT double ovrHmd_GetMeasuredLatencyTest2(ovrHmd hmddesc);

Other than that, there's lots of stuff that uses it internally. It does look like the distortion renderers handle drawing the color for you though. (Except for DirectX 9, which has a todo comment.) I'm guessing the above functions are primarily for developers trying to do raw latency tests without the distortion being involved.

Also, in case you were curious, the latency tester seems to be positioned at the right-top corner of the screen. The SDK draws a single colored pixel up there in release builds, and a 20x20 pixel square for debug builds.

Alright thanks! I only managed to download SDK just now (yay for slow connections and thunder) and started to skim it through.
I was just curious in general as it was one of the headline things in DK2 features page and it has been somewhat under the radar (well, only devs need it so why would it need to be anywhere else than in SDK and documentation?).

Man, I am not jealous of your internet! That's brutal.

I'm guessing the main reason for the lack of documentation on it is that they were scrambling for time and forgot/skipped it, or because Timewarp takes the latency tester into account. With the current design of the SDK, you couldn't have multiple things testing latency at once. Plus, since the latency up until the point the latency square is drawn is easily measurable, the latency tester is really only good for that "last mile" between the call to Present and the photons hitting your eye balls.

Any documentation on how these functions are to be used?

"kaetemi" wrote:
Any documentation on how these functions are to be used?

I'm pretty sure they're only useful if you're doing client side distortion. If you're using SDK based distortion the time management is baked into the SDK.

"jherico" wrote:
I'm pretty sure they're only useful if you're doing client side distortion.

I am.

"kaetemi" wrote:
Any documentation on how these functions are to be used?

For my own implementation, at the start of every frame I call ovrHmd_GetLatencyTestResult() at the start of a frame. Upon the completion of a successful latency tester run it returns a string you can parse using sscanf to find the result.

Then prior to rendering the distortion you call ovrHmd_ProcessLatencyTest() which will, if it returns true, will give you an RGB color you should render onto the screen.

This is where things get dicey. For the DK1 you simply draw a quad over the center of the field of view with that specific color - that's really all you have to do. With the DK2 it looks like you have to draw the quad in the top right corner of the screen, but there is no official documentation on that yet.

At this time it also appears that ovrHmd_GetLatencyTestResult() will continually return the results of the last latency test result, whereas in older SDKs it will only return as non-null if it has a result. Some amount of error handling has to be done as a result.

It also appears that since there is no way to programatically trigger the latency tester there is no way to actually get that API to work correctly with the DK2 - it will work with the DK1 because it responds to the button press.

As PathogenDavid pointed out, it appears there is a separate API used internally for the DK2 that they haven't exposed publicly yet. I have no idea if/when that will be enabled for client rendering, but at this time it appears inaccessible.

"PathogenDavid" wrote:
Also, in case you were curious, the latency tester seems to be positioned at the right-top corner of the screen. The SDK draws a single colored pixel up there in release builds, and a 20x20 pixel square for debug builds.

We were speculating about the lack of an optical sensor on reddit a little while ago, but given that they are doing a single pixel at the top right of the screen (which would actually be the top-left-most/first pixel the display receives via scan-out), this really makes me suspect they're getting the result directly from the video stream instead of relying on an external sensor.

It would actually make a ton of sense - latency from that point out is essentially constant and easily accounted for. The variable latency is really between the software and the display.

Either that or I'm completely blind and failing to see an obvious optical sensor ;)

Yup, I ended up trying to find it on my DK2 too. (Note: We were speculating that the latency tester doesn't work in SDK 0.4.0, but later found out we were both observing the same bug - Although I've yet to try the USB replug trick to get it working.)

Since it is only one pixel and due to the lack of any visible hardware, I'm incline to agree with the video stream theory.

"PathogenDavid" wrote:
Since it is only one pixel and due to the lack of any visible hardware, I'm incline to agree with the video stream theory.

Since the DK2 display is scanned starting with the top right corner, then downwards and to the left, it's trivial to implement a latency tester simply by looking at a spike in power consumption (the DK2 display is a OLED matrix, where there's a significant difference is current between pixels being off or an), or a little bit more complex by looking at the LVDS signal going into the display, when the first occurance of a certain pattern of bits goes in.

So yes, this is most certainly not implemented using a photodiode.