texelFetch: test various texture dimensions

This is the ultimate test for validating texture allocation in the driver.
texelFetch is a perfect test for it: it supports various texture targets,
NPOT textures, and mipmapping. It's also our only test for NPOT 3D mipmapped
textures. This commit adds support for testing various texture dimensions.

There are several ways to specify the range of dimensions to test, for example:

texelFetch fs sampler3D 1x129x9-98x129x9
  This runs the test with the texture width of 1, 2, 3, ... up to 98.

texelFetch fs sampler3D 1x1x1-30x30x30
  This tests all WxHxD combinations, where W,H,D is in {1,..,30}.
  This one takes a really long time, so it's not practical for all.tests, but
  the option is there. The main difference between this and tex3d-npot is that
  this also tests mipmaps and you have the option to test bigger dimensions.

The options for the last parameter are:
  WxH - test just WxHx1 (can be non-auto)
  WxHxD - test just WxHxD (can be non-auto)
  W1-W2 - start with W1x1x1 and end with W2x1x1
  W1xH1-W2xH2 - test all combinations between and including the specified
                values, and D=1
  W1xH1xD1-W2xH2xD2 - test all combinations between and including
                      the specified values

The new items in all.tests only iterate over one dimension, the other
dimensions are fixed. It should cover most cases.

Other changes:

- the space between drawn quads is changed to 1 and the mipmaps are positioned
  next to each other for more stuff to fit on the window

- the test fails if a texture with all its layers and mipmaps doesn't fit
  on the window

- v2: all memory leaks are fixed

Acked-by: Chris Forbes <chrisf@ijw.co.nz>
Merge quick-driver.tests to quick.tests

The difference between the two is 5 tests, which is pretty much nothing.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Optionally capture dmesg changes for each test and report them in a summary

The Radeon driver writes GPU page faults to dmesg and we need to know which
tests caused them.

If there is any change in dmesg during a test run, the test result is changed
as follows:
* pass -> dmesg-warn
* warn -> dmesg-warn
* fail -> dmesg-fail
Dmesg is captured before and after each test and the difference between the two
is stored in the test summary.

The piglit-run.py parameter which enables this behavior is --dmesg. It's also
recommended to use -c0.

v2: - address some of Dylan's remarks, mainly bug fixes
    - fix get_dmesg_diff

Reviewed-by: Dylan Baken <baker.dylan.c@gmail.com>
piglit-run: add -1 as an alternative to --no-concurrent

Reviewed-by: Dylan Baker <baker.dylan.c@gmail.com>
Fix out of bounds read in the AMD_performance_monitor measure test.

If the last counter returned is a 32-bit value, reading a uint64_t might
go past the end of the buffer.  So, delay reading the 64-bit value until
we know the type is 64-bit.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
status_tests.py: Tests Summary.py's assignment of statues

This code tests the way Summary.py assigns statuses to tests.
Specifically it tests regressions, fixes, changes, and problems,
assuring that only the correct permutations of these tests are added to
the list.

It uses python's builtin unittest framework, and a magical decorator to
limit code duplication.

This already reveals 8 problems in the current implementation
piglit-framework-tests.py: Adds a utility for running piglit unit tests

This program gives the option to run the tests. These tests are meant to
test internal features of the piglit framework. Currently there are only
tests for the summary module's handling of regressions, fixes, changes,
and problems.