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

[Aaron Plattner]

On 12/16/2014 11:22 PM, Mathias Fröhlich wrote:
>
> 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

Really?  Do you have a link to a report of this, or some description of 
how this happened?  I could see it happen if you're running a composite 
manager, but that's only because the application can render to its 
redirected window as fast as it wants, but it's up to the compositor to 
sample those frames at its own pace.  If that's the scenario you're 
thinking of, then it's just a side effect of the non-Present compositor 
design.

> 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