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.
The error message was falsely claiming that a debugfs directory
didn't exist, when it was supposed to report that the ringbuffer
file did not exist within that directory.
Add four new tests for error the error handling cases:
- gem_bad_address - store to a bad address, should generate a protection or
page table error
- gem_bad_batch - try to execute a bad batch, should generate a protection,
invalid instruction or page table error
- gem_bad_blit - blit to an invalid location, should generated a protection
or page table error
- gem_hang - hang the GPU on an event that will never happen, test hang
detection & recovery code
The printf used to clear the screen didn't have a format string, this
adds one to avoid a compiler warning.
Signed-off-by: Eric Anholt <eric@anholt.net>
It can be a bit easier to digest the percentages with bar graphs than by
scanning continually changing numbers.
Signed-off-by: Eric Anholt <eric@anholt.net>
For a typical vsync locked application running at 60fps, sampling at just
under twice a frame doesn't seem to give very stable lists of relevent hardware
units because there are a number of units involved that may not be sampled one
second to the next.
This bumps the sample rate to 10,000 instead which is ~ 170 samples per
frame so we tend to hit all the units involved.
It also changes the report threshold to a sample count >= 1, so you don't
see as many units with a percentage of 0.
Signed-off-by: Eric Anholt <eric@anholt.net>
humans are pretty bad at reading percentages quicky; this patch adds a
histogram capability to make it more visually clear as to which lines are
big ticket items
The large object test simply tries to allocate a 128M object, pin it, then
pwrite the whole thing. This should make obvious any leaks on close or
page pointer allocation failures.
This is the case where debugfs is mounted, the dri/0 directory
exists but there's no i915_ringbuffer_info file. Point the user
toward upgrading the driver.
Right now it requires a filename on the command line, (such as
/debug/dri/0/i915_batchbuffers). We plan to make it smarter in
the future by going out and collecting all the data it needs.
Chris Wilson