From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Hellstrom Subject: Re: dma-buf non-coherent mmap Date: Thu, 31 Oct 2013 22:38:30 +0100 Message-ID: <5272CDD6.3060809@vmware.com> References: <52728CA5.4030506@vmware.com> <5272C055.5010400@vmware.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from smtp-outbound-1.vmware.com (smtp-outbound-1.vmware.com [208.91.2.12]) by gabe.freedesktop.org (Postfix) with ESMTP id 9EECBF005E for ; Thu, 31 Oct 2013 14:38:33 -0700 (PDT) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces@lists.freedesktop.org Errors-To: dri-devel-bounces@lists.freedesktop.org To: Rob Clark Cc: "linaro-mm-sig@lists.linaro.org" , Daniel Vetter , Thomas Hellstrom , "dri-devel@lists.freedesktop.org" List-Id: dri-devel@lists.freedesktop.org On 10/31/2013 10:10 PM, Rob Clark wrote: > On Thu, Oct 31, 2013 at 4:40 PM, Thomas Hellstrom wrote: >> On 10/31/2013 06:52 PM, Rob Clark wrote: >>> On Thu, Oct 31, 2013 at 1:00 PM, Thomas Hellstrom >>> 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 >