On Wed, Aug 26, 2015 at 03:06:59PM +0200, Daniel Vetter wrote: > On Wed, Aug 26, 2015 at 12:55:57PM +0100, Chris Wilson wrote: > > As we mark the preallocated objects as bound, we should also flag them > > correctly as being map-and-fenceable (if appropriate!) so that latter > > users do not get confused and try and rebind the pinned vma in order to > > get a map-and-fenceable binding. > > > > Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> > > Cc: "Goel, Akash" <akash.g...@intel.com> > > Cc: Daniel Vetter <daniel.vet...@ffwll.ch> > > Cc: Jesse Barnes <jbar...@virtuousgeek.org> > > Cc: sta...@vger.kernel.org > > Reviewed-by: Daniel Vetter <daniel.vet...@ffwll.ch> > > Jani, can you please pick up both? And some bugzilla references for either > would be great too - Chris?
There's a few candidate "overwrite of address 0" bugs, but no way to really tell if that is the fbcon or userspace without trial and error. > Oh and does patch 1 fix the execlist resume troubles? Execlist having > bigger contexts might be enough explanations for the apparent regression. Hmm, plausible. > And can we igt patch 1 somehow? E.g. with memory pressure plus doing an > mmap on the legacy fbdev ... Look at i915_gem_framebuffer for the fbcon gtt address before/after aperture thrashing. Would also need to switch to a user framebuffer to drop the scanout pinning. Or just assert that it is still pinned following a modeset away from fbcon. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx