On 03/08/2016 16:36, Dave Gordon wrote:
The parallel execution test in gem_exec_nop chooses a pessimal
distribution of work to multiple engines; specifically, it
round-robins one batch to each engine in turn. As the workloads
are trivial (NOPs), this results in each engine becoming idle
between
On 18/08/16 16:27, Dave Gordon wrote:
On 18/08/16 13:01, John Harrison wrote:
[snip]
Can you post the numbers that you get?
I seem to get massive variability on my BDW. The render ring always
gives me around 2.9us/batch but the other rings sometimes give me region
of 1.2us and sometimes
On 18/08/16 16:36, Dave Gordon wrote:
On 18/08/16 16:27, Dave Gordon wrote:
[snip]
Note that SKL GuC firmware 6.1 didn't support dual submission or lite
restore, whereas the next version (8.11) does. Therefore, with that
firmware we don't see the same slowdown when going to 1-at-a-time
On 18/08/16 16:27, Dave Gordon wrote:
[snip]
Note that SKL GuC firmware 6.1 didn't support dual submission or lite
restore, whereas the next version (8.11) does. Therefore, with that
firmware we don't see the same slowdown when going to 1-at-a-time
round-robin. I have a different (new) test
On 18/08/16 13:01, John Harrison wrote:
On 03/08/2016 17:05, Dave Gordon wrote:
On 03/08/16 16:45, Chris Wilson wrote:
On Wed, Aug 03, 2016 at 04:36:46PM +0100, Dave Gordon wrote:
The parallel execution test in gem_exec_nop chooses a pessimal
distribution of work to multiple engines;
On 03/08/2016 17:05, Dave Gordon wrote:
On 03/08/16 16:45, Chris Wilson wrote:
On Wed, Aug 03, 2016 at 04:36:46PM +0100, Dave Gordon wrote:
The parallel execution test in gem_exec_nop chooses a pessimal
distribution of work to multiple engines; specifically, it
round-robins one batch to each
On Wed, Aug 03, 2016 at 04:36:46PM +0100, Dave Gordon wrote:
> The parallel execution test in gem_exec_nop chooses a pessimal
> distribution of work to multiple engines; specifically, it
> round-robins one batch to each engine in turn. As the workloads
> are trivial (NOPs), this results in each
