- 12 Aug, 2013 7 commits
-
-
Daniel Vetter authored
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>
-
Daniel Vetter authored
To simplify things add a set of gem_check_<ring> functions which take care of this. Since I've opted for static inlines drmtest.h grew a few more header includes which was a neat opportunity to dump a few redundant #defines. This kills all the skipped_all hand-rolled logic we have. Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
This way we can rip out all the skip handling from the test control flow, and additionally (by using drmtest_retval()) even get correct exit codes. The only tricky part is that when we only want ot skip parts of a test (like for gem_pread and gem_pwrite) we need to split out those parts as subtests. But no addition of control-flow is required, the set/longjmp magic in the helpers all makes it happen. Also we make extensive use of the behaviour of drmtest_skip to skip all subsequent subtests if it is called outside of a subtest. This allows us to re-flatten the control flow a lot. Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
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>
-
Daniel Vetter authored
Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Chris Wilson authored
Bugzilla: https://bugzilla.freedesktop.org/show_bug.cgi?id=68003
-
- 10 Aug, 2013 1 commit
-
-
Chris Wilson authored
-
- 07 Aug, 2013 5 commits
-
-
Daniel Vetter authored
-
Daniel Vetter authored
... not a great display of my prowess here. Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
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>
-
Daniel Vetter authored
Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
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>
-
- 06 Aug, 2013 9 commits
-
-
Daniel Vetter authored
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>
-
Daniel Vetter authored
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>
-
Daniel Vetter authored
Leak test that leaks ... Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Chris Wilson authored
Just to help sanity test alternate paths.
-
Chris Wilson authored
Further trying to determine the effects of setting snooping.
-
Chris Wilson authored
-
Chris Wilson authored
-
Chris Wilson authored
-
Chris Wilson authored
-
- 29 Jul, 2013 1 commit
-
-
Imre Deak authored
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>
-
- 25 Jul, 2013 1 commit
-
-
Daniel Vetter authored
The lib/drm_lib.sh load path trick doesn't work otherwise. Tsk. Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 24 Jul, 2013 7 commits
-
-
Daniel Vetter authored
They all race against each another, no worker-slave relationship like in the other subtest. Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
Oops, failed to git add. Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
- 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>
-
Daniel Vetter authored
This reverts commit bd927662. It's bogus. Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
And fail the test if the leak count is bigger than 0. Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
Oops. Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 23 Jul, 2013 4 commits
-
-
Daniel Vetter authored
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>
-
Daniel Vetter authored
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>
-
Daniel Vetter authored
Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
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>
-
- 22 Jul, 2013 1 commit
-
-
Ben Widawsky authored
Requested-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Ben Widawsky <ben@bwidawsk.net>
-
- 20 Jul, 2013 1 commit
-
-
Chris Wilson authored
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.
-
- 19 Jul, 2013 3 commits
-
-
Damien Lespiau authored
One code path to maintain is always better. Signed-off-by:
Damien Lespiau <damien.lespiau@intel.com>
-
Damien Lespiau authored
Signed-off-by:
Damien Lespiau <damien.lespiau@intel.com>
-
Xiong Zhang authored
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>
-