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