Eric Anholt wrote:
> On Fri, 2008-06-06 at 15:39 +0200, Thomas Hellström wrote:
>   
>> Hi!
>>
>> A small suggestion to the core GEM interface:
>> Could you add a driver-private uint64_t member when a gem object is created?
>>
>> The primary purpose of this member would be to allow the implementation 
>> to choose the
>> initial backing-store for a GEM object.
>>
>> This is for primarily for situations where a shmem object is not desirable.
>>
>> A caller that doesn't care (dri2) would simply pass zero.
>>     
>
> As keithp said, we really didn't like the idea of having to extend the
> core ioctls for all flags that driver writers might come up with.
> However, it wasn't consistent to require that those other drivers
> support the "generic" version that was only be used on intel along with
> their own ioctls.  So I've moved the create, along with mmap, pread,
> pwrite, and set_domain, to device-specific.
>   
OK. Yes, that's sounds like a solution.
> We've talked with krh, and there are a couple of different viable ways
> to deal with the dri2 requirement for shared memory.  That was basically
> the only reason for it to be generic originally, and including use of
> graphics memory objects for non-graphics purposes is kinda dubious as
> part of our design process anyway.
>
>   
Yes, unless it's to enforce a local permission model, like the old DRM 
shmem maps did.

Anyway, one idea would perhaps be to have DRI2 request a function table 
from the drivers, that handles the shared memory actions DRI2 needs. 
That would effectively make DRI2 fit with whatever the driver provides 
and should make it possible to make DRI2 part of a release quite soon.

/Thomas




-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to