[Mesa-dev] [PATCH v3 00/11] Map support for GBM

[Daniel Vetter]

On Sun, Apr 27, 2014 at 12:05:48PM +0200, Thomas Hellstrom wrote:
> On 04/25/2014 11:36 PM, Kristian Høgsberg wrote:
> > On Tue, Apr 8, 2014 at 1:49 PM, Thomas Hellstrom <thellstrom at vmware.com> wrote:
> >> On 04/08/2014 10:28 PM, Ander Conselvan de Oliveira wrote:
> >>> From: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira at intel.com>
> >>>
> >>> Changes from previous version:
> >>>
> >>>   - make it clearer that the interface is optional;
> >> No! this is still a NAK!
> > I don't agree with your NAK, Thomas.  We can't write APIs that only
> > supports what every graphics card out there can do.  GL itself is a
> > good example of how functionality or fast-paths can be made available
> > in an optional way through extensions.  In this case, we're missing
> > out on a zero-copy path for texturing from a sw-rendered buffer.  The
> > intended usecase is for one process to use gbm (that is, not loading a
> > GL driver or using GL API) to allocate a buffer and render to it using
> > CPU rendering.  Then share it by passing a dma-buf fd across a socket
> > to a GL-using process, which will then be able to create a GL texture
> > from it and texture from it.
> Yes. I'm aware about the use case. But GL extensions typically go
> through some form of review and issues brought up are usually resolved.
> In this particular case, this extension, while enabling a fastpath
> (which is good), may cause lazily written apps to be unusable on
> incoherent architectures (which is very bad. In particular for vmware),
> see [1].
> 
> If we take GL as an example, traditionally mapping and unmapping had to
> be done on buffer objects, and then transferred to the render buffer
> using some form of unpacking. I think this enables smart drivers to do a
> zero-copy upload, as well as providing a damage region (using
> writepixels / texSubImage) for incoherent / tiled architectures. The
> buffer object usage type is specified so that the driver can choose the
> type of caching. (Should the software writer be able to read from the
> buffer with any performance for example?).
> 
> This issue has been brought up many times before, also in the context of
> dma-buf mmap / unmaps (it's exactly the same issue),
> and at some point is has to be resolved. So far nobody has wanted it
> badly enough to specify a decent API, and such an API would IMO need to
> deal with
> 
> * Buffer usage (write, read, read/write etc.)
> * Specifying damage regions (before read and after write) for incoherent
> and tiled architectures.
> 
> That way the API would force app writers to think also about the
> slowpath while fully enabling the zero-copy fastpath.
> 
> >
> >> The reason is, just like the last time, that as soon as the major
> >> drivers implement this, The users of the interface will stop caring
> >> about the "slowpath" (no mmap() available). There are some other good
> >> reasons too, like for example the buffers being tiled or uncached.
> >>
> >> If you desperately need a generic way to access accelerated buffer
> >> contents using the CPU, then implement something similar to
> >> glTex[sub]Image() or gl[read|write]Pixels.
> > The semantics of the map/unmap API is that unmap acts as a flush and
> > the pixels in the mapped buffer aren't guaranteed to be visible to
> > other users of the gbm bo until after map.  That lets you implement
> > map as a malloc and unmap as glTexImage2D + free.  Which is the path
> > the application would have to fall back to anyway.  But instead of
> > forcing everybody to go through the copy path (as we would if we
> > implemented something like glTexImage2D in gbm), we now have the
> > option of eliminating the copy when the underlying GPU architecture
> > allows it.
> 
> [1]
> Yes, but the problem is when someone allocs a 1600x1200 bo, maps it and
> writes a single character. Then unmaps it and textures from it. We all
> know that eventually there will be apps out there that does this, and
> that also couldn't care less about the slow-path (non-zero copy). The
> app will crawl on any non-coherent architecture. So in this case, with
> this interface, I think the NAK is very well justified. At least for the
> API in its current form.

Aside for this discussion: All the tablet/phone/whatever you want to call
them SoCs intel ships (since there are also hsw SoCs now out there making
this complicated) Intel gfx is non coherent.

We have support for optionally using coherent buffer objects even there,
but that needs some awareness on the receivers side to work. And if you do
more than a single texture pass it won't be optimal. Nor will it work for
display as-is.

/me hides again

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch