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

[Aaron Plattner]

On 08/30/2012 10:31 AM, Aaron Plattner wrote:
> So I've been experimenting with support for Dave Airlie's new RandR 1.4 provider
> object interface, so that Optimus-based laptops can use our driver to drive the
> discrete GPU and display on the integrated GPU.  The good news is that I've got
> a proof of concept working.
>
> During a review of the current code, we came up with a few concerns:
>
> 1. The output source is responsible for allocating the shared memory
>
> Right now, the X server calls CreatePixmap on the output source screen and then
> expects the output sink screen to be able to display from whatever memory the
> source allocates.  Right now, the source has no mechanism for asking the sink
> what its requirements are for the surface.  I'm using our own internal pitch
> alignment requirements and that seems to be good enough for the Intel device to
> scan out, but that could be pure luck.
>
> Does it make sense to add a mechanism for drivers to negotiate this with each
> other, or is it sufficient to just define a lowest common denominator format and
> if your hardware can't deal with that format, you just don't get to share
> buffers?
>
> One of my coworkers brought to my attention the fact that Tegra requires a
> specific pitch alignment, and cannot accommodate larger pitches.  If other SoC
> designs have similar restrictions, we might need to add a handshake mechanism.
>
> 2. There's no fallback mechanism if sharing can't be negotiated
>
> If RandR fails to share a pixmap with the output sink screen, the whole modeset
> fails.  This means you'll end up not seeing anything on the screen and you'll
> probably think your computer locked up.  Should there be some sort of software
> copy fallback to ensure that something at least shows up on the display?
>
> 3. How should the memory be allocated?
>
> In the prototype I threw together, I'm allocating the shared memory using
> shm_open and then exporting that as a dma-buf file descriptor using an ioctl I
> added to the kernel, and then importing that memory back into our driver through
> dma_buf_attach & dma_buf_map_attachment.  Does it make sense for user-space
> programs to be able to export shmfs files like that?  Should that interface go
> in DRM / GEM / PRIME instead?  Something else?  I'm pretty unfamiliar with this
> kernel code so any suggestions would be appreciated.

There's also a #4 that didn't seem relevant to cross-post to linaro-mm-sig:

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.

-- Aaron