Each mode line has a number just like '[i]'. So we can only test the specified mode with giving the number of mode to '-o' parameter.
Signed-off-by: Yi Sun <yi.sun@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Repeat the memset streaming performance test on the same mapping so that
we can factor out the overhead of establishing the GTT/CPU mmaps.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This make the reasonable assumption that the libc code for memset() can
saturate the memory bandwidth -- at any rate it should do better than
the copy.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This is based on tests/gem_partial_pwrite_pread which aims to detect
incoherency between CPU reads and writes to a bo whilst using it as a
source and target for GPU writes.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Fixes build error:
"flip_test.c", line 180: improper pointer/integer combination: op "="
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We share these suckers, hence the fd-local libdrn instance does not
have full control over the lifecycle of the object. Prevents the tests
from blowing up with
[drm:i915_gem_mmap_gtt] *ERROR* Attempting to mmap a purgeable buffer
and similar things.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With the option '-r', the testdisplay could paint a 2-D bar code(QR
bar code) on the screen. The word "pass" is hiden in the bar code
image. Further more, with this option, testdisplay will wait until a
system signal 'SIGUSR1' coming after each mode setting. This function
is for another program to control testdisplay.
danvet: Fix up the missing static.
Signed-off-by: Yi Sun <yi.sun@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This will need to get modified when the ioctl expands, and so is only
here for reference/to make Daniel happy.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
By adding another testcase that follows up with a gpu read. This
checks whether the kernel properly tracks the pending write and
doesn't lose it (or sync up to the wrong seqno).
For some odd reason only the cpu mmap variant blows up, the gtt one
works here. I need to look into that some more.
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Due to the way we calculate the workload by doubling it each time we
might end up with almost twice as much as we want. Hence increase our
fudge by 1.5 to account for that.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50666
Daniel Vetter