Any way to determine the vsync wait time?

[fluffy]

tl;dr: I want to determine approximately how much rendering headroom time I have.

Quite some time ago I implemented an adaptive resolution mechanism to adjust the render quality on the fly based on GPU load. However, the big problem with it is that when vsync is on it's difficult to determine how much time is actually being spent on rendering vs. how much is spent simply waiting for vsync. So like if I'm getting 30FPS I don't know if that's because I'm getting a solid 30 or if I could get 60 if I were to just bump my resolution down a little tiny bit (or, conversely, if I'm getting 30FPS I don't know if getting 60 is a lost cause and I could increase my render quality to take advantage of it).

A hack I've used in the short term is to track both the average and variance of the total frame time and if the variance is less than 5% I assume it's sitting stably at the halfway point between vsync intervals, but as you might imagine this doesn't really work all that well.

I can easily determine my update time and deduct that from the frame time to determine render+vsync time (and use that to further determine if it's worth reducing video quality to try to bump up to the next vsync interval), but is there any way to also deduct vsync time? Unfortunately it seems that the entirety of the graphics finalization/buffer swap+vsync are all wrapped up in love.graphics.present() and there's no way I can tell from the API to further pick that apart. I've also tried adding love.graphics.flushBatch() to the end of my love.draw() routine to see if I can capture the timing of that but it doesn't seem to have any significant time usage either.

[pgimeno]

Yes, love.graphics.present is the one that waits for vsync. It also waits for the GPU to finish rendering.

If you only want to do it in your computer, and it's not intended for release, then you can just compare the vsync times with the no-vsync times. But I suspect you want to integrate it as part of your game logic.

I guess that if you could do a present() with vsync disabled followed by a present() with vsync enabled, the first one would force completion of the frame, so you could measure the time it takes. But I'm not sure that's possible. The graphics would also be wrong, because it would be swapping twice without rendering anything in between, but it would be useful for measuring purposes. To compensate for that, first do a present() with vsync disabled and measure it, then do another present() with vsync disabled (to swap back to the previous buffer) and then yet another present() but this one with vsync enabled. This would work if the rendering is guaranteed to take less than the frame time.

Perhaps it's possible by modifying the LÖVE source, or with some FFI hackery that I can't think of right now. Maybe there's some way to have vsync disabled and call some function that waits for vsync. If there's one, it seems it will be ugly.

[AuahDark]

There's actually

Code: Select all

refreshrate

key in table that is returned at 3rd return value of love.window.getMode. If you calculate

Code: Select all

1/refreshrate - updateDrawTime

where

Code: Select all

updateDrawTime

is time needed to update and draw your game (before love.graphics.present call), that's your vsync wait time.

[pgimeno]

Sorry to say but that post was spam, copied from here: https://stackoverflow.com/questions/241 ... wait-block to promote the search engine ranking of a web site. (Post was removed by mods)