This also raises the absolute wait-for-vblank sequence step from 5 to
10, just to make it consistent with the corresponding 1x subtests.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=69161
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Provide two arguments version, and verbose, which allow printing from an
arbitrary igt test. It will show system information (from build time,
not runtime), as well as the git SHA being used.
This will help reduce errors when people try to reproduce problems.
As an example if I want to verify someone is running the correct version
of a test, I could ask them to do:
bwidawsk@ironside ~/intel-gfx/intel-gpu-tools (master)$ sudo ./tests/gem_exec_nop --verbose
gem_exec_nop-git-3c5423b (Linux ironside 3.12.0-1-ARCH #1 SMP PREEMPT
Wed Nov 6 09:06:27 CET 2013 x86_64 GNU/Linux)
Time to exec x 1: 35.000µs (ring=render)
Time to exec x 2: 28.000µs (ring=render)
Time to exec x 4: 20.000µs (ring=render)
Time to exec x 8: 14.625µs (ring=render)
Time to exec x 16: 11.188µs (ring=render)
Time to exec x 32: 11.125µs (ring=render)
Time to exec x 64: 10.328µs (ring=render)
Time to exec x 128: 10.172µs (ring=render)
Time to exec x 256: 10.234µs (ring=render)
Time to exec x 512: 10.232µs (ring=render)
Time to exec x 1024: 10.121µs (ring=render)
Time to exec x 2048: 10.151µs (ring=render)
Time to exec x 4096: 11.474µs (ring=render)
Time to exec x 8192: 9.432µs (ring=render)
Time to exec x 16384: 6.003µs (ring=render)
Time to exec x 32768: 5.029µs (ring=render)
Time to exec x 65536: 4.206µs (ring=render)
Time to exec x 131072: 3.630µs (ring=render)
Subtest render: SUCCESS
--verbose is provided for completeness, but doesn't seem too useful at
the moement.
bwidawsk@ironside ~/intel-gfx/intel-gpu-tools (master)$ sudo ./tests/gem_exec_nop --version
gem_exec_nop-git-3c5423b (Linux ironside 3.12.0-1-ARCH #1 SMP PREEMPT
Wed Nov 6 09:06:27 CET 2013 x86_64 GNU/Linux)
I've put version.h in the root directory so that any subdir can access
it. I've added the tests usage since it's immediately useful, and done
easily via Daniels igt infrastructure work.
v2:
- Always print the version number.
- We want to print uname at runtime.
- Also prefix the i-g-t release version.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net> (v1)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
QA has asked me "How can we make sure LPSP is working?". Now, instead
of writing big paragraphs, I can just answer "make sure pm_lpsp
works".
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
It's what callers expect - pipe_crc_new is the function where
we pass a potential failure back to callers.
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
No need to duplicate this all over the place.
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Or more precisely: It already has an igt_require. So we cant ditch it
from tests.
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It is to check whether media pipeline on render ring works. Codes
are copied and modified from the rendercopy case which uses 3D pipeline.
However media pipeline is simpler than 3D pipeline and there is few changes
between gen6,gen7 and gen8
Reviewed-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
NOTE: Some subtests are still failing, but I haven't found the bug yet.
At least this should help QA meanwhile.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
NOTE: Some subtests are still failing, but I haven't found the bug yet.
At least this should help QA meanwhile.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
I've opted to not use the PIPE_CONTROL w/a for now. I am unclear if it
is actually required (the test does pass).
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
It didn't pan out at all since atm we don't evict context objects. But
maybe it's useful for when that happens.
v2: Actually test eviction. Took a while to figure that one out.
And indeed the testcase now fails because we don't evict the previous
context as we should.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This exercise the bug fixed in
commit 1020dc6990168a5081ffad620c440e220f05b460
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Tue Oct 29 08:55:57 2013 +0000
drm: Do not drop root privileges for a fancier younger process
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This triggers use after free oops on request->batch_obj when
going through the rings and setting reset status on requests,
after a gpu hang.
v2: Streamlined the test and added comments (Daniel)
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We do not have GLib there so it does not build.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Tests depend on assertions being enabled since they can, and do,
contain actual test steps. They are also mandatory for ensuring
sane test case behaviour.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
kms_fbc_crc will perform various write operations to the scanout buffer
whilc FBC is enabled. CRC checks will be used to make sure the
modifcations to scanout buffer are detected.
The operations include:
- page flip
- GTT mmap
- CPU mmap
- blit
- rendercopy
- context switch + rendercopy
- combination of a page flip and each operation listed above
v2: Use gem_sw_finish instead of drmModeDirtyFB after CPU access
v3: Drop pwrite tests, call gem_bo_busy() after rendering, drop
set_domain() calls after mmap access, wait for 2 vblanks
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
rendercopy does the batch buffer flush internally, so if we want
to use it with multiple contexts, we need to pass the context
in from caller.
v2: Modify rendercopy_gen8 as well
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
If a subtest fails, it'll leave the pipe CRC file open, which will
prevent subsequent subtests from opening the file. Make sure the file
is cloesed before trying to open it again.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Inspired by the recent pile of tests for the CS, which doesn't split
up the tests into per-ring subtests.
Cc: bradley.d.volkin@intel.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This one was missing. For some reason we never really detected it on
our test suite. I checked the Kernel source and now we should be fine.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Instead of creating a new FB every time we need one, create a cache of
FBs and reuse whenever possible. That means we'll create at most two
FBs, and reuse them hundreds and hundreds of times.
The kmstest_paint_test_pattern function takes about 1-2 seconds to
run, and we'll avoid it whenever we reuse the FB.
This makes the time taken to run the modeset-lpsp-stress subtest go
from 2:29 to 1:29.
A full "time ./pm_pc8 --quick" goes from 8:14 to 6:27.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
If we want to actually reach PC8+ states, we need to properly
configure all the devices on the system to allow this. This function
will try to setup the things we know we need, but won't scream in case
anything fails: we don't know which devices are present on your
machine, so we can't really expect anything, just try to help with the
more common problems.
Another reason for this commit is that I got tired of having to
readjust the runtime PM policies every time I reboot my machine.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Getting global reset count needs to be tested with root and
non root access.
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
To make driver report a simulated hang in dmesg.
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>
For BDW+, there BATCH_BUFFER_START is 3 * 32bits in length and
length needs to be encoded into the opcode.
Suggested-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Instead of freaking out about negating the skip condition and punting
I could have remembered that I've solved this already ...
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Not meant to be used on the QA cycles, but by developers who just want
to quickly check things while doing development. Reduces the total
time from 27 minutes to 6 minutes on my machine.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
I was suspecting some problems just happen if we have a bigger wait
than the current ones we have, so add a new WAIT_EXTRA flag just to
see if the problems really happen. Also, add support for the wait
flags on the gem stress tests, and use them.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
It's not executed by default, and it's completely relying on Haswell
registers and on internal knowledge of how the Kernel is supposed to
work. Since we plan to test generic runtime PM on all supported
platforms, maintaining this test so it works on all those platforms
will be a pain. We already have some ideas on how to verify registers
that must stay at specific values from inside the Kernel, so let's
kill this test and wait until the proper Kernel code gets merged.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
