If the hardware has a blt ring blits aren't allowed on the render ring.
Trying to execute blits on the render ring results in a GPU hang.
Flush outstanding blits from keep_gpu_busy() before calling rendercopy()
so that they don't end up on the render ring.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
And shovel all the various helpers in there.
Also move igt_set_vt_graphics_mode to igt_kms.h since the function is
implemented in igt_kms.c. And it fits better. I kinda missed this in
the prep work.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With the header cleanup we can now give this header a suitable name,
since it now really only contains register access and other I/O
functions and assorted definitions.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Only the igt core and non-test tools should have asserts to catch
internal errors, tests and helper libraries should all user igt_asert
instead.
Fix things up where assert instead of igt_assert was used.
One tiny step towards header sanity.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Step one to properly namespace the rendercpy/mediafill functions. Als
give the buf_height/width helpers a proper igt_ prefix.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
And move the public interfaces into intel_batchbuffer.[hc].
A bit messy since we are fairly inconsistent with our header #include
handling.
Also exclude rendercopy.h from the documentation.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
rendercopy does the batch buffer flush internally, so if we want
to use it with multiple contexts, we need to pass the context
in from caller.
v2: Modify rendercopy_gen8 as well
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
This provides a macro that allows us to update all the arbitrary blit
commands we have stuck throughout the code. It assumes we don't actually
use 64b relocs (which is currently true). This also allows us to easily find
all the areas we need to update later when we really use the upper dword.
This block was done mostly with a sed job, and represents the easier
in test blit implementations.
v2 by Oscar: s/OUT_BATCH/BEGIN_BATCH in BLIT_COPY_BATCH_START
CC: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
Mostly a sed job with too manual fixups:
- one case of using _exit instead of exit
- and one case which under some conditions use 77, so convert that
check to an igt_skip.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Requested-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
lib/drmtest.c provides gem_available_fences(). Use it where
appropriate.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Lots of tests need to create havoc to LRUs in the kernel or otherwise
need to shuffle things around a bit. So make a small array permutation
function available.
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Way too much copy-pasting going on here.
Also fix a compiler warnings in gem_stress while fixup things up.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
gem_stress.c: In function ‘main’:
gem_stress.c:980:3: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 4 has type ‘unsigned int’ [-Wformat]
In other news: We've been missing a unmapping_mapping_range somewhere
in the kernel. But lazy me never came around to digging up the real
cause.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
As signals cause the syscalls to be interrupted, we often need to clean
up partial state before returning to userspace. Often a source of
unamusing bugs, so encourage gem_stress to provoke them.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
gem_stress -p1 is much more evil than gem_stress -c1, it also manages
to tear appart untiled workloads!
Now duct-taping over it still works (--apply-duct-tape) ... hm.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Remember the 3D pipeline is much more restricted than the BLT engine,
and we were feeding it buffers much larger than either the
render engine or the sampler could manager.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
... and we have a winner: gen3_mixed_blits reproduces the issue Daniel
Vetter originally found. It seems clear that we have some incoherence
between the RENDER and BLT units on gen3 that no amount of MI_FLUSH can
hide. Hmmm....
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
