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>
|
|
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>
|
|
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>
|
|
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>
|
|
Rather than have the code in multiple locations, put a copy in lib/
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
In the old shared GTT modes, some addresses may already be in use and so
we cannot pin our objects there. Skip placing objects to those locations
for maximum test coverage.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
The contract with the kernel is that the presumed_offset matches the
value written into the batch. In the case where we were creating a new
object to simulate the old being relocation, we were writing some other
value into the batch. It just happens that using GGTT read back on !llc
was causing the original batch to migrated into the aperture, leaving a
hole suitable for the new batch, and the kernel could therefore skip the
relocation (causing us to complain).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100674
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Worst case is that the kernel has to copy the entire incoming reloc[],
so double the memory requirements.
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>
|
|
gem_exec_reloc --list-subtests breaks otherwise.
v2: use igt_subtest_group (Chris)
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Petri Latvala <petri.latvala@intel.com>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
If we do relocations on the gpu, then we have to wait for the gpu to
finish writing to the buffer before the relocations are complete.
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>
|
|
If the relocation is incomplete and we take the slow path, we fill the
reloc.presumed_offset with -1. This shouldn't happen for the basic
tests, at least not on the most recent kernels, yet can happen in older
kernels. Just reduce the failure to a warn.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Recently a patch ran successfully through BAT that broke 64bit
relocations on a couple of machines. Oops. So lets add a very fast set
of tests to check basic relocation handling.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Supersedes gem_dummy_reloc_loop.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
A few other tests I have updated recently to use MI_STORE_DWORD also need
the magic bit for gen4/5.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
The first steps towards basic relocation handling. In today's edition,
we ask how well does the kernel fare if we pass it relocations via
mmappings of our buffer objects.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|