On Wed, Oct 12, 2011 at 9:34 AM, Dave Airlie airlied@gmail.com wrote:
On Wed, Oct 12, 2011 at 3:24 PM, Rob Clark robdclark@gmail.com wrote:
On Wed, Oct 12, 2011 at 9:01 AM, Dave Airlie airlied@gmail.com 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.