If the object is at offset 0, quite likely using full-ppgtt, then the
presumed_offset set also to 0 causes the relocation to be skipped.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
