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 08:45:50 +0200	[thread overview]
Message-ID: <20150618064549.GG23637@phenom.ffwll.local> (raw)
In-Reply-To: <20150617173703.GO24012@nuc-i3427.alporthouse.com>

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.

Ofc new userspace on 48b would set both the execbuf opt-in (or context
flag, we have those now) plus the per-obj "I need this below 4G" flag for
the objects that need this wa.
-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