On Mon, Dec 5, 2011 at 4:09 PM, Arnd Bergmann arnd@arndb.de wrote:
On Monday 05 December 2011 14:46:47 Rob Clark wrote:
I sort of preferred having the DMABUF shim because that lets you pass a buffer around userspace without the receiving code knowing about a device specific API. But the problem I eventually came around to: if your GL stack (or some other userspace component) is batching up commands before submission to kernel, the buffers you need to wait for completion might not even be submitted yet. So from kernel perspective they are "ready" for cpu access. Even though in fact they are not in a consistent state from rendering perspective. I don't really know a sane way to deal with that. Maybe the approach instead should be a userspace level API (in libkms/libdrm?) to provide abstraction for userspace access to buffers rather than dealing with this at the kernel level.
It would be nice if user space had no way to block out kernel drivers, otherwise we have to be very careful to ensure that each map() operation can be interrupted by a signal as the last resort to avoid deadlocks.
map_dma_buf should be documented to be allowed to return -EINTR.. otherwise, yeah, that would be problematic.
Arnd _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel