GitLab

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Using for diagnosing some mysterious slowdowns. Should include a variant
for basic benchmarking...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Just a simple program to light up all detected outputs at their native
mode and respond to hotplug events.

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.

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 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.

Did this while trying to debug the Ubuntu DRI1+compiz issue.  Didn't succeed
in filling the ring.

This caught a bug with get_user_pages usage in the kernel, which would
result in zeroes being read out of the object when faulting in a new page.