cancel
Showing results for 
Search instead for 
Did you mean: 

DK2's internal latency tester

Miffyli
Honored Guest
So now that DK2 is out I have been going over "getting started" guides et cetera I haven't even seen a word about DK2's latency tester that is one of the highlights at DK2 order page. I know it's not the biggest thing in DK2 nor I shouldn't be worried about it unless I develope stuff, but just out of curiosity: Where is it in DK2 and how one uses it?

PS: Sorry if info for this is in SDK. I am still trying to download it but connection is being extermly lazy today...
10 REPLIES 10

PathogenDavid
Honored Guest
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.

Miffyli
Honored Guest
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?).

PathogenDavid
Honored Guest
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.

kaetemi
Honored Guest
Any documentation on how these functions are to be used?

jherico
Adventurer
"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.

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

I am.

dghost
Honored Guest
"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.

dghost
Honored Guest
"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 😉

PathogenDavid
Honored Guest
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.