[Intel-gfx] [PATCH igt] igt: Add gem_ctx_freq to exercise requesting freq on a ctx
antonio.argenziano at intel.com
Fri Mar 9 19:15:45 UTC 2018
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 at chris-wilson.co.uk>
>>> Cc: Paneri, Praveen <praveen.paneri at intel.com>
>>> Cc: Kamble, Sagar A <sagar.a.kamble at intel.com>
>>> Cc: Antonio Argenziano <antonio.argenziano at 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;
>> 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
We call that MAX_EGINES in gem_exec_schedule ;).
>>> +static void invalid_param(int fd)
>> gem_ctx_param is going to be upset again pretty soon ;).
> Poor thing.
More information about the Intel-gfx