On Wed, Jan 11, 2012 at 04:04:20PM -0500, Adam Jackson wrote:
> On Wed, 2012-01-11 at 12:16 -0800, Eric Anholt wrote:
>
> > I remember at one point you had a plan along the lines of passing shmem
> > fds across the protocol. I'm curious what happened to that -- too hard
> > to get the passing to
On 2/7/12 6:28 PM, Ben Widawsky wrote:
> On Wed, Jan 11, 2012 at 04:04:20PM -0500, Adam Jackson wrote:
>>> If you can, I recommend using the intel gtt mapping type of mmap ioctl,
>>> where it gives you back an offset that you use the mmap syscall on, and
>>> implement the vgem_gem_fault to map its
On 2/7/12 6:28 PM, Ben Widawsky wrote:
On Wed, Jan 11, 2012 at 04:04:20PM -0500, Adam Jackson wrote:
If you can, I recommend using the intel gtt mapping type of mmap ioctl,
where it gives you back an offset that you use the mmap syscall on, and
implement the vgem_gem_fault to map its pages, inst
On Wed, Jan 11, 2012 at 04:04:20PM -0500, Adam Jackson wrote:
> On Wed, 2012-01-11 at 12:16 -0800, Eric Anholt wrote:
>
> > I remember at one point you had a plan along the lines of passing shmem
> > fds across the protocol. I'm curious what happened to that -- too hard
> > to get the passing to
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
On Wed, Jan 11, 2012 at 8:32 PM, Daniel Vetter wrote:
> 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
On Wed, 2012-01-11 at 12:16 -0800, Eric Anholt wrote:
> I remember at one point you had a plan along the lines of passing shmem
> fds across the protocol. I'm curious what happened to that -- too hard
> to get the passing to work, or something else? I'm just thinking of
> kernel developer grumbl
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/
Draw
On Wed, 2012-01-11 at 12:16 -0800, Eric Anholt wrote:
> I remember at one point you had a plan along the lines of passing shmem
> fds across the protocol. I'm curious what happened to that -- too hard
> to get the passing to work, or something else? I'm just thinking of
> kernel developer grumbl
On Wed, Jan 11, 2012 at 8:32 PM, Daniel Vetter wrote:
> 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
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
On Wed, 11 Jan 2012 14:19:21 -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 ho
On Wed, 11 Jan 2012 14:19:21 -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 ho
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/
Draw
14 matches
Mail list logo
