On 10/31/2013 10:10 PM, Rob Clark wrote: > On Thu, Oct 31, 2013 at 4:40 PM, Thomas Hellstrom <thellstrom at vmware.com> > wrote: >> On 10/31/2013 06:52 PM, Rob Clark wrote: >>> On Thu, Oct 31, 2013 at 1:00 PM, Thomas Hellstrom <thellstrom at vmware.com> >>> wrote: >>>> Hi! >>>> >>>> I'm just looking over what's needed to implement drm Prime / dma-buf >>>> exports >>>> + imports in the vmwgfx driver. It seems like most dma-bufs ops are quite >>>> straightforward to implement except user-space mmap(). >>>> >>>> The reason being that vmwgfx dma-bufs will be using completely >>>> non-coherent >>>> memory, whenever there needs to be CPU accesses. >>>> >>>> The accelerated contents resides in an opaque structure on the device >>>> into >>>> which we can DMA to and from, so for mmap to work we need to zap ptes and >>>> DMA to the device when doing something accelerated, and on the first >>>> page-fault DMA data back and wait for idle if the device did a write to >>>> the >>>> dma-buf. >>>> >>>> Now this shouldn't really be a problem if dma-bufs were only used for >>>> cross-device sharing, but since people apparently want to use dma-buf >>>> file >>>> handles to share CPU data between processes it really becomes a serious >>>> problem. >>>> >>>> Needless to say we'd want to limit the size of the DMAs, and have mmap >>>> users >>>> request regions for read, and mark regions dirty for write, something >>>> similar to gallium's texture transfer objects. >>>> >>>> Any ideas? >>> well, I think vmwgfx is part of the reason we decided mmap would be >>> optional for dmabuf. So perhaps it is an option to simply ignore >>> mmap? >>> >>> BR, >>> -R >> >> Well, I'd be happy to avoid mmap, but then what does optional mean in this >> context? >> That all generic user-space apps *must* implement a workaround if mmap isn't >> implemented? > well, mmap was mostly just added because it was needed by android for > ION on dmabuf. > > I think it is an option to just not use dmabuf mmap in a linux > userspace. I mean, we could also define some ioctls to give us pwrite > and other similar sort of functionality if it is needed.
I think that if direct user-space cpu-access to dma-buf is ever needed by linux, something like that is a better option. Best IMHO would be to avoid user-space cpu-access completely. Regards, /Thomas > > BR, > -R >
