With the new _f variants we can replace almost all of them.
Also remove a ton of checks for argc != 1, they're a bit useless ...
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is mostly important to get the SKIP reporting right, but I've
found a few stragglers that wanted to get converted over to the igt
result reporting completely.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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>
The _block postfix meant to convey that a C statement/block must
follow can be misread as the verb to block. So drop it.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Doesn't do more than an if (drmtest_run_test(name)) right now, but
as soon as we get a bit of infrastructure to handle test failures and
skipping, this will get more interesting.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Let's start by a small set of tests, to eventually consider running
more.
The current list should then be:
gem_mmap
gem_pread_after_blit
gem_ring_sync_loop
gem_ctx_basic
gem_pipe_control_store_loop
gem_storedw_loop_render
gem_storedw_loop_blt
gem_storedw_loop_bsd
gem_render_linear_blits
gem_tiled_blits
gem_cpu_reloc
gem_exec_nop
gem_mmap_gtt
v2 add (Daniel Vetter)
gem_exec_bad_domains
gem_exec_faulting_reloc
gem_flink
gem_reg_read
gem_reloc_overflow
gem_tiling_max_stride
prime_*
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
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>
With this at least the y-tiled test reliably fails on my machines, but
x-tiled still passes on some. More ideas to tune this highly welcome.
v2: Fill cpu caches with data for each newly allocated bo. This seems
to do the trick on my snb here _really_ reliably. So apparently the
backsnoop for llc gtt writes is the crucial ingredient here to make
the test fail.
While at it, also stop leaking mmap space.
v3: Fixup commit message.
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Add write-verify test to gem_fence_thrash. Test will create
multiple threads per fence then verify the write into fenced region.
v2: non-threaded, non-tiled tests added. suggested by Chris Wilson.
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
autoconf can be configured to not generate a config.h but to give the
defines with command line arguments instead. In this case, there's no
config.h to include.
To work in both cases autoconf adds a HAVE_CONFIG_H define on the command
line to signal there's a config.h to include.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Without enabling largefile support the prototype for mmap64() is broken
on Linux/x86_64 with the result being a 32-bit integer sign-extended
to fill a 64-bit pointer. Hilarity ensues.
AC_USE_SYSTEM_EXTENSIONS is used to let autoconf take care of setting
the right system defintions for POSIX threads & similar extensions to
the base POSIX API. Since it will also #define _GNU_SOURCE 1, remove
the extra setting to avoid compiler warnings about redefined macros.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Despite the name implying it's a standard part of the POSIX threads API,
pthread_yield is actually non-standard and less portable than sched_yield.
For instance, Solaris only has sched_yield, and not pthread_yield.
Since even the Linux man page suggests using sched_yield, just call that.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We actually want to test lru behaviour, so do a bit of work with
the fence before yielding to the next thread (we use twice as many
fences as there are, so yielding always is pretty bad, no matter how
clever our fence stealing).
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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.
