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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
