| Age | Commit message (Collapse) | Author |
|---|
|
The goal of gem_exec_gttfill is to exercise execbuf under heavy GTT
pressure (by trying to execute more objects than may fit into the GTT).
We spread the same set of handles across different processes, with the
result that each would occasionally stall waiting for execution of an
unrelated batch, limiting the pressure we were applying. If we using a
steaming write via a WC pointer, we can avoid the serialisation penalty
and so submit faster.
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>
|
|
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>
|
|
Since all the batches start with the same content, we can reuse the same
buf to fill them.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
It access hardware, hence why the simple igt_only_list_subtests()
check from igt_fork/stop_signal_helper() isn't enough.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
|
|
Set bit 21 to enable qword writes for Broadwell.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Since we do not use the allow-48b GTT per-object flag, even on
Broadwell+ we will be constrained to 4GiB of usage GTT.
Also only do a single pass for BAT as suggested by Marius Vlad.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Since we want to focus on the issue of running with a full-gtt, and part
of that is in handling the eviction, do a warm-up pass before we start
the clock that allocates the objects and fills the gtt.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
This is an attempt to emulate the stressful nature of gem_cs_prefetch
without being as slow i.e. without trying to detect the GPU prefetch
issues and just emphasive the basic correctness in handling enough
batches to fill the GTT similar to gem_ringfill aims to fill a ring.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
