On Wed, Oct 12, 2011 at 9:34 AM, Dave Airlie <airlied@xxxxxxxxx> wrote: > 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. I'm not against it, but if it is a device-independent interface, it just seems like six of one, half-dozen of the other.. Ie. how does it differ if the dmabuf fd is the fd used for ioctl/mmap, vs if some other /dev/buffer-sharer file that you open? But I think maybe I'm misunderstanding what you have in mind? BR, -R > 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
