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

Paulo Zanoni przanoni at gmail.com
Wed Apr 1 15:08:18 PDT 2015


2015-03-31 19:05 GMT-03:00 Chris Wilson <chris at chris-wilson.co.uk>:
> On Tue, Mar 31, 2015 at 06:52:08PM -0300, Paulo Zanoni wrote:
>> From: Paulo Zanoni <paulo.r.zanoni at intel.com>
>>
>> For all those IGT tests that need an easy way to draw rectangles on
>> buffers using different methods. Current planned users: FBC and PSR
>> CRC tests.
>>
>> There is also a tests/kms_draw_crc program to check if the library is
>> sane.
>>
>> v2: - Move the test from lib/tests to tests/ (Daniel).
>>     - Add igt_require() to filter out the swizzling/tiling methods we
>>       don't support (Daniel).
>>     - Simplify reloc handling on the BLT case (Daniel).
>>     - Document enum igt_draw_method (Daniel).
>>     - Document igt_draw_get_method_name() (Paulo).
>
> You are already missing one draw path (mmap wc),

Oh, new stuff! Done.

> adding the extra swizzle
> modes for anything but bit17 is trivial,

Done.

> 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".

> 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. But Daniel/Ville had also suggested a test without the sync,
so I guess I would have removed the sync from the library anyway when
implementing the test.

Thanks for the review!

> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre



-- 
Paulo Zanoni


More information about the Intel-gfx mailing list