dri-devel Archive on lore.kernel.org
 help / color / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Thomas Hellstrom <thomas@shipmail.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 0/3] embed drm_gem_object into radeon_bo
Date: Mon, 15 Nov 2010 19:45:55 +0100
Message-ID: <20101115184555.GA3484@viiv.ffwll.ch> (raw)
In-Reply-To: <4CE0E05C.7030507@shipmail.org>

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@ffwll.ch
Mobile: +41 (0)79 365 57 48

  reply index

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-13 20:57 Daniel Vetter
2010-11-13 20:57 ` [PATCH 1/3] drm/radeon: embed struct drm_gem_object Daniel Vetter
2010-11-13 20:57 ` [PATCH 2/3] drm/radeon: introduce gem_to_radeon_bo helper Daniel Vetter
2010-11-13 20:57 ` [PATCH 3/3] drm/radeon: kill radeon_bo->gobj pointer Daniel Vetter
2010-11-15  7:25 ` [PATCH 0/3] embed drm_gem_object into radeon_bo Thomas Hellstrom
2010-11-15 18:45   ` Daniel Vetter [this message]
2010-11-15 20:48     ` Thomas Hellstrom
2010-11-15 10:20 Sedat Dilek
2010-11-16 17:05 Sedat Dilek
2010-11-16 17:30 ` Daniel Vetter
2010-11-16 19:37   ` Sedat Dilek
2010-11-16 19:54     ` Sedat Dilek
2010-11-27  9:47 Daniel Vetter
2010-11-28  0:29 Sedat Dilek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20101115184555.GA3484@viiv.ffwll.ch \
    --to=daniel@ffwll.ch \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=thomas@shipmail.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

dri-devel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/dri-devel/0 dri-devel/git/0.git
	git clone --mirror https://lore.kernel.org/dri-devel/1 dri-devel/git/1.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 dri-devel dri-devel/ https://lore.kernel.org/dri-devel \
		dri-devel@lists.freedesktop.org
	public-inbox-index dri-devel

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.freedesktop.lists.dri-devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git