From: Thomas Hellstrom <thomas@shipmail.org>
To: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 0/9] make struct drm_mm_node embeddable
Date: Mon, 15 Nov 2010 08:58:13 +0100 [thread overview]
Message-ID: <4CE0E815.3000908@shipmail.org> (raw)
In-Reply-To: <1289583401-16605-1-git-send-email-daniel.vetter@ffwll.ch>
On 11/12/2010 06:36 PM, Daniel Vetter wrote:
> Hi all,
>
> This patch-set changes the algorithm in drm_mm.c to not need additional
> allocations to track free space and adds an api to make embedding struct
> drm_mm_node possible. Benefits:
>
> - If struct drm_mm_node is provided, no allocations need to be done anymore
> in drm_mm. It looks like some decent surgery, but ttm should be able to
> drop its preallocation dance.
> - void *priv is back, but done right ;)
> - Avoids a pointer chase when lru-scanning in i915 and saves a few bytes.
>
> As a proof of concept I've converted i915. Beware though, the drm/i915
> patches depend on my direct-gtt patches (which are actually the reason for
> this series here).
>
> Tested on my i855gm, i945gme, ironlake and agp rv570.
>
> Comments, flames, reviews highly welcome.
>
Hi, Daniel!
Nice work, although I have some comments about general applicability
that we perhaps need to think about.
1) The space representation and space allocation algorithm is something
that is private to the aperture management system. For a specialized
implementation like i915 that is all fine, but Ben has recently
abstracted that part out of the core TTM bo implementation. As an
example, vmwgfx is now using kernel idas to manage aperture space, and
drm_mm objects for traditional VRAM space. Hence, embedding drm_mm
objects into ttm bos will not really be worthwile. At least not for
aperture space management, and TTM will need to continue to "dance",
both in the ida case and in the drm_mm case. For device address space,
the situation is different, though, and it should be possible to embed
the drm_mm objects, but that brings up the next thing:
2) The algorithm used by drm_mm has been around for a while and has seen
a fair amount of changes, but nobody has yet attacked the algorithm used
to search for free space, which was just quickly put together as an
improvement on what was the old mesa range manager. In moderate
fragmentation situations, the performance will degrade, particularly
with "best match" searches. In the near future we'd probably want to add
something like a "hole rb tree" rather than a "hole list", and a choice
of algorithm for the user. With embeddable objects, unless you want to
waste space for unused members, you'd need a separate drm_mm node
subclass for each algorithm, whereas if you don't embed, you only need
to allocate what you need.
/Thomas
> Please consider merging the core drm parts (and the nouveau prep patch) for
> -next (the i915 patches need coordination with Chris Wilson, they're rather
> invasive).
>
> Thanks, Daniel
>
> Daniel Vetter (9):
> drm/nouveau: don't munge in drm_mm internals
> drm: mm: track free areas implicitly
> drm: mm: extract node insert helper functions
> drm: mm: add api for embedding struct drm_mm_node
> drm/i915: embed struct drm_mm_node into struct drm_i915_gem_object
> drm/i915: kill obj->gtt_offset
> drm/i915: kill gtt_list
> drm: mm: add helper to unwind scan state
> drm/i915: use drm_mm_for_each_scanned_node_reverse helper
>
> drivers/gpu/drm/drm_mm.c | 570 ++++++++++++++++-------------
> drivers/gpu/drm/i915/i915_debugfs.c | 22 +-
> drivers/gpu/drm/i915/i915_drv.h | 13 +-
> drivers/gpu/drm/i915/i915_gem.c | 173 ++++-----
> drivers/gpu/drm/i915/i915_gem_debug.c | 10 +-
> drivers/gpu/drm/i915/i915_gem_evict.c | 37 +-
> drivers/gpu/drm/i915/i915_gem_gtt.c | 14 +-
> drivers/gpu/drm/i915/i915_gem_tiling.c | 6 +-
> drivers/gpu/drm/i915/i915_irq.c | 34 +-
> drivers/gpu/drm/i915/intel_display.c | 26 +-
> drivers/gpu/drm/i915/intel_fb.c | 6 +-
> drivers/gpu/drm/i915/intel_overlay.c | 14 +-
> drivers/gpu/drm/i915/intel_ringbuffer.c | 10 +-
> drivers/gpu/drm/nouveau/nouveau_object.c | 2 +-
> drivers/gpu/drm/nouveau/nv50_instmem.c | 2 +-
> include/drm/drm_mm.h | 49 ++-
> 16 files changed, 525 insertions(+), 463 deletions(-)
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
next prev parent reply other threads:[~2010-11-15 7:58 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-12 17:36 [PATCH 0/9] make struct drm_mm_node embeddable Daniel Vetter
2010-11-12 17:36 ` [PATCH 1/9] drm/nouveau: don't munge in drm_mm internals Daniel Vetter
2010-11-12 17:36 ` [PATCH 2/9] drm: mm: track free areas implicitly Daniel Vetter
2010-11-12 17:36 ` [PATCH 3/9] drm: mm: extract node insert helper functions Daniel Vetter
2010-11-12 17:36 ` [PATCH 4/9] drm: mm: add api for embedding struct drm_mm_node Daniel Vetter
2010-11-12 17:36 ` [PATCH 5/9] drm/i915: embed struct drm_mm_node into struct drm_i915_gem_object Daniel Vetter
2010-11-12 17:36 ` [PATCH 6/9] drm/i915: kill obj->gtt_offset Daniel Vetter
2010-11-12 17:36 ` [PATCH 7/9] drm/i915: kill gtt_list Daniel Vetter
2010-11-12 17:36 ` [PATCH 8/9] drm: mm: add helper to unwind scan state Daniel Vetter
2010-11-12 17:36 ` [PATCH 9/9] drm/i915: use drm_mm_for_each_scanned_node_reverse helper Daniel Vetter
2010-11-12 17:56 ` [PATCH 0/9] make struct drm_mm_node embeddable Chris Wilson
2010-11-15 7:58 ` Thomas Hellstrom [this message]
2010-11-15 19:45 ` Daniel Vetter
2010-11-15 20:40 ` Thomas Hellstrom
2010-11-15 20:54 ` Daniel Vetter
2010-11-14 14:03 Sedat Dilek
2010-11-14 14:38 ` Chris Wilson
2010-11-14 15:52 ` Sedat Dilek
2010-11-14 16:13 ` Daniel Vetter
2010-11-14 16:56 ` Sedat Dilek
2010-11-14 17:14 ` Daniel Vetter
2010-11-14 17:27 ` Sedat Dilek
2010-11-14 17:52 ` Sedat Dilek
2010-11-14 18:14 ` Daniel Vetter
2010-11-14 18:19 ` Sedat Dilek
2010-11-14 18:31 ` Sedat Dilek
2010-11-14 18:54 ` Daniel Vetter
2010-11-14 19:55 ` Sedat Dilek
2010-11-15 10:31 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=4CE0E815.3000908@shipmail.org \
--to=thomas@shipmail.org \
--cc=daniel.vetter@ffwll.ch \
--cc=dri-devel@lists.freedesktop.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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).