OpenGL: calibration loop when context is created

[slomp]

I was a bit late for this discussion #1393, but I think we can minimize drift substantially with a better cpu-gpu clock calibration upfront, when the context is created.

@bruno-dasilva Would you be able to give this branch a try, without toggling TRACY_OPENGL_AUTO_CALIBRATION to see if your drift problems go away?

Assuming all goes well, we could consider increasing the Recalibration period to, say, 10s when TRACY_OPENGL_AUTO_CALIBRATION is enabled (or rather, let the user specify the recalibration period as the value of TRACY_OPENGL_AUTO_CALIBRATION).

[slomp]

(as it is, my draft makes OpenGL.hpp always dependent on <chrono>, which may or may not be acceptable, but we can discuss that later if my drift hypothesis can be plausibly demonstrated)

[bruno-dasilva]

@slomp sure let me give this a try.

[bruno-dasilva]

hmm. It does look a better initial drift (only 600us instead of multiple ms)

This is what I see with no manual drift correction:

Start of the game (note frame number)

Couple minutes later:

With manual drift correction the frames still aren't perfect depending on if you look early game or later game (as in the original it seems drift is not constant on my machine/binary).
But the initial drift being more correct did seem to help

[bruno-dasilva]

As a side note, I'm not entirely sure how the gpu timer works, but in our game/this binary the simulation is running on the same thread as the opengl draw calls - so the gpu is frequently without work while the simulation is running (possible downclocking to idle?). I wonder if running at lower utilization like this results in more drift.

Also I would guess that the original synchronization is happening during initial game load/load screen, where draw calls are not happening much at all (so, again an idle gpu). Perhaps that is what's causing the initial major drift?

[bruno-dasilva]

Wait hold on a rebase fucked up and i didnt notice, let me try again (so I was just on vanilla 0.13.1 lol)
edited/fixed

[bruno-dasilva]

ok sorry should be good to go now. It did indeed seem to improve (but not fix) the drift, anecdotally.

[slomp]

Thanks for running the experiment!

I'll keep this draft around and try to run some experiments myself.

It must be noted that the way that CPU and GPU timestamps are correlated will always skew the correlation in such a way that the GPU time is always behind the CPU:
This is what's currently in master:

tracy/public/tracy/TracyOpenGL.hpp

Lines 216 to 217 in 7ee4380

	glGetInteger64v( GL_TIMESTAMP, &tgpu );
	const int64_t refCpu = Profiler::GetTime();

I kept the same strategy in this draft in order to "control the variables", but in case you're curious, you could try uncommenting the "mid-point" approach to see if it is more accurate:

tracy/public/tracy/TracyOpenGL.hpp

Lines 239 to 240 in 5240b96

	//bestCpu = cpu0 + range / 2; // mid-point estimate
	bestCpu = cpu1; // right-bias estimate

I'll ping you again once I can find some cycles to resume work on this draft.

[bruno-dasilva]

sounds good, pretty easy for me to test, so just let me know.