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@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
