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.
Wrt hw_id and dev moving to u16, both fields theoretically can be wider
so I did not do that either.
What's left is class:instance, group two context id's together, and
expand ctx to u64.
Hopefully not controversial at this time, or as a first step, or something.
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
