All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Wilson <chris@chris-wilson.co.uk>
To: Ian Romanick <idr@freedesktop.org>
Cc: mesa-dev@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
	Kenneth Graunke <kenneth@whitecape.org>
Subject: Re: [PATCH] i965: Embrace "unlimited" GTT mmap support
Date: Thu, 25 Aug 2016 22:58:03 +0100	[thread overview]
Message-ID: <20160825215803.GA10693@nuc-i3427.alporthouse.com> (raw)
In-Reply-To: <8428b552-ad29-834f-2658-c6b3ec768a5e@freedesktop.org>

On Thu, Aug 25, 2016 at 01:43:53PM -0700, Ian Romanick wrote:
> On 08/24/2016 12:42 PM, Chris Wilson wrote:
> > +#define I915_PARAM_MMAP_GTT_VERSION 40 /* XXX delete me with new libdrm */
> > +   if (intel_get_integer(intelScreen, I915_PARAM_MMAP_GTT_VERSION) >= 1) {
> > +      /* Theorectically unlimited! */
> > +      intelScreen->max_gtt_map_object_size = UINT64_MAX;
> 
> Well... not quite unlimited, right?  Isn't the actual VMA space less
> than 64-bits?  I thought it was more like 48 bits.

The object which can be mapped is unconstrained by the GPU's address
space. We are only about 2MiB of the mappable aperture to map a portion
of the object at a time. The limits upon the object size are that we
have a global 64bit space to allocate GTT offsets from shared by all
objects across all clients. And of course the CPU only has a 40bit
address space, and far less physical memory.

Wrt the interface we can claim to be able to support any object up to
64bits in size. You can apply the same argument as for the mappable
aperture and halve/quarter it so that you can fit more than one huge
object at a time - but if you are planning to allocate lots of 60+bit
objects, we will run out of virtual offsets for them rapidly.

A safe value then would be 1<<64 / <typical number of objects>, so say
1<<48. By the time we can allocate more than one 1<<48 object, I
anticipate we will have moved onto 128bit address spaces.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

  reply	other threads:[~2016-08-25 21:58 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-24 19:42 [PATCH] drm/i915: Add I915_PARAM_MMAP_GTT_VERSION to advertise unlimited mmaps Chris Wilson
2016-08-24 19:42 ` [PATCH] i965: Embrace "unlimited" GTT mmap support Chris Wilson
2016-08-25  7:06   ` [Mesa-dev] " Daniel Vetter
2016-08-25  7:26   ` Kenneth Graunke
2016-08-25 20:43   ` Ian Romanick
2016-08-25 21:58     ` Chris Wilson [this message]
2016-08-25  7:02 ` [PATCH] drm/i915: Add I915_PARAM_MMAP_GTT_VERSION to advertise unlimited mmaps Daniel Vetter
2016-08-25  8:00 ` Joonas Lahtinen
2016-08-25  8:27   ` [Intel-gfx] " Chris Wilson
2016-08-25 12:15     ` Joonas Lahtinen
2016-08-25 18:05       ` [PATCH v2] " Chris Wilson

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=20160825215803.GA10693@nuc-i3427.alporthouse.com \
    --to=chris@chris-wilson.co.uk \
    --cc=idr@freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=kenneth@whitecape.org \
    --cc=mesa-dev@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.