[PATCH 04/11] xf86: Add PRIME flipping functions to ScreenRec

[Michel Dänzer]

On 09.12.2015 13:21, Alex Goins wrote:
> On Tue, 8 Dec 2015, Michel Dänzer wrote:
>> On 26.11.2015 11:39, Alex Goins wrote:
>>>
>>> (Start/Stop)FlippingPixmapTracking are merely the double-buffered
>>> equivalents of (Start/Stop)PixmapTracking, allowing the source driver to do
>>> whatever setup and teardown necessary for presenting on the two shared
>>> pixmaps.
>>
>> AFAICT there's no implementation of these hooks in this series. Is it
>> really necessary (or even worth) adding these hooks instead of just
>> calling Start/StopPixmapTracking separately for the front and back pixmaps?
>
> Yeah, there's no open source implementation of these right now, but essentially
> they just allow the source driver to do whatever specific setup necessary to
> present to either of the two supplied shared buffers from the same headsurface,
> as well as having presentation driven by PresentTrackedFlippingPixmap() as
> opposed to some sort of internal mechanism.

Not sure adding an API without showing how it's supposed to be
implemented is going to fly.


> It would probably be possible to implement (Start/Stop)PixmapTracking such that
> multiple calls on the same mscreenpix with different shared pixmaps achieves
> that behavior, but it would be less explicit and would probably result in some
> unnecessary setup/teardown when switching to externally driven presentation on
> the second call.
> 
> As of right now, I would expect multiple calls to StartPixmapTracking() with the
> same mscreenpix but different shared pixmaps to result in two independently
> driven shared pixmaps presenting from the same mscreenpix. I've been trying to
> avoid tampering with the semantics of the old paths as much as possible.

AFAICT presentation is entirely driven by the drivers, so it's not
obvious to me why it couldn't work with the existing
StartStopPixmapTracking API.

One thing that might be nice, to avoid the master driver unnecessarily
updating a shared pixmap from the screen pixmap, would be a hook for the
slave driver to ask the master driver to update a shared pixmap. As you
mentioned in another post before, the slave driver could hook into the
master screen pixmap damage directly for triggering presentation. Then
the control flow could be:

Drawing to screen pixmap
 -> damage triggers slave driver to start presentation
  -> slave driver asks master driver to update shared pixmap
   -> slave driver submits flip from shared pixmap


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer