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

[Mathias Fröhlich]

Hi Aaron,

On Monday, December 29, 2014 08:01:53 Aaron Plattner wrote:
> 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.

Hmm, the initial observation was probably even older than compositing
at least on our workgroups machines which had switched off compositing for
a long time. Sure the observation was with a case where you render as
fast as possible and where one frames amount of draw is small
compared to the speed of the gpu.
You can probably tell me for sure what can possibly happen. I am sitting
in front of a black box that I can observe and interpret. A proof of
such an interpretation is often hard to impossible. I hoped to have
this already put somehow into the previous mail.

No, there is nothing to track. And no I even don't think there is. If we
are in render as fast as possible mode and if a new frames image
supersedes the previous one and if it can be proven that this old image
is not reaching the user anymore, generally, I do not see why it
should be generally illegal to optimize away superfluous work.
That does *not* mean that there are no valid use cases where you want to prove
that every rendered frame needs to reach the end users eye, like it is the
case for Marios application.

Thanks

Mathias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg-devel/attachments/20150111/34a44ca6/attachment-0001.html>