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? -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
