On 11/05/2018 10:33, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-05-11 10:21:05)
On 11/05/2018 10:04, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-05-11 09:31:52)
On 11/05/2018 08:11, Chris Wilson wrote:
A little tool I've been meaning to write for a while... Convert the
.wsim into their dag and find the longest chains and evaluate them on an
simulated machine.
Very cool!
But I think you need to handle the 's' command which appears in the
interesting workloads. Maybe you could just fake it as a zero duration
batch with a data dependency.
Barriers were even more trivial than that. :)
Fence related commands would also be useful but more difficult I guess.
As would throttling.
I haven't groked your fence command lines so skipped them. Fortunately,
syncs appears to be the only one missed from the "interesting" set of
wsim.
Fences are created with 'f' and then batches can reference them from the
dependency list the same as with data dependencies. When created they
are unsignaled and then 'a' advances the fence addresses relatively to
the 'a' command. For instance 'a.-2' means "signal ready the fence
created two steps above".
I really wish you did named fences :)
Should be possible to add/replace but would need another data structure
to look them up then.
How is 'a' synchronised? If I just did the 'f' as a dependency then
signaled it sometime later, it adds no delay to pipeline.
media_nn_1080p_s1.wsim:
f
1.VCS1.6500-8000.f-1.0
1.VCS2.6500-8000.f-2.0
a.-3
2.RCS.2000-4000.-2/-3.0
3.RCS.3000-5000.-1.0
3.RCS.23000-27000.0.0
3.VCS.16000-20000.-1.1
From the point of view of scheduling f,a become a no-op.
media_nn_1080p_s2.wsim:
1.VCS.13000-17000.0.0
2.RCS.2000-4000.-1.0
3.RCS.3000-5000.-1.0
3.RCS.23000-27000.0.0
f
3.VCS1.8000-10000.-2/f-1.0
3.VCS2.8000-10000.-3/f-2.0
a.-3
s.-3
s.-3
Same here. "f" appears ungrounded.
Okay in these examples I guess it doesn't do much for a single client.
In multiple client cases it can have an effect. Or if there was
something in between the batches with input fence dependencies.
Delays could maybe be faked as batches as well by adding input
dependency to everything preceding it.
It would definitely want to be a task with say .engine = -1. It implies
a full barrier as well? Not limited to waiting for an earlier step?
There is 'd' which is a normal/dumb fixed delay, and then 'p' which is
relative to start of the loop, meaning "wait how much is needed so that
time from start of loop to this step is x".
There aren't any '^[dp]' in the current set of .wsim, can I just
pretend they don't exist for now? ;)
Probably. There is -a option to gem_wsim which media-bench uses in some
modes essentially to convert any workload into realtime. For instance -a
p.16667 (AFAIR) makes any workload not run faster than 60fps. But your
sim_wsim I guess you don't care about that.
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
