On Mon, Nov 02, 2015 at 02:53:00PM +0100, Maarten Lankhorst wrote: > Op 02-11-15 om 14:46 schreef Chris Wilson: > > On Mon, Nov 02, 2015 at 02:13:48PM +0100, Maarten Lankhorst wrote: > >> Op 29-10-15 om 01:30 schreef Matt Roper: > >>> On Wed, Sep 23, 2015 at 01:27:12PM +0200, Maarten Lankhorst wrote: > >>>> diff --git a/drivers/gpu/drm/i915/intel_overlay.c b/drivers/gpu/drm/i915/intel_overlay.c > >>>> index 444542696a2c..1b18cc6bdbd6 100644 > >>>> --- a/drivers/gpu/drm/i915/intel_overlay.c > >>>> +++ b/drivers/gpu/drm/i915/intel_overlay.c > >>>> @@ -749,7 +749,11 @@ static int intel_overlay_do_put_image(struct intel_overlay *overlay, > >>>> if (ret != 0) > >>>> return ret; > >>>> > >>>> - ret = i915_gem_object_pin_to_display_plane(new_bo, 0, NULL, NULL, > >>>> + ret = i915_gem_object_wait_rendering(new_bo, true); > >>> Again, I'm not super familiar with GEM internals...can this be a > >>> behavior change from the previous code? Originally the pin_to_display > >>> plane function would have passed (obj->base.pending_write_domain == 0) > >>> as the second parameter here (readonly), but you're unconditionally > >>> passing true. Can there not be pending writes against this object? > >> I don't think it would be important in the case of overlays. But maybe I should > >> just replace it with a call to i915_gem_object_sync and wait for full object idle. > > Technically it removes a call to set-cache, acquiring a GGTT offset and > > pinning it, and a final set-to-gtt. > > > > Quite a major and broken change. > > -Chris > > > No? pin_to_display_plane is called immediately below in this patch, it's just not shown here in the comments because it was about using wait_rendering. Bah. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
