Age | Commit message (Collapse) | Author |
|
In order to make adding more options easier, expose the full set of
options to the caller.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Petri Latvala <petri.latvala@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
|
|
Some tests measure the render's ring size but are actually meant to
measure the smallest across all engines. This patch adds measuring the
smallest size in gem_measure_ring_size_inflight() given the appropriate
parameter.
v2:
- Only expose high level API. (Chris)
v3:
- Use ALL_ENGINES macro.
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>
|
|
Although we want to specify exactly which physical engine to run on, the
busy ioctl can only return the I915_EXEC_RING identifier, i.e. the
aliased I915_EXEC_BSD for vcs0/vcs1. Horrors.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105248
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
|
|
We current have a single for_each_engine() iterator which we use to
generate both a set of uABI engines and a set of physical engines.
Determining what uABI ring-id corresponds to an actual HW engine is
tricky, so pull that out to a library function and introduce
for_each_physical_engine() for cases where we want to issue requests
once on each HW ring (avoiding aliasing issues).
v2: Remember can_store_dword for gem_sync
v3: Find more open-coded for_each_physical
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>
|
|
With intel_measure_ring_size added as common function we can use it
instead of the local copy
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Antonio Argenziano <antonio.argenziano@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
igt_spin_batch_new() includes a throttling check that GEM works, which
breaks trying to create multiple spin batches, use
__igt_spin_batch_new() instead, after verifying GEM works.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
|
|
In CI, we were observing situations where the busy blt would complete
before the very next instruction (in userspace) to assert that it was
busy. This is entirely possible if the process was scheduled away and
slept for longer than the arbitrary batch. Instead replace arbitrariness
with a precise infinity.
v2: Be respectful to UP!
v3: Move spinbatch to owning process to avoid serialisation delays.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103829
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
|
|
General update to reflect current state of things.
Signed-off-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Acked-by: Radoslaw Szwichtenberg <radoslaw.szwichtenberg@intel.com>
Acked-by: Petri Latvala <petri.latvala@intel.com>
|
|
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>
|
|
This reverts commit d7a0b61450797a3d6644c65aebf75c2a90da1a15.
|
|
Default is not an engine but an ABI alias for RCS. Remove it
from the engine list to eliminate redundant subtests and test
passes.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Acked-by: Daniel Vetter <daniel.vetter@intel.com>
|
|
Rather than have the code in multiple locations, put a copy in lib/
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Painfully obvious afterwards.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
On gen2 MI_STORE_DWORD_IMM operates on a physical, not virtual, address
i.e. we can't use it.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Easy one first.
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>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
And replace with basic testing that rendering first is detected as being
busy, and then will automatically retire.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Make kms_busy a separate set of tests so that gem_busy is kept within
the core set and not thrown out from Android due to the cairo dependency
of rendering the fb.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Flips should wait until all rendering is complete to a framebuffer
before applying.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
When doing lockless lookups using gem_busy(), one of the largest
complications is ensuring that the bo doesn't disappear as we read it.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
When deliberately hanging the GPU, don't report FAIL if we detect a GPU
hang!
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97106
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Ensure that we eventually report idle if we call gem_busy() in a tight
loop on a hanging batch.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Remember to skip using BSD on gen6, unless you want to kill the machine.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95134
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Caught by check target.
Signed-off-by: Marius Vlad <marius.c.vlad@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Marius Vlad <marius.c.vlad@intel.com>
|
|
Parallel but not concurrent!
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
The stack of batchbuffers is myth. In general there are only 2 levels of
stack for HEAD (ringbuffer, batchbuffer) and chaining up the batch
buffer just updates the lowest level of the stack. A BATCH_BUFFER_END at
any depth then returns to the ring.
So be creative and modify the batch buffer on the fly...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Add a few more (128) loops to the page full of MI_STORE_DWORD in an
attempt to try and slow down the execution to the point where a
full-debug kernel can beat the GPU.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Missed increment of the batch offset between commands.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
With lockdep enabled, the driver overhead is enormous and we need to
slow down the GPU to compenstate (otherwise the GPU is already idle when
we expect busyness). So do more work per batch.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
A little more inelegant as we can't control the delay very well, but it
should prove more vesatile and broaden the test coverge (and still be
quick enough for basic).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Now that gem_require_ring() does the right thing with BSD1/BSD2 we can
use it to our advantage here.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
I dropped this from the list of rings for some tests when refactoring to
a common array. Almost all of the tests should be run over the default
exec engine to ensure ABI backwards compatiblity.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
A few tests wish to execute on every engine, so centralise the array of
known engines.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
An oft-repeated function to check EXECBUFFER2 for a particular fail
condition.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Exercise the busy-ioctl and verify it reports the right active engines
using the execbuffer notation.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|