On Tue, 21 Feb 2012 11:08:52 -0500
Adam Jackson wrote:
> On Tue, 2012-02-21 at 15:34 +, 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
On Tue, Feb 21, 2012 at 3:03 PM, Adam Jackson wrote:
> On Mon, 2012-02-20 at 18:10 +0100, Ben Widawsky wrote:
>> On Thu, 16 Feb 2012 05:52:12 -0800 (PST)
>> Jakob Bornecrantz wrote:
>> > Any reason why you are not using the dumb_bo interface? I at least
>> > would like to be able to offer vgem
On Tue, 2012-02-21 at 15:34 +, 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
On Mon, 2012-02-20 at 18:10 +0100, Ben Widawsky wrote:
> On Thu, 16 Feb 2012 05:52:12 -0800 (PST)
> Jakob Bornecrantz wrote:
> > Any reason why you are not using the dumb_bo interface? I at least
> > would like to be able to offer vgem on the vmwgfx device when the
> > host has disabled 3D.
>
>
On Mon, 2012-02-20 at 18:10 +0100, Ben Widawsky wrote:
On Thu, 16 Feb 2012 05:52:12 -0800 (PST)
Jakob Bornecrantz ja...@vmware.com wrote:
Any reason why you are not using the dumb_bo interface? I at least
would like to be able to offer vgem on the vmwgfx device when the
host has disabled
On Tue, Feb 21, 2012 at 3:03 PM, Adam Jackson a...@redhat.com wrote:
On Mon, 2012-02-20 at 18:10 +0100, Ben Widawsky wrote:
On Thu, 16 Feb 2012 05:52:12 -0800 (PST)
Jakob Bornecrantz ja...@vmware.com wrote:
Any reason why you are not using the dumb_bo interface? I at least
would like to be
On Tue, 2012-02-21 at 15:34 +, 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
On Tue, 21 Feb 2012 11:08:52 -0500
Adam Jackson a...@redhat.com wrote:
On Tue, 2012-02-21 at 15:34 +, 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
On Thu, 16 Feb 2012 05:52:12 -0800 (PST)
Jakob Bornecrantz wrote:
> - Original Message -
> > From: Adam Jackson
> >
> > 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.
> >
On Thu, 16 Feb 2012 05:52:12 -0800 (PST)
Jakob Bornecrantz ja...@vmware.com wrote:
- Original Message -
From: Adam Jackson a...@redhat.com
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
- Original Message -
> From: Adam Jackson
>
> 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
From: Adam Jackson
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
On Thu, 9 Feb 2012 00:19:27 +0100, Ben Widawsky wrote:
> From: Adam Jackson
> +static void vgem_gem_free_object(struct drm_gem_object *obj)
> +{
> + if (obj->map_list.map)
> + drm_gem_free_mmap_offset(obj);
> +
> + drm_gem_object_release(obj);
> +}
From: Adam Jackson a...@redhat.com
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
On Thu, 9 Feb 2012 00:19:27 +0100, Ben Widawsky b...@bwidawsk.net wrote:
From: Adam Jackson a...@redhat.com
+static void vgem_gem_free_object(struct drm_gem_object *obj)
+{
+ if (obj-map_list.map)
+ drm_gem_free_mmap_offset(obj);
+
+ drm_gem_object_release(obj);
+}
15 matches
Mail list logo