Age | Commit message (Collapse) | Author |
|
Make sure that at least one of the 'mmap' functions returns a valid pointer to
avoid dereferencing a NULL pointer later on. (Issue found via coverity)
v2:
- Use the version of the mapping function that will assert on fail
(Chris).
Signed-off-by: Antonio Argenziano <antonio.argenziano@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
|
|
gen4/5 require a DRM_MASTER to use MI_STORE_DW, make it so.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
|
|
Pollable spin batch exports a spin->running pointer which can be checked
by dereferencing it to see if the spinner is actually executing on the
GPU.
This is useful for tests which want to make sure they do not proceed with
their next step whilst the spinner is potentially only being processed by
the driver and not actually executing.
Pollable spinner can be created with igt_spin_batch_new_poll or
__igt_spin_batch_new_poll, after which igt_spin_busywait_until_running can
be used to busy wait until it is executing.
v2:
* Move READ_ONCE to igt_core.
* Add igt_spin_busywait_until_running. (Chris Wilson)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
In interfaces where a parameter allow to select an engine, we usually
use '-1' or '~0u' to select all engines. This patch replaces magic
numbers with a named constant.
Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Antonio Argenziano <antonio.argenziano@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
__igt_spin_batch_new() may be used inside a background helper which is
competing against the GPU being reset. As such, we cannot even assert
that the spin->handle is busy immediately after submission as it may
have already been reset by another client writing to i915_wedged.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
|
|
The "cork" bo (imported bo with attached fence) and fence is used in several
tests to stall execution. Moving it to a common place makes the codebase
cleaner.
Note that the actual test updates is done in follow up patches as it is
simpler to do in one go after one more common function is added in the
next patch.
v2: don't use new/free naming, don't use dynamic alloc (Chris)
v3: add sw_sync common functions. (Chris)
v4: squash sw_sync and vgem cork structs into one. (Chris)
v5: use anonymous enum in cork struct. (Chris)
v6: reset cork after unplugging. (Chris)
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Antonio Argenziano <antonio.argenziano@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Support creating spin batches which return an output fence using new
__igt_spin_batch_new_fence / igt_spin_batch_new_fence API.
This will be used fromthe perf_pmu@interrupts test to ensure user
interrupt generation from a batch with controlled duration.
v2: Support out fence with multiple engines as well. (Chris Wilson)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v1)
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Give the list a mutex, for we try to iterate over it from many a random
context.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
|
|
Random change when it was copied broke the interface I am using,
so bring it back into line with all the other stanzas to generate
engine[].
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
We queue N low priority hanging batches across the engines
and check that our high priority write over takes them.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Michał Winiarski <michal.winiarski@intel.com>
|
|
The early gen3 machines inherited the MI block and restrictions from
gen2, and may only use physical addresses in conjunction with
MI_STORE_DATA_IMM -- that makes it unusable for us from userspace, where
we can only use virtual offsets.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
|
Part of the attraction of using a recursive batch is that it is
hard on the system (executing the "function" call is apparently
quite expensive). However, the GPU may hog the entire system for
a few minutes, preventing even NMI. Quite why this is so is unclear,
but presumably it relates to the PM_INTRMSK workaround on gen6/gen7.
If we give the system a break by having the GPU execute a few nops
between function calls, that appears enough to keep SNB out of
trouble.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tomi Sarvela <tomi.p.sarvela@intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
[danvet: Add bugzilla link]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101079
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Currently, the main thread needs to wakeup to run the signal handler
that ends a spin batch. When testing whether a function call succesfully
waits for a batch to complete, this behavior is undesired. It actually
invalidates the test.
Fix this by spawning a new thread to handle the timeout.
v2: Get rid of mutexes. (Chris)
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
SIGRTMAX appears to be used by valgrind now for its internal tracking,
so avoid it in the helpers.
Also add some valgrind annotations in gem_mmap, to make sure that its
accesses are tracked correctly. I've also added gem_munmap, but there
are a lot of places that don't use it yet in tests/.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
WC mmaps have fewer coherency issues than GTT mmaps, important for timely
closure.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Now that the signal is disable on spin_batch_end, we don't need to do
the same from the signal handler if we have a match.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
This reverts commit 32d38ea2f6c3e07d38bc65f8cf2df1e0c0fe1c6b.
|
|
If the signal handler fires after we delete the busybatch, it would walk
the list and find no match. Then attempt to use the list_head as its
info->signo. Use the passed in sig instead.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
|
|
Fixes an issue when calling igt_spin_batch_set_timeout and then
tearing down the spinner right away before it has the chance
to timeout, causes the associated signal handler to linger. Make
sure to remove the handler on the destructor.
Signed-off-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
A lot of igt testcases need some GPU workload to make sure a race
window is big enough. Unfortunately having a fixed amount of
workload leads to spurious test failures or overly long runtimes
on some fast/slow platforms. This library contains functionality
to submit GPU workloads that should consume exactly a specific
amount of time.
Since v14: Since we are using multiple signals, walk list of batches
to terminate a batch to avoid using a single global batch. Cycle signals
between SIGRTMIN and SIGRTMAX properly.
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: tomeu@tomeuvizoso.net
Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Signed-off-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
|