| Age | Commit message (Collapse) | Author |
|---|
|
Promote intel_os.c helpers to igt_os.c, so that I can re-use them for
some additional msm tests. Just big churny rename, no functional change.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Petri Latvala <petri.latvala@intel.com>
|
|
This reverts commit 5343ca6ad8fac39fe4d468f771af72c968404bea.
This validates gpu relocations, which we're about to delete.
Cc: Jason Ekstrand <jason@jlekstrand.net>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Lakshminarayana Vudum <lakshminarayana.vudum@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
|
|
This reverts commit 57ee41f12b7a53283fd812c5f72fcb39e6ad2197.
This validates gpu relocations, which we're about to delete.
Cc: Jason Ekstrand <jason@jlekstrand.net>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Lakshminarayana Vudum <lakshminarayana.vudum@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
|
|
This reverts commit cf2f41b3d3dfabaf3a4837062f996f3491a350b1.
And I mean revert with extreme prejudice because this was already
thrown out in
commit 39e9aa1032a4e60f776f34b3ccf4fb728abbfe5c
Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Date: Mon Aug 10 11:00:34 2020 +0200
tests/i915: Remove subtests that rely on async relocation behavior
and Chris then decided to undo that without any acks from the people
who've removed these tests. Or well anyone else. Commit fights in
upstream repositories are not acceptable.
Cc: Jason Ekstrand <jason@jlekstrand.net>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Petri Latvala <petri.latvala@intel.com>
Cc: Arkadiusz Hiler <arek@hiler.eu>
Cc: Lakshminarayana Vudum <lakshminarayana.vudum@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Acked-by: Arkadiusz Hiler <arek@hiler.eu>
|
|
Just use the one from the kernel headers. Updated with:
git grep -l LOCAL_I915 | \
xargs sed -i -e '/^#define LOCAL_I915/d' -e 's/LOCAL_\(I915[[:alnum:]_]*\)/\1/g'
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
|
|
v2 (Zbigniew Kempczyński):
- Iterate over tmp_ctx when that's what we're using
- Drop the zero-init of ctx
v3 (Ashutosh Dixit):
- Simplify context creation
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
|
|
Add a wrapper for gem_create_ext ioctl (a version of gem_create that
accepts extensions). In preparation for the driver change implementing it,
a local definition of its id and necessary structs have been added,
which are to be erased as soon as those definitions
appear in the i915_drm.h file.
The new ioctl wrapper is added to a separate file.
For consistency the wrapper of the old ioctl, gem_create
is moved from ioctl_wrappers to gem_create.
Signed-off-by: Andrzej Turko <andrzej.turko@linux.intel.com>
Cc: Zbigniew Kempczynski <zbigniew.kempczynski@intel.com>
Cc: Dominik Grzegorzek <dominik.grzegorzek@intel.com>
Cc: Petri Latvala <petri.latvala@intel.com>
Cc: Chris P Wilson <chris.p.wilson@intel.com>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Acked-by: Petri Latvala <petri.latvala@intel.com>
|
|
practically lets assume we will have < 512 relocations per page and
multiple object relocations will continue to work. Its highly unlike
to get as many relocations which basic-many-active test is testing
thus setting max limit to 2048 should suffice reloactions test.
Cc: Maarten Lankhorst <maarten.lankhorst@intel.com>
Signed-off-by: Tejas Upadhyay <tejaskumarx.surendrakumar.upadhyay@intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
|
|
i915 kernel driver is dropping reloc support gen12+. This change
will check reloc support in respective platform before executing
gem_exec_reloc in IGT.
Changes since V1 :
- Adjusted for gem_has_relocations(i915)
Ref : https://patchwork.kernel.org/project/dri-devel/patch/20210311162606.1045592-1-jason@jlekstrand.net/
Cc: Maarten Lankhorst<maarten.lankhorst@intel.com>
Signed-off-by: Tejas Upadhyay <tejaskumarx.surendrakumar.upadhyay@intel.com>
Reviewed-by: Petri Latvala <petri.latvala@intel.com>
|
|
In light of the VT-d workarounds, we may introduce padding around the
scanout vma. This should not affect relocations referencing the scanout
on !full-ppgtt where we leak the GGTT address of scanout to users.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
|
|
These tests were removed under a blatantly false statement to hide a
regression. Denying that userspace can deadlock other clients, does not
stop the violations. Introducing such deadlocks deliberately is a cause
for concern.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
As a stepping stone, increase the assumed 16 engines is enough for
everyone, to cover the current RING_MASK, the maximum number of engines
that can currently be selected during execbuf.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
|
|
We want to recognise future devices (gen = -1u) and treat them as an
extension of the latest known device, which is typically true.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
|
|
gen5 not only needs the MI_USE_GGTT flag, but also I915_EXEC_SECURE.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
|
|
These tests are no longer valid, as they require behavior that
was never accepted upstream; it assumes that relocations don't
block synchronously, and the reservation_object lock is only
held at the end of command submission to install the fences.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Dave Airlie <airlied@redhat.com>
Acked-by: Dave Airlie <airlied@redhat.com>
|
|
Replace gem_exec_bad_domains with negative test in gem_exec_reloc.
Signed-off-by: Dominik Grzegorzek <dominik.grzegorzek@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Check that when relocating a batch along an engine, we are not forced to
wait upon a resource elsewhere that userspace may be holding, or else we
are faced with a deadlock that may be injected by another user. That
deadlock may be resolved by resetting the hostile context, but in doing
so we should not break the relocation processing.
Ideally, we would avoid the deadlock.
References: https://gitlab.freedesktop.org/drm/intel/-/issues/2021
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
|
|
While we may chide userspace if they try to use the same batches from
multiple threads (the order of operations is undetermined), we do try to
ensure that each ioctl appears to be atomic from the perspective of
userspace.
In particular, relocations within execbuf are expected to be consistent
for the executing batch. That is we want the relocations applied by
this execbuf to be visible for the associated batch, and we especially
do not want to execute the batch with conflicting relocations from
another thread.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
|
|
Local macros were declared in several files as a prelude to upstream
implementations. Now that we ship include/drm-uapi, we can remove LOCAL
as we upstream.
Cc: Dixit, Ashutosh <ashutosh.dixit@intel.com>
Cc: Tahvanainen Jari <jari.tahvanainen@intel.com>
Signed-off-by: ranjeet kumar <ranjeet1.kumar@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
igt_require_gem() is a pecularity of i915/, move it out of the core.
Similar opportunistic move of gem_reopen_driver() and
gem_quiescent_gpu().
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Record receipt of the stop signal from our parent and STOP!
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
|
|
Using a quadruplicing load factor and a 5s timeout, meant that we could
submit one more workload just before the timeout that would take around
20s for the kernel to process (just from the large number of objects and
relocations). As that exceeds the hangcheck, the spinner was being
killed even though we did not hit the deadlock. Use a doubling factor,
and aim for the worst case run to be less than 10s.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
|
|
As we try to fill the entire GTT with as many objects as we can
allocate, we can easily create more than 4GiB of objects and exhaust the
restricted range. Ask for the full 48b addressing.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
|
|
Try to fill the ring with GPU relocations and cause the execution to
block; only to be resolved by a GPU hang. Whereas in the previous test,
we went deep with many relocations inside the same object, here we go
wide with one relocation inside each of many objects.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
|
|
Try to fill the ring with GPU relocations and cause the execution to
block; only to be resolved by a GPU hang.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
|
|
Since we block the engines using an igt_spin_t, in order to interrupt it
and run the nop, we need preemption. As a variant we could use a sw_sync
but that would only gain us extra coverage on bdw.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
|
|
Check we can handle active gpu relocations across multiple engines
simultaneously without blocking unrelated contexts.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
|
|
Use igt_subtest_with_dynamic for the flexible approach to engine
dependent test discovery.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
|
|
Do a pass over gem_exec_reloc where we inject lots of SIGINTs.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Antonio Argenziano <antonio.argenziano@intel.com>
Reviewed-by: Antonio Argenziano <antonio.argenziano@intel.com>
|
|
The test loops across several mappings so, when explicitly asking for a
GTT mapping it has to make sure such mapping is available.
Signed-off-by: Antonio Argenziano <antonio.argenziano@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Vinay Belgaumkar <vinay.belgaumkar@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Our worst case is blocking on a infinite batch, as the hangcheck allows
it to remain in place indefinitely. This is too slow for CI as it only
fails via a lengthy timeout. However, for our purposes a fail due to
hangcheck is an equally good indicator of the bug, so use a hostile
spinner to provoke hangcheck.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Mika Kuoppala <mika.kuoppala@intel.com>
|
|
With GPU relocations we avoid blocking inside execbuf and prevent
priority inversions where a low priority client can cause a denial of
service to higher priority clients.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
|
|
Provide the iterator name as an explicit macro parameter so that it is
known to the caller, and allows for them to properly nest loops over all
engines.
Fixes:
../tests/i915/gem_exec_schedule.c: In function ‘semaphore_noskip’:
../lib/igt_gt.h:84:44: warning: declaration of ‘e__’ shadows a previous local [-Wshadow]
for (const struct intel_execution_engine *e__ = intel_execution_engines;\
^~~
../tests/i915/gem_exec_schedule.c:653:2: note: in expansion of macro ‘for_each_physical_engine’
for_each_physical_engine(i915, other) {
^~~~~~~~~~~~~~~~~~~~~~~~
../lib/igt_gt.h:84:44: note: shadowed declaration is here
for (const struct intel_execution_engine *e__ = intel_execution_engines;\
^~~
../tests/i915/gem_exec_schedule.c:652:2: note: in expansion of macro ‘for_each_physical_engine’
for_each_physical_engine(i915, engine) {
^~~~~~~~~~~~~~~~~~~~~~~~
../tests/i915/gem_exec_schedule.c: In function ‘measure_semaphore_power’:
../lib/igt_gt.h:84:44: warning: declaration of ‘e__’ shadows a previous local [-Wshadow]
for (const struct intel_execution_engine *e__ = intel_execution_engines;\
^~~
../tests/i915/gem_exec_schedule.c:1740:3: note: in expansion of macro ‘for_each_physical_engine’
for_each_physical_engine(i915, engine) {
^~~~~~~~~~~~~~~~~~~~~~~~
../lib/igt_gt.h:84:44: note: shadowed declaration is here
for (const struct intel_execution_engine *e__ = intel_execution_engines;\
^~~
../tests/i915/gem_exec_schedule.c:1719:2: note: in expansion of macro ‘for_each_physical_engine’
for_each_physical_engine(i915, signaler) {
^~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Andi Shyti <andi.shyti@intel.com>
|
|
There is no guarantee that spinners are and will be implemented
using batches. As we have igt_spin_t, manipulate it through
igt_spin_* functions consistently and hide the batch nature.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
We can already move all the tests with distinct prefixes: gem_, gen3_
and i915_.
pm_ and drv_ tests will follow in batches, so we can do the
adjustments in the reporting/filtering layer of the CI system.
v2: Fix test-list.txt generation with meson
v3: Fix docs build (Petri)
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Petri Latvala <petri.latvala@intel.com>
Cc: Martin Peres <martin.peres@linux.intel.com>
Signed-off-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Reviewed-by: Petri Latvala <petri.latvala@intel.com>
Tested-by: Petri Latvala <petri.latvala@intel.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
|
