On 11/15/2010 07:45 PM, Daniel Vetter wrote: > Hi Thomas, > > Thanks for your comments about ttm and vmwgfx. Some of my own ideas about > where this might all be heading below. > > On Mon, Nov 15, 2010 at 08:25:16AM +0100, Thomas Hellstrom wrote: > >> Hi, Daniel, >> >> My main concerns previously for embedding GEM objects as user-space >> references for TTM has been twofold and implementation specific. >> >> 1) The locking has been using global mutexes where local spin- or >> RCU locks have been more appropriate. It looks like this has finally >> been / is finally going to be addressed. >> > gem object lookup / insert has always (iirc) been protected by a spinlock. > drm/i915 is just a bit inefficient with lookups, hence this spinlock > showing up in profiling. > > >> 2) The gem object is too specialized for general purpose use: >> a) The shmem member has no natural use with TTM except possibly as a >> persistent swap storage, but in an ideal world, TTM would talk to >> the swap cache directly so in the longer term there is no need for >> the shmem object at all. >> > Chris Wilson is working on a gem_vm for i915 that employs a address_space > per bo and directly manages swap entries and has its own page allocator > (actualy cflushed page cache). I haven't yet looked into this closely > (especially the ttm part), but this might (at least in parts) be shareable > between i915 and ttm. At least it gets rid of the shmfs inode in struct > drm_gem_object! > > >> b) Implementations may want to use other user-space visible objects >> than buffer objects: >> For example fence objects or CPU synchronization objects. The common >> traits of / operations on these are user-space visibility, >> inter-process visibility, refcounting and destruction when the >> relevant file is closed. >> >> Hence a class that provides only the user-space handles, naming >> (flink), refcounting and registering with a file handle would be the >> best choice of a "base" class. Traditional Gem objects could derive >> from those and provide any extra *generic* members needed for buffer >> objects. >> >> This doesn't really affect your work though. Just some comments on >> why vmwgfx don't use GEM objects by default and how they could be >> made optimal for TTM-aware drivers. >> > Yeah, I've noticed that vmwgfx is the (sometimes) sole user of many of the > more fancy stuff in ttm. And I also don't like the duplication between gem > and ttm. My plan (i.e. wishful thinking) is to have a common set of helper > functions that can be shared between i915, radeon and nouveau and any > other driver with a gem-like interface (i.e. buffer-objects + execbuffer, > gpu<->cpu sync abstracted away by the kernel). Leaving the cracy stuff for > drivers that need it (vmwgfx). Nothing concrete though (besides a new > testing rig to start hacking on nouveau), I'll intend to simply plow > along, hunting for common patterns. >
Sounds good. I actually think the only thing which is currently vmwgfx-specific are the ttm_objects and the ttm_locks. TTM objects could really be replaced by gem objects with the bo-specific part stripped, as discussed above. And then there is the ttm lock to allow concurrent execbufs running. /Thomas > >> Thanks, >> /Thomas >> > Yours, Daniel >
