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

[Kristian Høgsberg]

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.

> 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.

Kristian

> Thanks,
> /Thomas
>
>
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev