[Intel-gfx] [PATCH 7/7] lib: add igt_draw

[Paulo Zanoni]

2015-04-01 19:22 GMT-03:00 Chris Wilson <chris at chris-wilson.co.uk>:
> On Wed, Apr 01, 2015 at 07:08:18PM -0300, Paulo Zanoni wrote:
>> 2015-03-31 19:05 GMT-03:00 Chris Wilson <chris at chris-wilson.co.uk>:
>> > 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