[Intel-gfx] [igt-dev] [PATCH i-g-t v2 1/9] trace.pl: Improve time axis labels
John Harrison
John.C.Harrison at Intel.com
Tue Jul 17 17:57:19 UTC 2018
On 7/17/2018 9:22 AM, Tvrtko Ursulin wrote:
> On 17/07/18 16:31, John Harrison wrote:
>> On 7/17/2018 8:11 AM, John Harrison wrote:
>>> On 7/17/2018 1:56 AM, Tvrtko Ursulin wrote:
>>>> On 16/07/2018 18:53, John Harrison wrote:
>>>>> On 7/13/2018 2:55 AM, Tvrtko Ursulin wrote:
>>>>>> From: Tvrtko Ursulin<tvrtko.ursulin at intel.com>
>>>>>>
>>>>>> It is possible to customize the axis display so change it to display
>>>>>> timestamps in seconds on the major axis (with six decimal spaces) and
>>>>>> millisecond offsets on the minor axis.
>>>>>>
>>>>>> v2:
>>>>>> * Give up on broken relative timestamps.
>>>>>>
>>>>>> Signed-off-by: Tvrtko Ursulin<tvrtko.ursulin at intel.com>
>>>>>> Suggested-by: Chris Wilson<chris at chris-wilson.co.uk>
>>>>>> Cc: Chris Wilson<chris at chris-wilson.co.uk>
>>>>>> Cc: John Harrison<John.C.Harrison at Intel.com>
>>>>>> ---
>>>>>> scripts/trace.pl | 37 +++++++++++++++++++++++++++++++++++++
>>>>>> 1 file changed, 37 insertions(+)
>>>>>>
>>>>>> diff --git a/scripts/trace.pl b/scripts/trace.pl
>>>>>> index fc1713e4f9a7..41f10749a153 100755
>>>>>> --- a/scripts/trace.pl
>>>>>> +++ b/scripts/trace.pl
>>>>>> @@ -1000,6 +1000,42 @@ $first_ts = ts($first_ts);
>>>>>> print <<ENDHTML;
>>>>>> ]);
>>>>>> + function majorAxis(date, scale, step) {
>>>>>> + var s = date / 1000;
>>>>>> + var precision;
>>>>>> +
>>>>>> + if (scale == 'millisecond')
>>>>>> + precision = 6;
>>>>>> + else if (scale == 'second')
>>>>>> + precision = 3;
>>>>>> + else
>>>>>> + precision = 0;
>>>>>> +
>>>>>> + return s.toFixed(precision) + "s";
>>>>>> + }
>>>>>> +
>>>>>> + function minorAxis(date, scale, step) {
>>>>>> + var ms = date;
>>>>>> + var precision;
>>>>>> + var unit;
>>>>>> +
>>>>>> + if (scale == 'millisecond') {
>>>>>> + ms %= 1000;
>>>>>> + precision = 0;
>>>>>> + unit = 'ms';
>>>>>> + } else if (scale == 'second') {
>>>>>> + ms /= 1000;
>>>>>> + precision = 1;
>>>>>> + unit = 's';
>>>>>> + } else {
>>>>>> + ms /= 1000;
>>>>>> + precision = 0;
>>>>>> + unit = 's';
>>>>>> + }
>>>>>> +
>>>>>> + return ms.toFixed(precision) + unit;
>>>>>> + }
>>>>>> +
>>>>>> // Configuration for the Timeline
>>>>>> var options = { groupOrder: 'content',
>>>>>> horizontalScroll: true,
>>>>>> @@ -1007,6 +1043,7 @@ print <<ENDHTML;
>>>>>> stackSubgroups: false,
>>>>>> zoomKey: 'ctrlKey',
>>>>>> orientation: 'top',
>>>>>> + format: { majorLabels: majorAxis, minorLabels: minorAxis },
>>>>>> start: '$first_ts',
>>>>>> end: '$end_ts'};
>>>>> I'm still seeing some kind of strange offset. However, it appears to
>>>>> be browser dependent. If I use Chrome then the offset is +28.8
>>>>> seconds. With Firefox it is -59958115.2 seconds! On the other hand,
>>>>> if I try Edge or IE then I don't get a graph at all. I'm wondering
>>>>> if the issue is with Vis browser compatibility rather than anything
>>>>> in the trace.pl script. Are you seeing anything at all similar?
>>>>>
>>>>> Hmm, if I comment out the 'format:' line and go back to the
>>>>> unformatted time stamps then IE & Edge still show nothing. However,
>>>>> Firefox shows dates based on a year of 0097 whereas Chrome says 1997.
>>>>>
>>>>> Either way, I can't spot anything in this patch that could cause a
>>>>> random offset. So...
>>>> Yeah, I can see that now that I tried in Firefox. I was using
>>>> Chromium so far and there timestamps are exactly matching the ones
>>>> from the tracepoint log. Which is what we want for easy correlation
>>>> between the log and HTML..
>>>>
>>>> Firefox corrupts that somehow by applying the large negative offset
>>>> to everyhting. Perhaps around two year worth of negative seconds if
>>>> my rough calculation can be trusted. Or Vis under Firefox, I wouldn't
>>>> know really who is to blame.
>>>>
>>>> I have no idea what to do here. :(
>>>>
>>>> Regards,
>>>>
>>>> Tvrtko
>>> I think ship it for now. It is better than it was. Certainly reporting
>>> in date format is vaguely meaningless at best and totally meaningless
>>> with the x1000 scale factor.
>>>
>>> Note that chromium on Ubuntu 16.04 does the same as Chrome on Windows
>>> for me - 28.8 seconds offset. It's not as bad as the 1.9 years of
>>> Firefox but it is still out :(. I'm guessing it is a bug in the date
>>> -> absolute seconds conversion going on within either Javascript
>>> itself or Vis in particular. The timestamps are still encoded as dates
>>> in the HTML file (and referenced from 0 not from 1900 or 1970 or
>>> whatever). So any difference in calculating leap years between the
>>> Perl script and the browser would potentially cause quite a
>>> significant delta.
>>>
>>> Is it at all possible to put absolute seconds style values in the HTML
>>> file instead of dates? That would seem like the obvious answer. I
>>> don't know if Vis would cope with that, though?
>>>
>>> John.
>>>
>> Hmm. It looks like if I change the 'ts()' function to use 'localtime()'
>> instead of 'gmtime()' and to add on 1900 to the year then it all works
>> fine for me :). So yes, I think it is some incompatibility between the
>> Perl and Javascript implementations of date <-> absolute seconds
>> conversions. Given that the timestamp is no longer being reported as an
>> actual date anymore, the relative value doesn't really matter. So I
>> would go with using whatever scheme produces the least mutation along
>> the way!
>>
>> I wonder if you see the correct values on Chrome because your logs have
>> smaller timestamps? The ones I am currently testing with are of the
>> order of 856985.688681. With the above tweaks, that comes out as a date
>> of '1997-02-26 11:34:48.681000'. The 'gmtime' version was '1997-02-26
>> 19:34:48.681000' and obviously the non-1900 version was '0097-02-26
>> 19:34:48.681000'. Actually, maybe the Chrome difference is because you
>> are in the UK and don't have a timezone delta? Although I would assume
>> you are on BST not GMT right now?
> Can you try leaving gmtime in ts() and adding this diff:
>
> diff --git a/scripts/trace.pl b/scripts/trace.pl
> index 88abc2ee5ebf..2e43b68e3163 100755
> --- a/scripts/trace.pl
> +++ b/scripts/trace.pl
> @@ -1338,6 +1338,10 @@ print <<ENDHTML;
> zoomKey: 'ctrlKey',
> orientation: 'top',
> format: { majorLabels: majorAxis, minorLabels: minorAxis },
> + moment: function(date) {
> + return vis.moment(date).utc();
> + },
> +
> start: '$first_ts',
> end: '$end_ts'};
>
> Could be the gotcha we were missing!
>
> Regards,
>
> Tvrtko
Doesn't seem to make a difference for me :(. The +1900 gets rid of the
massive negative offset in Firefox but only the localtime() fixes the
28.8s offset in both Firefox and Chrome.
More information about the Intel-gfx
mailing list