| 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>
|
|
The shmem mmap and pwrite interfaces conveniently let us probe just a
few pages, without needing to populate the entire object. On discrete
and newer platforms the kernel has dropped support for both, leaving us
with MMAP_OFFSET, which will always populate the entire object, for now
at least. Luckily we can just move the batch creation to after checking
the available memory to ensure we don't hit -ENOMEM on such platforms.
Also it seems that doing a massive allocation(filling much of system
memory) and then calling intel_purge_vm_caches() seems to take 40+
seconds, like when calling intel_require_memory(). Hence switching the
ordering here should also help with that.
For reference the larger-than-life test is just a simple regression test
to ensure that some very large batch buffer(greater than ~4G) can't
overflow the batch_len, causing all kinds of issues. See 57b2d834bf23
("drm/i915/gem: Support parsing of oversize batches").
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Ashutosh Dixit <ashutosh.dixit@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
|
|
With new intel_ctx_t we're responsible to set execbuf rsvd1 (context) id
field. As same field exists for exec object there's risk to mechanically
set improper field and compiler won't complain.
Signed-off-by: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
Cc: Ashutosh Dixit <ashutosh.dixit@intel.com>
Cc: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
|
|
When relocations are not available tests must assign addresses to objects
by themselves instead of relying on the driver. We use allocator for
that purpose.
Signed-off-by: Ch Sai Gowtham <sai.gowtham.ch@intel.com>
Cc: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
Cc: Petri Latvala <petri.latvala@intel.com>
Cc: Ashutosh Dixit <ashutosh.dixit@intel.com>
Reviewed-by: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
|
|
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>
|
|
../tests/i915/gem_exec_params.c:342:37: warning: unused variable ‘e’ [-Wunused-variable]
const struct intel_execution_ring *e;
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
|
|
Once we have completed the legacy ABI tests and need to check execution,
switch to the more recent engine iterator to exercise all engines.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
|
|
Improve the differentiation between the legacy ring selector ABI and the
more recent engine selection API.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Andi Shyti <andi.shyti@intel.com>
|
|
Without opting into 48B addressing, objects are strictly limited to
being placed only the first (4G - 4K). This is to avoid an issue with
stateless 32b addressing being unable to access the last 32b page.
Assert that we do indeed fail to fit in a 4G object without setting the
EXEC_OBJECT_SUPPORTS_48B_ADDRESS flag.
Reported-by: CQ Tang <cq.tang@intel.com>
References:: 48ea1e32c39d ("drm/i915/gen9: Set PIN_ZONE_4G end to 4GB - 1 page")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: CQ Tang <cq.tang@intel.com>
Reviewed-by: CQ Tang <cq.tang@intel.com>
|
|
As we submit a failing sequence of batches, flush the failures before
continuing.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
|
|
See if can make something explode with too large batch (1ULL << 32),
while also making the batch_len implicit. We should also try each engine
since batch_len seems to have different interactions related to that.
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
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>
|
|
If there is no bsd ring at all, trying to choose any bsd ring should
fail.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
|
|
Since both the in-fence and the submit-fence utilise the same slot in
execbuf.rsvd2, we can only enable one of the two. If the user
accidentally, tries to use both with the same fence, we expect EINVAL.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
|
|
In the CI shards, we have a mixture of icl, some with vcs2, some without.
Any test that requires vcs2 will flip-flop between skips, so avoid such
requires where possible. Here, we know what the outcome should be if we
have vcs2 and if we do not, so assert we get the correct outcome.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Mika Kuoppala <mika.kuoppala@linux.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>
|
|
Sanity check that kernel rejects invalid batch_start_offset and
batch_len.
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Commit b0da8bb705c0 ("lib/i915: for_each_mmap_offset_type()")
introduced a macro that makes it easy to repeat a test body within a
loop for each mmap-offset mapping type supported by v4 of i915 MMAP_GTT
API. However, when run on an older version of the driver, those
subtests are believed to be still repeated for each known mmap-offset
mapping type while effectively exercising GTT mapping type only. As
that may be confusing, fix it.
It has been assumed that the modified macro is still suitable for use
inside gem_mmap_offset test itself. Would that not be case,
gem_mmap_offset could redefine the macro back to its initial form for
internal use.
v2: Move extra condition to a separate function and call it via
for_each_if(), in case we need to fix it again in future (Chris)
v3: Fix blind copy-paste
Suggested-by: Michał Winiarski <michal.winiarski@intel.com>
Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Pull the increasingly replicated for loop over the possible mmap offset
types into a library helper.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Antonio Argenziano <antonio.argenziano@intel.com>
Cc: Dixit Ashutosh <ashutosh.dixit@intel.com>
Reviewed-by: Antonio Argenziano <antonio.argenziano@intel.com>
|
|
The gtt/readonly tests are nothing to do with execution and engines;
they are strictly checking the copy-from-user of the ioctl arguments.
Drop the silly per-engine tests.
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>
|
|
If we can't do secure execbuf, there is no point in trying.
Signed-off-by: Kuoppala, Mika <mika.kuoppala@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
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>
|
|
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>
|
