[Intel-gfx] [PATCH igt] igt: Add gem_ctx_freq to exercise requesting freq on a ctx
Chris Wilson
chris at chris-wilson.co.uk
Fri Mar 9 20:37:17 UTC 2018
Quoting Antonio Argenziano (2018-03-09 19:15:45)
>
>
> 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...
for (i = min; i <= max; i++)
igt_assert(min <= set_and_fetch_freq(i) <= max);
I don't think we want to constrain the ABI any more than that.
But adding that level of check seems ok.
The behaviour is we ask the kernel for a range, the kernel tells us what
range it can provide based on the request. Then we expect that the
kernel upholds that contract. (Except where we make a conflicting
contract with another party, either parallel execution or sysadmin
override.)
Binding ourselves into a tighter contract feels overly prescriptive and
not flexible enough to weasel our way out of bad situations in future.
-Chris
More information about the Intel-gfx
mailing list