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@xxxxxxxxx>
>>>>>
>>>>> 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@xxxxxxxxx>
>>>>> Suggested-by: Chris Wilson<chris@xxxxxxxxxxxxxxxxxx>
>>>>> Cc: Chris Wilson<chris@xxxxxxxxxxxxxxxxxx>
>>>>> Cc: John Harrison<John.C.Harrison@xxxxxxxxx>
>>>>> ---
>>>>> 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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
