[Intel-gfx] uABI / Removing DRM_I915_LOW_LEVEL_TRACEPOINTS Kconfig

[Joonas Lahtinen]

Quoting Pierre-Loup A. Griffais (2018-12-18 20:14:49)
> 
> On 12/18/18 3:33 AM, Chris Wilson wrote:
> > Quoting Michael Sartain (2018-12-18 01:26:03)
> >> I'm writing to try and make a case for Tvrtko's "Remove
> >> DRM_I915_LOW_LEVEL_TRACEPOINTS Kconfig" patch:
> >>
> >>    https://lists.freedesktop.org/archives/intel-gfx/2018-June/169052.html
> > 
> > I'd recommend we just remove the tracepoints as in the very near future
> > we will break them and the outlook seems bleak that we can support the
> > same information in the future.
> 
> Is it due to moving to a more async (or HW-assisted) submission model? 
> If so, I assume/hope there's still a way to reflect on when things 
> completed after the fact? You could still emit tracepoints at the time 
> when that becomes known, with the time delta marked in the tracepoint 
> itself. gpuvis supports this, but the syntax it currently uses for it 
> isn't necessarily important. There's not much value in looking at these 
> tracepoints fly by in realtime, so being deferred a bit works well for 
> all scenarios where examining a GPU scheduling trace is useful.

When you combine HW-assisted scheduling with the Virtual Engine work we
have ongoing, there will basically be a situation where the KMD only
indicates to hardware which contexts are ready to execute, and it'll
just care when *some* requests finish that userspace is making wait
IOCTLs on.

So kernel's view will just be that it wrote a request to logical ring,
indicated that it's runnable (if it previously wasn't) and then it might
or might not want an interrupt on completion.

The motive is quite naturally to reduce the flow of unnecessary
information between the CPU and GPU during execution. And that
reduces a lot with HW-assisted scheduling. But it also reduces
the ability to introspect that information from kernel driver.

Wiring that information to flow back from the hardware is one task.
But forcing kernel to shape hardware events back to tracepoints seems
forceful considering current state of tracepoints.

There would have to be a triggered kernel activity reading the hardware
event ring and converting it to special tracepoints with the timestamp
as parameter information specifically for gpuvis to understand. Or you
could try to do that live but you would have to basically reintroduce the
communication between GPU and kernel driver we just used enormous
engineering efforts to get rid of :) Either way, triggered or live, the
usefulness with generic ftrace tooling would be reduced.

And all this would have to be stable, enabled-by-default in distros
with varying application versions (gpuvis), kernel versions and firmware
versions (HW-assisted scheduling) through the unversioned tracepoint
interface.

Having to jump through such hoops makes one think why does the GPU event
log have to come through tracepoints? It seem backwards to make kernel go
the extra mile, when userspace could just grab the data from an alternative
source in well-defined form and interleave the information when displaying.

For all that is worth, the thread to read the GPU events and turn them into
special tracepoints could be implemented in a userspace daemon, just
like you might import syslog from remote system.

To me, it seems almost as if folks are too preoccupied with thinking if
we somehow can do this through tracepoints, to stop and actually think
if we should.

Regards, Joonas

> 
> > -Chris
> > 
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx