Since these two tests exercise a working set larger than aperture, they
require stalls which are prone to being interrupted - so interrupt them
and check that everything still works.
Invoking say,
sudo ./tests/gem_render_linear_blits 1
does not make a lot of sense as we're creating a single bo. The test
does not yell at you and passes, even if the rendercopy function does
not do anything. This makes it quite harmful when trying to debug
rendercopy without realizing that count is the number of allocated bos
and must be >= 2.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
... but actually run the test with reduced memory requirements,
as the messages claims. Additional print it to stdout, stderr
seems to imply FAIL in our QA's testing rig.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Include a simple series of blits that exhaust the aperture but have the
maximum grace time between reuse.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
After full-gtt, gem_tiled_blits doesn't allocate enough to force
eviction. So query the total aperture and accommodate.
Also introduce a similar test that utilizes fences rather than
use the BLT to perform the tiling and detiling.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
A few of the tools can be performed post-mortem from a different system,
so it is useful to be able to compile those tools on those foreign
systems. Obviously, any program to interact with the PCI device or talk
to GEM will fail on a non-Intel system.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
