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

[Thomas Hellstrom]

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.

/Thomas

>
> Kristian
>
>> Thanks,
>> /Thomas
>>
>>
>>
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org
>> https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=l5Ago9ekmVFZ3c4M6eauqrJWGwjf6fTb%2BP3CxbBFkVM%3D%0A&m=odFlWkDI%2BmOWVatvfBb6%2B%2BwJ0wfBvjphI%2FNXAVVJGBQ%3D%0A&s=b566a35c98538f7394cb4bfc2741bd38af1ba4f2f351a695ca6417b09563c6bd