This things just won't die (libva!!!), so add an option to test them.
_Not_ meant to test snoopable mappings.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This seems to be another trick to massively improve correctness
of the render blit. At least on my i945.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Of all the things I've tried, this seems to be the only thing
to fix tile corruptions reliably on gen2&gen3 (safe for outright
disabling the render copy).
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
That little snippet creapt in and magically made render copy work -
by essentially disabling it.
Restore order, everything incoherent again.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It seems to be randomly broken, every boot in a slightly different
way on my i945gme. Works quite well on my Q35. So add an option to
disable it till this is resolved.
Well, more testing seems to suggest that I've been hunting ghosts.
Or maybe not and it works now simply because it's a different day.
Anyway, leave this in for future testing.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
gem_stress maps all buffers, so more only results in trashing (which
should be handled with an option).
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
ddx and mesa assume that this is issued after every blit command.
Breaking that invariant results in a dying gpu.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The busy bo has a fixed size (1024x256, 32bpp) whereas the scratch bo
may need to vary their size to exercise different features of fence
allocation.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
And a few other things:
- inline checking when copying tiles with the cpu, fails _much_ faster.
- bo size seems to have a tremendous effect, put on the TODO.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Move the loop operations around for test_all_modes so that it is clearly
split up into the desired phases.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We have not a unified tool to check Intel display driver and we plan to use
intel-gpu-tools/testdisplay to check Intel display driver even though some
function tests can be found in libdrm/test. 3 new features are added:test
all supported modes, force mode and dump mode info(dump mode info is based on
libdrm/tests/modetest).
[ickle: attack the whitespacing!]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
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>
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>
Using for diagnosing some mysterious slowdowns. Should include a variant
for basic benchmarking...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
After bf79cb914dbfe848add8bb76cbb8ff89110d29ff, drm uses ENOENT to
report unknown handles buffer objects, update the tests accordingly.
Fixes:
Bug 29794 - some intel_gpu_tools cases fail
https://bugs.freedesktop.org/show_bug.cgi?id=29794
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>
This is a test case that overcommits fence registers between threads, which
are copying from one fenced bo to another. In earlier versions of the driver
this would cause excessive spinning as the first inactive (i.e. not in use
by the GPU) would be used to service the next page. After all the fence
registers had been allocated, in effect only the very first fence would then
be used for all subsequent faults.
