From: Dave Gordon <david.s.gordon@intel.com>
To: John Harrison <John.C.Harrison@Intel.com>,
intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 1/2] igt/gem_exec_nop: add burst submission to parallel execution test
Date: Thu, 18 Aug 2016 16:36:11 +0100 [thread overview]
Message-ID: <16660ccd-089f-b606-bf55-5539e7bfcbb2@intel.com> (raw)
In-Reply-To: <4d49e32f-21eb-ff72-1bbc-5787f89f54ae@intel.com>
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 that shows this more clearly.
This is with GuC version 6.1:
skylake# ./intel-gpu-tools/tests/gem_exec_paranop | fgrep -v SUCCESS
Time to exec 8-byte batch: 3.428µs (ring=render)
Time to exec 8-byte batch: 2.444µs (ring=bsd)
Time to exec 8-byte batch: 2.394µs (ring=blt)
Time to exec 8-byte batch: 2.615µs (ring=vebox)
Time to exec 8-byte batch: 2.625µs (ring=all, sequential)
Time to exec 8-byte batch: 12.701µs (ring=all, parallel/1) ***
Time to exec 8-byte batch: 7.259µs (ring=all, parallel/2)
Time to exec 8-byte batch: 4.336µs (ring=all, parallel/4)
Time to exec 8-byte batch: 2.937µs (ring=all, parallel/8)
Time to exec 8-byte batch: 2.661µs (ring=all, parallel/16)
Time to exec 8-byte batch: 2.245µs (ring=all, parallel/32)
Time to exec 8-byte batch: 1.626µs (ring=all, parallel/64)
Time to exec 8-byte batch: 2.170µs (ring=all, parallel/128)
Time to exec 8-byte batch: 1.804µs (ring=all, parallel/256)
Time to exec 8-byte batch: 2.602µs (ring=all, parallel/512)
Time to exec 8-byte batch: 2.602µs (ring=all, parallel/1024)
Time to exec 8-byte batch: 2.607µs (ring=all, parallel/2048)
Time to exec 4Kbyte batch: 14.835µs (ring=render)
Time to exec 4Kbyte batch: 11.787µs (ring=bsd)
Time to exec 4Kbyte batch: 11.533µs (ring=blt)
Time to exec 4Kbyte batch: 11.991µs (ring=vebox)
Time to exec 4Kbyte batch: 12.444µs (ring=all, sequential)
Time to exec 4Kbyte batch: 16.211µs (ring=all, parallel/1)
Time to exec 4Kbyte batch: 13.943µs (ring=all, parallel/2)
Time to exec 4Kbyte batch: 13.878µs (ring=all, parallel/4)
Time to exec 4Kbyte batch: 13.841µs (ring=all, parallel/8)
Time to exec 4Kbyte batch: 14.188µs (ring=all, parallel/16)
Time to exec 4Kbyte batch: 13.747µs (ring=all, parallel/32)
Time to exec 4Kbyte batch: 13.734µs (ring=all, parallel/64)
Time to exec 4Kbyte batch: 13.727µs (ring=all, parallel/128)
Time to exec 4Kbyte batch: 13.947µs (ring=all, parallel/256)
Time to exec 4Kbyte batch: 12.230µs (ring=all, parallel/512)
Time to exec 4Kbyte batch: 12.147µs (ring=all, parallel/1024)
Time to exec 4Kbyte batch: 12.617µs (ring=all, parallel/2048)
What this shows is that the submission overhead is ~3us which is
comparable with the execution time of a trivial (8-byte) batch, but
insignificant compared with the time to execute the 4Kbyte batch. The
burst size therefore makes very little difference to the larger batches.
.Dave.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2016-08-18 15:36 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-03 15:36 [PATCH 0/2] Updates to gem_exec_nop parallel execution test Dave Gordon
2016-08-03 15:36 ` [PATCH 1/2] igt/gem_exec_nop: add burst submission to " Dave Gordon
2016-08-03 15:45 ` Chris Wilson
2016-08-03 16:05 ` Dave Gordon
2016-08-18 12:01 ` John Harrison
2016-08-18 15:27 ` Dave Gordon
2016-08-18 15:36 ` Dave Gordon [this message]
2016-08-18 15:54 ` Dave Gordon
2016-08-18 15:59 ` Dave Gordon
2016-08-22 14:28 ` John Harrison
2016-08-03 15:36 ` [PATCH 2/2] igt/gem_exec_nop: clarify & extend output from " Dave Gordon
2016-08-22 14:39 ` John Harrison
2016-08-22 14:42 ` John Harrison
2016-08-03 16:07 ` ✗ Ro.CI.BAT: failure for Updates to gem_exec_nop " Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=16660ccd-089f-b606-bf55-5539e7bfcbb2@intel.com \
--to=david.s.gordon@intel.com \
--cc=John.C.Harrison@Intel.com \
--cc=intel-gfx@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.