As we use chained batch into itself to hang the gpu, there
was no need to end the batchbuffer with BATCH_BUFFER_END.
With the introduction of command parser, the batch
need to have proper BATCH_BUFFER_END in it or it
will be rejected.
While at it, shift the upper half of batch gtt_offset
accordingly with gen8+
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Use extra threads to cause extra memory pressure and stress upon the
relevant code. Limit the number of threads to available fences to avoid
falling off the fence cliff.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reset the system to a vanilla state before we query how much RAM/swap
space is available for our testing.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If there is not enough free RAM+swap for us to execute our test, we will
hit OOM, so check first.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Add Makefile targets to create two text files containing the list of
available single and multi-test programs. This enables the tests to be
enumerated without requiring the build system.
Signed-off-by: Thomas Wood <thomas.wood@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
A recent commit means igt_debugfs.c now needs to include igt_kms.h,
which in turn includes igt_fb.h and hence cairo.h.
We need to avoid this inclusion of cairo.h when building for Android,
(until we have a cairo port) so I have added a #ifndef around it.
Signed-off-by: Tim Gore <tim.gore@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When building within the android tree (specifically in /external)
the compilation fails due to the wrong versions of some header files
getting picked up. This commit adds some include paths to ensure the
correct headers are found
Signed-off-by: Tim Gore <tim.gore@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In android builds there is no reliable way to determine if mmap64 is defined
or not, and this sometimes leads to a compile error due to its re-defnition.
So this commit avoids its use altogether in intel-gpu-tools for Android builds,
unless the HAVE_MMAP64 macro is defined.
Signed-off-by: Tim Gore <tim.gore@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Someone with actual automake-fu really needs to fix this up for real
since compiling a bunch of source files again, with broken dep
tracking even just because we can't link against a .la somehow really
isn't too awesome.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Note that the sleep(5); to fully idle the gpu is _really_ important.
Without it the bug is not exhibited.
The issue at hand is that after gem_quiescent_gpu we are at max
(expected, since the blocking waits peg to max), but then we never go
down to a lower freq again until we're fully idle. The tiny load is
sufficient to keep the gpu at max. I've played around with this a bit
and even ridiculously low loads (like one MI_STORE per 50ms) are
enough to keep the gpu at max freq.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Apparently some rps chips are prone to stick to max once you're there.
And all the synchronous waits in gem_quiescent_gpu are _really_ good
at forcing the kernel to go full throttle.
And even a positively tiny load (one MI_STORE_IMM per 50 ms) is enough
to eternally keeep it there, which means the first idle measurement of
the freqs before we do the reset it completely busted.
Just add a wait before the tricky test and call it a day.
Option b) would have been to now have this tiny load, but I think a
good reminder how quirky rps is is always welcome. Just in case we
start sleeping too easy at night.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74956
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Using uint64_t in that second member makes it aligned to 64bits, while
the first member is only 32bits. We then had a 32bits hole in there!
Found-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ben Widawsky <benjamin.widawsky@intel.com>
Cc: Rafael Barbalho <rafael.barbalho@intel.com>
Tested-by: Rafael Barbalho <rafael.barbalho@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Also realign function parameters and replace abort() with igt_fail()
while at it.
v2: Forgotten to add a nice intro.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
igt_kms docs are just skeleton and also added igt_fb to make sure the
linking works correctly.
Next up: Actually documenting igt_fb.
Also fix that depency spelling fumble I've copied around to a few too
many places.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
For 1 function and 2 types we kinda don't need separate files.
Especially now that igt_kms is much more focused on the actual modeset
stuff with all the framebuffer helpers extracted to igt_fb.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Shorter and more in line with our general igt_ prefix for everything
which isn't somehow intel or i915-gem or otherwise hw specific - these
helpers here are all fully generic framebuffer handling functions
based on kms + cairo.
Well, the actual buffer alloc is done with i915 gem, but meh ;-)
Two special cases:
- bpp_depth_to_drm_format and drm_format_to_bpp completely lacked
prefixes, so just add igt_.
- write_fb was a bit misleading given that we have gem_write for
uploading to buffers. Rename that to write_fb_to_png to make it
crystal clear what this thing does even without looking at docs.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Stuff all the framebuffer creation, cairo and drm fourcc format
handling in there. This gives us a very clear cut in the headers where
igt_fb.c only needs to include igt_fb.h, and igt_kms.c includes both
(well igt_kms.h pulls in igt_fb.h since we always need this).
The aim here is to add api docs for igt_fb since that part of the kms
library seems fairly stable already, while all the mode setting and
iteration is still a bit in flux.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Use the new-style function using drm fourcc codes instead everywhere.
To easily use thew fourcc based interface also expose
bpp_depth_to_drm_format from the library. Finally include drm_fourcc.h
from the igt_kms.h header since pretty much everyone needs this now.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
quick_dump built fine, but it could actually run, since a lot of the
linking happens at run time. There is one hack where we redefine the
environment stuff, since depending on igt_aux means we have to pull in
libdrm, which I do not want to do.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
I've forgotten that we might want to call this from within specific
subtests (or special helpers like the autoresume one).
Also props for being competent enough to write a testcase, but
incompetent enough to botch the job up.
Fix both things and remove a leftover debug printf while at it.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
I think we might have some use for a do_ioctl_expected_errno or some
such thing. But that's for later.
Cc: Brad Volkin <bradley.d.volkin@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is a speculative test in that it's not particularly relevant
today, but is important if we switch the parser implementation to
use kmap_atomic instead of vmap.
Signed-off-by: Brad Volkin <bradley.d.volkin@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Start with a simple testcase that should pass.
v2: Switch to I915_PARAM_CMD_PARSER_VERSION
Signed-off-by: Brad Volkin <bradley.d.volkin@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
To gain more coverage on interface, default context and banning.
As there is no proper reset support for gen <= 3, we only
do limited interface testing on those.
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
