[Intel-gfx] [PATCH] drm/i915: Consistent ordering of tracepoint binary data

Tvrtko Ursulin tvrtko.ursulin at linux.intel.com
Tue May 30 12:11:29 UTC 2017


On 11/05/2017 14:16, Tvrtko Ursulin wrote:
> 
> On 11/05/2017 14:07, Chris Wilson wrote:
>> On Thu, May 11, 2017 at 02:00:45PM +0100, Tvrtko Ursulin wrote:
>>> From: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
>>>
>>> For userspace receiving binary data it is easier if all related
>>> request tracepoints emit the binary data in the same order of
>>> dev, ring, ctx, seqno, ...
>>
>> We decided that dev, ctx, ring, seqno was the right heirachy last time.
>> After much debate :)
>> ctx is the logical view of the device for a user
>> ctx + ring = timeline
> 
> I couldn't remember so I thought it must have been what is documented in 
> TP_printk. Now I am confused. On one hand it's true, but on the other 
> ctx/seqno is also a pair as opposed to engine being stuck in the middle. 
> So ring-ctx-seqno is easier for humans I think. Even since per 
> ctx/engine seqno space.

[thread bump!]

Can we agree what to do here? Printk's are all engine-ctx-seqno which 
makes it sound like that was the order we agreed upon. But binary blobs 
are inconsistent as you have noticed - do we care enough to go and 
fiddle with that is the question? Is overlay the only userspace to your 
knowledge that accesses the binary blobs?

Regards,

Tvrtko



More information about the Intel-gfx mailing list