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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
