GitLab

... not a great display of my prowess here.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

This checks that we really always fill the dma-buf export cache. Which
sometimes we don't.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

This testcase mixes correctnes tests with performance tests, so it's
good to track the different correctness test separate for QA.

Together with pread_after_blt the pwrite->blt tests here exercise the
full cache coherency lifecycle of both snooped and uncached objects.

/me is happy
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

New testcase to check that pwrite/pread correctly synchronize with
oustanding rendering. Just to catch regressions when we change
something.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Similar to how we test flink races. Note that on unfixed kernels this
oopses, and with my current set of patches it still leaks like mad.

v2: Only close the prime fd if we've successfully created it.

v3: Add a reimport test to check whether we don't race when reaping
the obj->dma_buf link.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Leak test that leaks ...
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Just to help sanity test alternate paths.

Further trying to determine the effects of setting snooping.

intel_copy_bo assumes a 32bpp bo, whereas we passed it bos with
arbitrary bpp values. This resulted in thrashing GPU memory following the
destination bo.

Fix this by using a blit helper that can handle other bpps too.
Signed-off-by: Imre Deak <imre.deak@intel.com>

The lib/drm_lib.sh load path trick doesn't work otherwise. Tsk.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

They all race against each another, no worker-slave relationship
like in the other subtest.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Oops, failed to git add.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

- Enable subtest support.

- Add a check for the same flink name in the racing threads, which is
  an issue one of my recent patches actually fixes.

- Add the test I've actually wanted to write which races an flink
  against gem close (with no open in between). That one does indeed
  leak.

- Readd the leak check, but note that this needs a fixed kernel.
  Otherwise the leak counter will be utter garbage.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

This reverts commit bd927662.

It's bogus.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

And fail the test if the leak count is bigger than 0.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Oops.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

This exercises a race in the flink name descruction of the current drm
gem core. When racing a gem close with a gem open the open can sneak
in and cause the kernel to leak the flink name and its reference.

This results in leaked gem objects that won't get reaped even at drm
file close time. On my 2 core/4 threads snb machine this leaks on the
order of 1k objects per second.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Requires us to rename a few things in the gem_flink test to avoid
variable shadowing.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

This exercise the bug fixed in

commit 94a335dba34ff47cad3d6d0c29b452d43a1be3c8
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Jul 17 14:51:28 2013 +0200

    drm/i915: correctly restore fences with objects attached

For fun I've also added a subtest for the inverse transition.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Requested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>

Extend the simply functionality by repeating it under the rude
interrupter and chain together a couple of steps in new test cases.

As a compromise for adding more tests, incorporate the piglit subtest
framework.

One code path to maintain is always better.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>

the reloc, pread, pwrite slow path will be prevented by prefault,
these subtests will disable prefault first, then do reloc, pread,
pwrite, finally enable prefault.
Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.com>

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>

We tweak the tests marked as runnable in simulation to run more quickly,
more often then not at the expense of stress testing (which is of an
arguable interest for the initial bring up in simulation). Hopefully the
values chosen still test something, which is not always straightforward.

It does run quickly, the number on an IVB machines are:

$ time sudo IGT_SIMULATION=0 ./piglit-run.py tests/igt.tests foo
[...]
real	2m0.141s
user	0m16.365s
sys	1m33.382s

Vs.

$ time sudo IGT_SIMULATION=1 ./piglit-run.py tests/igt.tests foo
[...]
real	0m0.448s
user	0m0.226s
sys	0m0.183s
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>

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>

We want prime to only ever create one native gem object for each
dma-buf it sees. This can e.g. happen if multiple processes import the
same foreign dma-buf, e.g. the application imports a yuv frame from
v4l to encode it into a video stream and the compositor imports it
into his fd again to display it with an overlay.

Hence add a bunch of tests which check all the various orders in which
this could happen. Currently they all fail.

Checking flink names is the easiest (and afaik only) way to check
whether we're indeed dealing with the same object.

This checks both ways, i.e. exporting from i915 and from nouveau, each
with two variants of the test: One reuses the prime fd, the other
closes it and creates a new one.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Different argument order, otherwise the same.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>