OpenGL: calibration loop when context is created

(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)

@slomp sure let me give this a try.

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

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?

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

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

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: https://github.com/wolfpld/tracy/blob/7ee4380f64f7ad146a978385f75fda249c9ddc32/public/tracy/TracyOpenGL.hpp#L216-L217

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: https://github.com/wolfpld/tracy/blob/5240b9667511c131b4d36e77be1fde060378a695/public/tracy/TracyOpenGL.hpp#L239-L240

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

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