On Wed, Oct 12, 2011 at 3:24 PM, Rob Clark <robdclark@xxxxxxxxx> wrote: > On Wed, Oct 12, 2011 at 9:01 AM, Dave Airlie <airlied@xxxxxxxxx> wrote: >>> But then we'd need a different set of accessors for every different >>> drm/v4l/etc driver, wouldn't we? >> >> Not any more different than you need for this, you just have a new >> interface that you request a sw object from, >> then mmap that object, and underneath it knows who owns it in the kernel. > > oh, ok, so you are talking about a kernel level interface, rather than > userspace.. > > but I guess in this case I don't quite see the difference. It amounts > to which fd you call mmap (or ioctl[*]) on.. If you use the dmabuf fd > directly then you don't have to pass around a 2nd fd. > > [*] there is nothing stopping defining some dmabuf ioctls (such as for > synchronization).. although the thinking was to keep it simple for > first version of dmabuf > Yes a separate kernel level interface. Well I'd like to keep it even simpler. dmabuf is a buffer sharing API, shoehorning in a sw mapping API isn't making it simpler. The problem I have with implementing mmap on the sharing fd, is that nothing says this should be purely optional and userspace shouldn't rely on it. In the Intel GEM space alone you have two types of mapping, one direct to shmem one via GTT, the GTT could be even be a linear view. The intel guys initially did GEM mmaps direct to the shmem pages because it seemed simple, up until they had to do step two which was do mmaps on the GTT copy and ended up having two separate mmap methods. I think the problem here is it seems deceptively simple to add this to the API now because the API is simple, however I think in the future it'll become a burden that we'll have to workaround. Dave. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
