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. 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. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------- 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
