Re: [PATCH igt] igt: Add gem_ctx_freq to exercise requesting freq on a ctx

[Antonio Argenziano <antonio.argenziano@intel.com>]

On 08/03/18 17:03, Chris Wilson wrote:
> Quoting Antonio Argenziano (2018-03-09 00:45:42)
>>
>>
>> On 08/03/18 09:13, Chris Wilson wrote:
>>> Exercise some new API that allows applications to request that
>>> individual contexts are executed within a desired frequency range.
>>>
>>> v2: Split single/continuous set_freq subtests
>>>
>>> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
>>> Cc: Paneri, Praveen <praveen.paneri@intel.com>
>>> Cc: Kamble, Sagar A <sagar.a.kamble@intel.com>
>>> Cc: Antonio Argenziano <antonio.argenziano@intel.com>
>>> ---
>>>    tests/Makefile.am      |   1 +
>>>    tests/Makefile.sources |   1 +
>>>    tests/gem_ctx_freq.c   | 604 +++++++++++++++++++++++++++++++++++++++++++++++++
>>>    tests/meson.build      |   1 +
>>>    4 files changed, 607 insertions(+)
>>>    create mode 100644 tests/gem_ctx_freq.c
>>>
>>

>>> +             uint32_t cur, discard;
>>> +
>>> +             set_freq(fd, ctx, freq, freq);
>>> +             get_freq(fd, ctx, &cur, &discard);
>>
>> igt_assert_eq(freq, cur)?
> 
> Not quite. The trick is that the interface is not strictly idempotent,
> since we pass in MHz, the driver converts that into freq bins and spits
> it back out to the nearest MHz. So cur is not strictly freq, it just
> happens that 50MHz is the bin size on gen9.
> 
> The idea here is that we grab the adjusted freq from the driver to
> validate with.

I see, can we enforce a tolerance? It feels like we are trusting the 
kernel too much, but if that is the only thing we can do...

>>> +static void smoketest(int fd, int timeout)
>>> +{
>>> +     unsigned int engines[16];
>>
>> use a macro instead of magic number 16.
> 
> #define THIS_IS_FAR_MORE_MAGIC_THAN_A_MEANINGLESS_BARE_NUMBER_THAT_YOU_SHOULD_NOT_BE_READING_ANYTHING_INTO 16
> /rant

We call that MAX_EGINES in gem_exec_schedule ;).

Thanks,
Antonio

> 
>>> +static void invalid_param(int fd)
>>> +{
>>
>> gem_ctx_param is going to be upset again pretty soon ;).
> 
> Poor thing.
> -Chris
> 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx