On 16/08/18 08:31, Tvrtko Ursulin wrote:
On 15/08/2018 12:58, Tvrtko Ursulin wrote:
On 14/08/2018 15:59, Lionel Landwerlin wrote:
Hey Tvrtko,
Thanks for taking over this series.
I've been talking to developers using the i915/perf interface and
from their point of view, they expect the system to be in a stable
configuration when doing measurements.
One issue with this patch on Gen11 is that it will lock the system
in a configuration that isn't workable for media workloads (all
subslices enabled).
So I think we should set the value for the locked configuration per
generation (gen8-10: all slices/subslices, gen11: only subslices
that contain VME samplers) so that we always get a functional
configurations for all workloads.
Could we want to select that configuration when opening perf?
This would be via i915_perf.c/gen8_configure_all_contexts?
Sounds like an unfortunate but workable compromise. As long as there
doesn't appear another asymmetric slice feature in the future, which
doesn't align with VME. Like one workloads wants slices 0 & 2,
another wants 1 & 3, or whatever. If that happens then I don't know
what we do apart from locking out perf/OA.
Another question is how do we expose the selected value to the user.
But that can be solved in a different series.
SSEU get_param would cut it? Although it would be perhaps be
unexpected to get different results depending on whether perf/OA is
active or not.. Hm... export device and available bitmasks via get
param? Device bitmask would be fixed and available would change
depending on whether perf/OA is active or not.
I would avoid changing the get_param. This is supposed to report the
physical device's properties.
Maybe add an ioctl entry to report that configuration onto the i915_perf fd?
Big downside to this is that observing something via OA would cause
slow down of the whole system - since the SSEU config would be locked
to a subset of slices on Gen11. :( Regardless or not of the details..
say even if we choose to lock only if there is one non-default SSEU
context, that still locks all whilst perf/OA is active.
That's quite bad I think. But the alternative is to lock out perf/OA
while non-default SSEU contexts are present. Which is also very bad. :(
Overall I don't see a solution. Latter is maybe better by being more
explicit? Who are the perf/OA users and what would they prefer?
The other solution I could think of would be to prevent schedule
contexts that are not compatible with the OA configuration.
That doesn't sound great either...
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
