From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [RFC PATCH] drm/vgem: virtual GEM provider Date: Wed, 11 Jan 2012 21:32:04 +0100 Message-ID: <20120111203204.GC3855@phenom.ffwll.local> References: <1326309561-21055-1-git-send-email-ajax@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-we0-f177.google.com (mail-we0-f177.google.com [74.125.82.177]) by gabe.freedesktop.org (Postfix) with ESMTP id A149F9E9F1 for ; Wed, 11 Jan 2012 12:30:00 -0800 (PST) Received: by wera10 with SMTP id a10so1220830wer.36 for ; Wed, 11 Jan 2012 12:29:59 -0800 (PST) Content-Disposition: inline In-Reply-To: <1326309561-21055-1-git-send-email-ajax@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: Adam Jackson Cc: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org On Wed, Jan 11, 2012 at 02:19:21PM -0500, Adam Jackson wrote: > This is about as minimal of a virtual GEM service as possible. My plan > is to use this with non-native-3D hardware for buffer sharing between X > and DRI. > > The current drisw winsys assumes an unmodified X server, which means > it's hopelessly inefficient for both the push direction of SwapBuffers/ > DrawPixels and the pull direction of GLX_EXT_texture_from_pixmap. I'm > still working through the details of what the xserver support will look > like, but in broad strokes it's "use vgem for CreatePixmap and > optionally the shadowfb". > > Obviously alpha quality, mostly looking for feedback on the approach or > any glaring bugs. Eventually I'd like to see solutions for sharing gem > objects between drm devices and/or the dma_buf API, but that's a ways > down the road. > > Signed-off-by: Adam Jackson I like this and the userspace abi is pretty much what I expect for such a beast. I think integration with other drivers/dma_buf can just happen with prime, nothing special needed. A few quick comments on the code - no need to allocate a gem mmap offset if you only expose the direct shm mmap. This also will make the BUG in _fault correct, otherwise userspace could try to mmap well-guessed ranges on the fd and hit this. - unsigned int in ioctl structs instead if __u32 (and also use __u64). - I don't see why you have a size arg for the mmap ioctl, simply mapping the entire bo is likely all you ever want. - The fops is inline instead of separate and constified. Otherwise I couldn't find anything to complain about ;-) Cheers, Daniel -- Daniel Vetter Mail: daniel@ffwll.ch Mobile: +41 (0)79 365 57 48