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. > Thanks, > /Thomas Yours, Daniel -- Daniel Vetter Mail: daniel@xxxxxxxx Mobile: +41 (0)79 365 57 48 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
