[Mesa-dev] [PATCH 3/3] glx/dri3: Request non-vsynced Present for swapinterval zero.

[Mathias Fröhlich]

Hi,

On Tuesday, December 16, 2014 19:30:04 Mario Kleiner wrote:
> Hmm. For benchmarking i think i'd consider that a mild form of cheating. 
> You get higher fps because you skip processing like the whole gpu blit 
> overhead and host processing overhead for queuing / validating / 
> processing the copy command in the command stream, so the benchmark 
> numbers don't translate very well anymore in how the system would behave 
> in a non-benchmark situation?
Agree, sounds somehow like cheating.
Nevertheless, I think I have observed the nvidia blob doing the same and
probably even more under some circumstance. I could get framerates
there that I could not explain by issuing the same draw as before with
the buffer swap only being scheduled every n frames.
So, if you think about this, it sounds like cheating even more.
There is not only the savings that you mentioned with the swap not happening.
That's what the test application in this case already did to trigger the effect.
Looking at this I thought that if a buffer swap is scheduled, even
the draws that are not yet executed on the gpu and belonging to previous swaps
that are now hidden by the now scheduled swap are skipped.
Sure, if doing this you need to be careful if something else that must be
measurable by the application like reading back buffer data happens in between.
I have never tried to drive a verification of this interpretation to the
end, so I may be wrong.
But I ever thought that this sounds like the main reason why some gl drivers can draw
so much more gears a second then others can - just don't draw the ones that are already
proven not to be observable anymore by the application or user.
So, yes, this is kind of cheating. ... probably not the only 'cheat' for a GL
driver to be fast in a lot of 'benchmarks'.

Greetings

Mathias