Re: [PATCH v2 17/18] drm/i915: Wa32bitGeneralStateOffset & Wa32bitInstructionBaseOffset

From: Daniel Vetter <daniel@ffwll.ch>
To: Chris Wilson <chris@chris-wilson.co.uk>,
	Daniel Vetter <daniel@ffwll.ch>,
	Michel Thierry <michel.thierry@intel.com>,
	intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH v2 17/18] drm/i915: Wa32bitGeneralStateOffset & Wa32bitInstructionBaseOffset
Date: Thu, 18 Jun 2015 09:11:46 +0200	[thread overview]
Message-ID: <20150618071146.GK23637@phenom.ffwll.local> (raw)
In-Reply-To: <20150618070326.GS24012@nuc-i3427.alporthouse.com>

On Thu, Jun 18, 2015 at 08:03:26AM +0100, Chris Wilson wrote:
> On Thu, Jun 18, 2015 at 08:45:50AM +0200, Daniel Vetter wrote:
> > On Wed, Jun 17, 2015 at 06:37:03PM +0100, Chris Wilson wrote:
> > > On Wed, Jun 17, 2015 at 05:03:19PM +0200, Daniel Vetter wrote:
> > > > On Wed, Jun 17, 2015 at 01:53:17PM +0100, Chris Wilson wrote:
> > > > > On Wed, Jun 17, 2015 at 02:49:47PM +0200, Daniel Vetter wrote:
> > > > > > On Wed, Jun 10, 2015 at 07:09:03PM +0100, Chris Wilson wrote:
> > > > > > > On Wed, Jun 10, 2015 at 05:46:54PM +0100, Michel Thierry wrote:
> > > > > > > > There are some allocations that must be only referenced by 32bit
> > > > > > > > offsets. To limit the chances of having the first 4GB already full,
> > > > > > > > objects not requiring this workaround use DRM_MM_SEARCH_BELOW/
> > > > > > > > DRM_MM_CREATE_TOP flags
> > > > > > > > 
> > > > > > > > User must pass I915_EXEC_SUPPORTS_48BADDRESS flag to indicate it can
> > > > > > > > be allocated above the 32b address range.
> > > > > > > 
> > > > > > > This should be a per-object flag not per-execbuffer.
> > > > > > 
> > > > > > We need both. This one to opt into the large address space, the per-object
> > > > > > one to apply the w/a. Also libdrm/mesa patches for this are still missing.
> > > > > 
> > > > > Do we need the opt in on the context? The 48bit vm is lazily
> > > > > constructed, if no object asks to use the high range, it will never be
> > > > > populated. Or is there a cost with preparing a 48bit vm?
> > > > 
> > > > If we restrict to 4G we'll evict objects if we run out, and will stay
> > > > correct even when processing fairly large workloads. With just lazily
> > > > eating into 48b that won't be the case. A bit far-fetched, but if we go
> > > > to the trouble of implementing this might as well do it right.
> > > 
> > > i915_evict_something runs between the range requested for pinning. If we
> > > run out of 4G space and the desired pin does not opt into 48bit, we will
> > > evict from the lower 4G.
> > > 
> > > I obviously missed your concern. Care to elaborate?
> > 
> > Current situation: You always get an address below 4G for all objects,
> > even if you use more than 4G of textures - the evict code will make space.
> > 
> > New situation with 48b address space enabled but existing userspace and a
> > total BO set bigger than 4G: The kernel will eventually hand out ppgtt
> > addresses > 4G, which means if we get such an address potentially even for
> > an object where this wa needs to apply. This would be a regression. But if
> > we make 48b strictly opt-in the kernel will restrict _all_ objects to
> > below 4G, creating no regression.
> 
> How? The pin code requires PIN_48BIT to be set to hand out higher
> addresses. That is only set by execbuffer if execobject->flags is also set.

I've been dense, somehow I thought we need the execbuf opt-in with the
object opt-out. But opt-in at the object level is indeed all we need.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx