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