Tests _must_ be able to run as non-root and on non-intel platforms,
otherwise the enumeration is busted (since QA enumerates testcases on
a gpu-less xeon box).
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The kernel will round it, so if we don't we'll have a spurious
mismatch. Happens on my machine here with 650-1300MHz range, where the
midpoint is 975.
Cc: Jeff McGee <jeff.mcgee@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Test that RPS functions as expected after a gpu reset.
Signed-off-by: Jeff McGee <jeff.mcgee@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The load helper can be set to HIGH or LOW. HIGH is the original mode
of sending continuous dword store commands. LOW adds a pause between
each command to reduce throughput.
Signed-off-by: Jeff McGee <jeff.mcgee@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This ensures that gpu is quiescent when load helper exits.
Signed-off-by: Jeff McGee <jeff.mcgee@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Like subtest basic-api, but additionally requires that current
frequency is increasing to the configured maximum within reasonable
time since we are loaded.
Signed-off-by: Jeff McGee <jeff.mcgee@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The load helper submits repeated dword store commands to keep the
gpu loaded while subtests running in the parent process check for
expected rps response.
Signed-off-by: Jeff McGee <jeff.mcgee@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Like subtest basic-api, but additionally requires that current
frequency is settling to the configured minimum within reasonable
time since we are idle.
Signed-off-by: Jeff McGee <jeff.mcgee@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Exercise that calling madvise produces expected results
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Bunch of explicit include paths needed adjustments and
eviction_common.c needs to be added to the dist files.
This has been broken in the following three commits:
commit 42bcd05eb3f1545fbf9c397c3f37c3f6a27c5da4
Author: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Date: Mon Feb 3 10:59:41 2014 +0000
tests/eviction_common: Avoid submitting duplicate objects
commit b92b397d5e4ffe10ed92fb2fc6711758ef5bcf89
Author: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Date: Tue Dec 3 15:09:57 2013 +0000
build: Make sure asserts are enabled for tests
commit 8c33e9ad111d27b84db4daac43809a807f262632
Author: Ben Widawsky <benjamin.widawsky@intel.com>
Date: Fri Dec 6 20:35:29 2013 -0800
intel-gpu-tools: Version informatio
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Ben Widawsky <benjamin.widawsky@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Make sure selection loop does not generate duplicates
when it picks a subset of objects for a single exec buffer.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In preparation for userptr test we move the eviction logic
into a common file so it can be used from both test cases.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The goal of this test is to ensure that we respect inter ring
dependencies. A more detailed description of what it tests is in a
comment.
The tests relies on having a blit function for the ring, so is currently
only checking synchronization between the render and blitter ring.
v2: Actually create an inter-ring dependency by making the first copy on
ring2 and the second on ring2, not both on ring2.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Instead of recompiling the lib directory for every tool or tests we can just
re-use the static library. This also has the nice side effect of fixing the
android "mm" command to allow android users to only rebuild the local changes
in either the test or tools directory.
Signed-off-by: Rafael Barbalho <rafael.barbalho@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
All the Android.mk files had the same directives to find the path of
libdrm & libpciaccess. These are no longer required as the android system
now allows the libraries being used to export include paths to dependant
modules & programs.
Signed-off-by: Rafael Barbalho <rafael.barbalho@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Storing values avoids some unnecessary overhead but more importantly
allows all of our processing to be atomic.
Signed-off-by: Jeff McGee <jeff.mcgee@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Add a function that methodically varies min and max to exercise
several valid and invalid combinations. Allow the caller to
define what is to be checked between each step.
Signed-off-by: Jeff McGee <jeff.mcgee@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Note that we use twice the number of buffers, and so we need to restrict
num_buffers appropriately to fit within RAM.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72255
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we stop all the rings, we can end up blaming the innocent
rings on hangcheck.
Reference: https://bugs.freedesktop.org/show_bug.cgi?id=73652
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
My git failures are truly remarkable. I ended up pushing the wrong
commit here:
commit 1552aa21124cabe762862bb414490510415a2b2d
Author: Ben Widawsky <benjamin.widawsky@intel.com>
Date: Mon Jan 13 06:28:45 2014 -0800
gem_storedw_batches_loop: Fix for BDW
This puts the offset of the reloc in the wrong place for pre-BDW
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73866
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
As a flip is outstanding, there is an issue that the kernel may not be
able to release one of the fences that userspace requires and erroneous
report EDEADLK (on gen2, gen3).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73696
- We need to drop root to actually hit the limits. This requires us to
fork the actual test since otherwise the exit handlers (which
require root) fail the entire test.
- Don't assert that the gem create ioctl succeeds, it won't on the
final run of the loop.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Exhausts the system limit on open files and then tries to create
a new shmem-backed gem object. Linus Torvalds reported that this
blows up on a null obj->base.filp, but I can't reproduce this here:
http://lists.freedesktop.org/archives/intel-gfx/2014-January/038433.html
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If it's not in the multi-test target group testrunners won't pick up
on the fact that they need to enumerate subtests first.
Cc: jeff.mcgee@intel.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Since we don't execute any subtests, using igt_exit leads to
inconsistent behaviour. In the future, this may be converted.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73641
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Fix usage of shared variable LOCAL_PATH in deferred variable expansion area.
In Makefile language, rule and dependency definitions use immediate
expansions of variables, so they get expanded as soon as the rule is
created (1st pass). Rule implementation (a.k.a recipe) use deferred
expansion (2nd pass).
Android effectively makes all Android.mk files a single makefile by
including them all in a big tree from the toplevel makefile. The rules
are all evaluated in the first pass and targets are generated. Then the
2nd pass happens and the required target's recipes are run. At this
point, LOCAL_PATH has been assigned the value from the last evaluated
Android.mk in the 1st phase that defined LOCAL_PATH (most Android.mk use
this variable). In my particular case, it was the bootloader's
Android.mk that was evaluated last and had defined LOCAL_PATH to it's
path. The errors are rather misleading due to it looking like a bug in
another module's Android.mk rather than this one :)
Basically, if you want to use a variable that any other Android.mk
defines, then you can only use it in an immediate expansion context,
not a deferred expansion context as it will likely be re-defined by
the time the 2nd pass happens.
This patch stores it in a unique variable that should not be being
used by other Android.mk files. An alternative fix would be to use $@
and $< as the files in question are target and dependency, but I never
like using those as they can easily break if dependencies are added
etc. I prefer variable to be explicitly named to make them obvious.
See gnu make manual for explanation of deferred vs immediate
expansion of variables :
http://www.gnu.org/software/make/manual/make.html#Reading-Makefiles
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Robert Beckett <robert.beckett@intel.com>
Run all relevant tests on all rings.
Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Split context related tests from non-context ones
and cleanup the naming.
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It's pure luck that nv can detile some of the intel layouts since one
of the video MC formats matches it. Since we can't possible fix this
comment the test out.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73538
Acked-by: Maarten Lankhorst <bugs@mblankhorst.nl>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
