Re: [PATCH 7/7] lib: add igt_draw

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Apr 01, 2015 at 07:33:15PM -0300, Paulo Zanoni wrote:
> 2015-04-01 19:22 GMT-03:00 Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>:
> > On Wed, Apr 01, 2015 at 07:08:18PM -0300, Paulo Zanoni wrote:
> >> 2015-03-31 19:05 GMT-03:00 Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>:
> >> > the BLT code is an opencoded
> >> > intel_copy_bo
> >>
> >> No, we do BLT fills, not copies. On the render side I used rendercopy
> >> just because I still don't know how to do a "render fill".
> >
> > Ojjjjh, my mistake then. We certainly could do with an intel_bo_fill()
> > routine as we use XY_COLOR_BLT in quite a few places now.
> 
> I just added this to my TODO list. Some of the current XY_COLOR_BLT
> users will become users of igt_draw, so the duplication will be
> reduced a little bit. Later we can create intel_bo_fill and make
> igt_draw call it.
> 
> >
> >> > and what is with all the sync? Moving everything into the
> >> > GTT write domain (i.e. manually doing cache flushes) would seem to
> >> > nullify the point of using the GPU in the first place.
> >>
> >> The idea was to just be as simple as possible for the callers, but I
> >> can remove the gem_sync()s and leave it to the callers. There's also a
> >> little explanation on patch 2: I used this lib for some FBC tests, so
> >> the syncs would allow us to not wait so much for the retire work
> >> handler.
> >
> > Which retire work handler? Not the requests one surely?
> 
> i915_gem_retire_work_handler()
> 
> Now that we use the frontbuffer tracking mechanism, when we use the
> BLT, FBC gets disabled (by intel_fb_obj_invalidate(), called by
> i915_gem_execbuffer2()). But if we don't gem_sync(), FBC only gets
> reenabled after i915_gem_retire_work_handler() happens and calls
> intel_frontbuffer_flush(). While having FBC disabled for a long time
> is not a bug, the gem_sync() helps reducing the
> many-undreds-of-milliseconds waits.

Hmm. Bad news, that side-effect of gem_sync() won't happen in future.
You would need to call gem_sync() on the framebuffer to trigger the
flush, but that itself would then set the framebuffer to the GTT write
domain which should then invalidate the FBC again. To flush without
invalidate you want set_domain(scanout, read=GTT, write=0).
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx





[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux