On Tue, Apr 8, 2014 at 1:49 PM, Thomas Hellstrom <thellst...@vmware.com> wrote: > On 04/08/2014 10:28 PM, Ander Conselvan de Oliveira wrote: >> From: Ander Conselvan de Oliveira <ander.conselvan.de.olive...@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@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
