| Age | Commit message (Collapse) | Author |
|---|
|
Just a set of scripts to integrate these benchmarks with ezbench. They
need to be revised to plugin into latest version of ezbench.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
For sync, it really is just the average latency across all rings, but
for continuous we can expect to see the effect of concurrent dispatch
across rings. Hopefully.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
If we listen to the uevents from the kernel, we can detect when the GPU
hangs. This requires us to fork a helper process to do so and send a
signal back to the parent.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
To simplify and speed up running interruptible tests, use a custom
ioctl() function that control the signaling and detect when we need no
more iterations to trigger an interruption.
We use a realtime timer to inject the signal after a certain delay,
increasing the delay on every loop to try and exercise different code
paths within the function. The first delay is very short such that we
hopefully enter the kernel with a pending signal.
Clients should use
struct igt_sigiter iter = {};
while (igt_sigiter_repeat(&iter, enable_interrupts=true))
do_test()
to automatically repeat the test until we can inject no more signals
into the ioctls. This is condensed into a macro
igt_interruptible(enable_interrupts=true)
do_test();
for convenience.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Android defines __USE_GNU but does not provide pthread_attr_setaffinity_np()
so added an extra guard arround pthread_attr_setaffinity_np().
Signed-off-by: Derek Morton <derek.j.morton@intel.com>
|
|
Only if the trial __gem_execbuf reports an error do we want to remove
the fancy LUT flags.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
pthread_setaffinity_np is a GNU extensions, so add some __USE_GNU
ifdeffry and hope for the best if unavailable.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Since clock_gettime() should be a fixed overhead that adds to the
latency result, subtract it from the result.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
In order to keep the latency as low as possible for the idle load, we
need to keep the CPU awake. Otherwise we end up with the busy workload
having lower latency than the idle workload!
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Also useful to know how much worse than baseline the latency is when the
gem load is applied. For slower systems, presenting in nanoseconds makes
it hard to read, so switch to microseconds for output.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Instead of measuring the wakeup latency of a GEM client, we turn the
tables here and ask what is the wakeup latency of a normal process
competing with GEM. In particular, a realtime process that expects
deterministic latency.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Use a simpler statically allocated struct for computing the mean as
otherwise we many run out of memeory!
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
This patch moves userptr definitions and helpers implementation that were
locally in gem_userptr_benchmark and gem_userptr_blits to the library, so other
tests can make use of them as well. There's no functional changes.
v2: added __ function to differentiate when errors want to be handled back in
the caller; bring gem_userptr_sync back to gem_userptr_blits; added gtkdoc.
v8: remove local_i915_gem_userptr from gem_concurrent_all.c to use the global
helpers instead.
Signed-off-by: Tiago Vignatti <tiago.vignatti@intel.com>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
|
|
An oft-repeated function to check EXECBUFFER2 for a particular fail
condition.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Well, 24000 years.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Like the previous patch to gem_exec_ctx, retrict gem_exec_nop to running
for a fixed length of time, rather than over a range of different
execution counts. In order to retain some measurement of that range,
allow measuring individual execution versus continuous dispatch.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Rather than investigate the curve for dispatch latency, just run for a
fixed time and report an average latency. Instead offer two modes,
average single dispatch latency, average continuous dispatch latency.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
If we autotune the workload to only take 0.1s and then repeat the
measurements over 2s, we can bound the benchmark runtime. (Roughly of
course! Sometimes the dispartity between main memory CPU bandwidth, and
GPU execution bandwidth throws off the runtime, but that's the purpose
of the benchmark!)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
The joy of our hardware; don't let two threads attempt to read the same
register at the same time.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Try and gauge the amount of CPU time used for each dispatch/wait cycle.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Allow the producers to be set with maximum RT priority to verify that
the waiters are not exhibiting priorty-inversion.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Reading BCS_TIMESTAMP just returns 0...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Try a different pattern to cascade the cancellation from producers to
their consumers in order to avoid one potential deadlock.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Do the workload before the nop, so that if combining both, there is a
better chance for the spurious interrupts. Emit just one workload batch
(use the nops to generate spurious interrupts) and apply the factor to
the number of copies to make inside the workload - the intention is that
this gives sufficient time for all producers to run concurrently.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Just to make it easier to integrate into ezbench.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Split the distinct phases (generate interrupts, busywork, measure
latency) into separate batches for finer control.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Allow the user to choose a time to run for, default 10s
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Allow the user to select how many batches each producer submits before
waiting.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Knowing how long it takes to execute the workload (and how that scales)
is interesting to put the latency figures into perspective.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Late last night I forgot I had only added the llc CPU mmaping and not
the !llc GTT mapping for byt/bsw.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Superseded by gem_latency.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
The goal is measure how long it takes for clients waiting on results to
wakeup after a buffer completes, and in doing so ensure scalibilty of
the kernel to large number of clients.
We spawn a number of producers. Each producer submits a busyload to the
system and records in the GPU the BCS timestamp of when the batch
completes. Then each producer spawns a number of waiters, who wait upon
the batch completion and measure the current BCS timestamp register and
compare against the recorded value.
By varying the number of producers and consumers, we can study different
aspects of the design, in particular how many wakeups the kernel does
for each interrupt (end of batch). The more wakeups on each batch, the
longer it takes for any one client to finish.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
wait-ioctl skips a couple of side-effects of retiring, so provoke them
using set-domain before we sleep.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Switching between fds also involves a context switch, include it amongst
the measurements.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Benchmark the overhead of changing from GTT to CPU domains and vice
versa. Effectively this measures the cost of a clflush, and how well the
driver can avoid them.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
When extending the batch for multiple copies, we need to remember to
flag it as being in the CPU write domain so that the new values get
flushed out to main memory before execution. We also have to be careful
not to specify NO_RELOC for the extended batch as the execobjects will
have been updated but we write the wrong presumed offsets. Subsequent
iterations will be correct and we can tell the kernel then to skip the
relocations entirely.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Thomas Wood <thomas.wood@intel.com>
|
|
Add a README to introduce the ezbench.sh benchmark runner.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Report the highest throughput measured from a large set of runs to
improve sensitivity.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Apparently the pthread shim on Android doesn't have pthread cancellation,
so use the plain old volatile to terminate the CPU hogs.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
One scenario under recent discussion is that of having a thundering herd
in i915_wait_request - where the overhead of waking up every waiter for
every batchbuffer was significantly impacting customer throughput. This
benchmark tries to replicate something to that effect by having a large
number of consumers generating a busy load (a large copy followed by
lots of small copies to generate lots of interrupts) and tries to wait
upon all the consumers concurrenctly (to reproduce the thundering herd
effect). To measure the overhead, we have a bunch of cpu hogs - less
kernel overhead in waiting should allow more CPU throughput.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
To fix a build error on android
Signed-off-by: Derek Morton <derek.j.morton@intel.com>
Signed-off-by: Thomas Wood <thomas.wood@intel.com>
|
|
gem_mmap__{cpu,gtt,wc}() already has the assert built in, so replace
__gem_mmap__{cpu,gtt,wc}() + igt_assert() with it.
Mostly done with coccinelle, with some manual help:
@@
identifier I;
expression E1, E2, E3, E4, E5, E6;
@@
(
- I = __gem_mmap__gtt(E1, E2, E3, E4);
+ I = gem_mmap__gtt(E1, E2, E3, E4);
...
- igt_assert(I);
|
- I = __gem_mmap__cpu(E1, E2, E3, E4, E5);
+ I = gem_mmap__cpu(E1, E2, E3, E4, E5);
...
- igt_assert(I);
|
- I = __gem_mmap__wc(E1, E2, E3, E4, E5);
+ I = gem_mmap__wc(E1, E2, E3, E4, E5);
...
- igt_assert(I);
)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Stochastically-reviwewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
