[Intel-gfx] [PATCH 2/2] drm/i915/trace: Remove engine out of the context sandwich

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-05-25 09:30:29)
> 
> On 24/05/2018 17:00, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-05-24 16:48:45)
> >>
> >> On 24/05/2018 16:33, Chris Wilson wrote:
> >>> But what we call ctx here isn't really context, but timeline; how about
> >>> if we switch to the fence=%llx:%d representation we've mostly settled on
> >>> for the debug messages?
> >>
> >> For the ctx and seqno pair? But here we have the additional issue of
> >> hw_id. I think context is better than timeline at this level.
> >>
> >> Or you mean keep explicit hw_id and join ctx and seqno into fence=%llx:%d?
> > 
> > Right. I think what we call ctx here is very confusing, as it's just the
> > fence.context (i.e timeline id) and not any of the ids we assign to the
> > context (neither hw_id or uabi_id), so I don't think ctx refers to
> > i915_gem_context/intel_context at all and so would rather stop using
> > 'ctx'.
> 
> I couldn't make myself re-order ctx and engine, since I did not find the 
> solution for the resulting ctx and seqno split. And I did not like the 
> fence=%llu:%u for tracepoints. Just can't think of requests as fences.

But we are referring to the fence id of the request (rq->fence.context,
rq->fence.seqno), not its global seqno.

> Wrt hw_id and dev moving to u16, both fields theoretically can be wider 
> so I did not do that either.

dev cannot. We are limited to 16 DRM devices on the system, so minor is
always 0-15. Immaterial if we need padding between members in the
struct, we might as well use up the padding.
-Chris