[Intel-gfx] [PATCH v2 17/18] drm/i915: Wa32bitGeneralStateOffset & Wa32bitInstructionBaseOffset

[Chris Wilson]

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.
 
> 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.

I don't see why we need another flag beyond the per-object flag. If you
are thinking validation, we have to validate per-object flags anyway.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre