[Linaro-mm-sig] A few questions about the best way to implement RandR 1.4 / PRIME buffer sharing

[Daniel Vetter]

On Thu, Aug 30, 2012 at 10:34:23AM -0700, Aaron Plattner wrote:
> 4. There's no mechanism for double buffering the output sink
> 
> RandR allocates one pixmap on the output source screen and sets up tracking so
> the source driver can copy the screen into the shared pixmap.
> However, the sink driver scans out from the shared pixmap directly.
> There's no mechanism to
> prevent tearing on the sink side of the pipeline.
> 
> It seems like it would be nice if the source could trigger the sink device to
> flip between front and back buffers when the copy is finished, and get back a
> fence to indicate when the flip has occurred and the source can start the next copy.

Dave already answered your other questions, I'll chip in with some more
details on the in-kernel fencing that Maarten Lankhorst is working on.
Current wip code is available at

http://cgit.freedesktop.org/~mlankhorst/linux/

The v10-wip branch is the latest, with some experimental code to port ttm
over to the new core reservation code. The fencing itself would be all
kernel-internal with no explicit fence objects exposed to userspace: I.e.
the driver doing the pageflip would just wait for any write-fences (=
exclusive fences) before doing the pageflip and then attach a read (=
shared) fence on the to-be-swapped out fb that signals once the pageflip
completed (to avoid other gpus rendering into the new backbuffer while
it's still being displayed).

People involved in the discussion of this are mostly Maarten, Rob Clark
(from TI) and me, and most of the discussion happens on #dri-devel, but at
least Maarten&me should be at XDC in Nürnberg. Comments/discussion of this
code, especially whether the fence/reservation code would suit you for
shared buffers highly welcome. I'll definitely annoy any nvidia guy who
shows up at xdc about this ;-)

The longer-term idea is to port all drm/* drivers over to the new
reservation framework (hence the experimental ttm port), which would allow
us to dynamically evict even shared buffers (which should be rather useful
on highly constrained SoC iommus shared among a few graphics IP blocks).

Cheers, Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48