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. > > -- > Chris Wilson, Intel Open Source Technology Centre -- Paulo Zanoni _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
