Re: Small GEM core interface suggestion.
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
Re: Small GEM core interface suggestion.
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
Re: Small GEM core interface suggestion.
On Thu, Jun 12, 2008 at 10:14 AM, Keith Packard [EMAIL PROTECTED] wrote: On Thu, 2008-06-12 at 09:03 +0200, Thomas Hellström wrote: Yes, unless it's to enforce a local permission model, like the old DRM shmem maps did. Abusing GEM objects to hold state which never touches the graphics card is an ugly way to accomplish this. I guess it's easy and convenient to shoot this part of the design down at this point, but please consider: - at the time I did this, TTM was the one memory manager and already supported this feature. - using a drm provided shared memory scheme re-uses the existing auth scheme. - doesn't introduce exotic dependencies to something that's *supposedly* an os-agnostic feature. Of course, even Linux doesn't have a memory manager yet, so worrying about depending on shm_open() is academic. Anyway, with the brouhaha out the way, I do agree that just using regular posix shared memory is nicer and more flexible and I have a set of patches that implements it. I'll probably change the DRI interface to make it accept a void pointer for the sarea, so for cases like EGL where reader and writer of the sarea are in the same process, you can just malloc the sarea. cheers, Kristian - 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
Small GEM core interface suggestion.
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. /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
Re: Small GEM core interface suggestion.
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? Please feel free to add a driver-specific ioctl to include whatever parameters you need. They're cheap, and it will let you customize it for your driver needs more easily than trying to add undefined data to an existing interface. -- [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
