Re: [igt-dev] [Intel-gfx] [PATCH i-g-t] benchmarks/wsim: Simulate and interpret .wsim

[Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>]

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
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev