[PATCH 00/23] drm/etnaviv: support performance counters

[Lucas Stach]

Am Dienstag, den 12.09.2017, 17:11 +0200 schrieb Christian Gmeiner:
> In a perfect world we would be able to read GPU registers of interest
> via the command stream with a 'read-register' command/package. For perf
> counters it is a must to read them synchronized with the GPU to put the
> values in relation to a draw command. As Vivante GPUs do not provide this
> functionality we need to emulate it in software.
> 
> 
> We need to support three different kind of perf register types:
> 
> 1) normal register
>   This is the easierst case where we can simply read the register and we
>   are done.
> 
> 2) debug register
>   We need to configure the mux register and then read the debug register value.
> 
> 3) pipeline register
>   We need to 'iterate' over all pixel pipes and sum up the values. The 'iteration'
>   is done by select the pipe of interest via HI_CLOCK_CONTROL_DEBUG_PIXEL_PIPE.
>   There is also need to configure the mux register.
> 
> 
> Allowing the userspace to do it all by its own feels quite error prone and not
> future-proof. Thats why the kernel exports all performance domains and their
> signals to the userspace via two new ioctls. So the kernel knows all performance
> counters and how to sample them.
> 
> At the moment all performacne domains and signals get exported to all gpu pipe types,
> but that can be changed in follow-up patches.

Okay, after testing the V4 patches I'm convinced that we need this
filter _before_ any of this can go in.

At least on GC3000 profiling the PE counters wastes the GPU bad enough
that not even our regular GPU recovery mechanism is able to get it back
to life. This is a trivial DOS vector, which we simply can't allow in
the kernel driver. For this to go in, we need some way to only export
the counters, which are _tested_ to be safe on the hardware.

Regards,
Lucas