From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ben Widawsky Subject: Re: [PATCH 1/5] drm/vgem: virtual GEM provider Date: Tue, 21 Feb 2012 18:41:20 +0100 Message-ID: <20120221184120.5650765c@intel.com> References: <1328743171-13750-2-git-send-email-ben@bwidawsk.net> <959188052.1150535.1329400331995.JavaMail.root@zimbra-prod-mbox-2.vmware.com> <20120220181007.04ba20fe@intel.com> <1329836614.30884.18.camel@atropine> <1329840532.30884.42.camel@atropine> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by gabe.freedesktop.org (Postfix) with ESMTP id 6F56A9E761 for ; Tue, 21 Feb 2012 09:42:24 -0800 (PST) Received: by wgbdt10 with SMTP id dt10so4142998wgb.13 for ; Tue, 21 Feb 2012 09:42:22 -0800 (PST) In-Reply-To: <1329840532.30884.42.camel@atropine> 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 Tue, 21 Feb 2012 11:08:52 -0500 Adam Jackson wrote: > On Tue, 2012-02-21 at 15:34 +0000, Dave Airlie wrote: > > > Not sure what you mean there, those 3 APIs are just to create dumb > > unaccelerated objects, > > probably are fine for vgem's use. For scanout we create framebuffer > > objects from a dumb object > > then we do shove it back in from above. > > > > So if the ioctls are doing the same thing we should just use the > > generic dumb ioctls for vgem. > > That's... not at all obvious from the comments or the ioctl argument. > > /* create a dumb scanout buffer */ > struct drm_mode_create_dumb { > uint32_t height; > uint32_t width; > uint32_t bpp; > uint32_t flags; > /* handle, pitch, size will be returned */ > uint32_t handle; > uint32_t pitch; > uint64_t size; > }; > > This doesn't look like "here, kernel, I am handing you a pointer". It > looks instead like "please, kernel, create this thing for me", and the > comment above sure does imply the thing being created is explicitly for > scanout purposes. > > If it's just creating unaccelerated objects and the "bind to > framebuffer" part is somewhere else, then sure, vgem should probably > just use that. I'm still going to need that to exist as its own device > node not backed by a physical device, but I don't think that's > contentious. I'm on board with the dumb ioctls as well. I also need a device node, and some test ioctls for the prime stuff, but mmap and create are no issue to switch over at the moment.