line-flat-clip-color: test flat-shaded line clipping color

This exercises a bug found in Mesa with softpipe, llvmpipe and swrast

Reviewed-by: José Fonseca <jfonseca@vmware.com>
Add test to verify interpolation at sample position

ARB_sample_shading extension says:
 "When the sample shading fraction is 1.0, a separate set of colors
  and other associated data are evaluated for each sample, each set
  of values are evaluated at the sample location."

Test passes on intel hardware with mesa patch: 'i965: Use sample
barycentric coordinates with per sample shading'.

Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Add test to verify 'centroid' qualifier is ignored in case of persample shading

Here is what it tests:
Enable sample shading for the whole fragment shader using OpenGL API
glEnable(GL_SAMPLE_SHADING);
glMinSampleShading(1.0);

fragment shader:
centroid in vec4 b;
main()
{
  ...
}

Variable 'b' should be interpolated at sample's location.

V2: Use just one 'in' variable with the 'centroid' qualifier.
Another test already covers the interpolation of 'in' variable
without any 'qualifier'. This change also captures the mesa bug
reported on i965 driver:
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73915

Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
framework/dmesg: Adds a new module for dmesg

This modules implements two classes and a helper function. The two
classes are both dmesg wrapper classes, one, PosixDmesg is used on posix
systems when requested to actually do checks on dmesg. The second class,
DummyDmesg, is used to reduce code complexity by providing dummy
versions of the methods in PosixDmesg. This means that we don't need
separate code paths for Posix systems wanting to check dmesg, Posix
systems not wanting to check dmesg, and non-posix systems which lack
dmesg.

Beyond reducing complexity this module also gives better isolation,
dmesg is only used in Test.execute(), no where else. Additional classes
don't need to worry about dmesg that way, it's just available.

v2: - Remove unnecessary assert from PosixDmesg.update_result()
    - simplify replace helper in PoixDmesg.update_result()
    - replace try/except with if check
    - Change PosixDmesg.update_dmesg() to work even if dmesg 'wraps'
v3: - Try/Except assignment of PosixDmesg._last_message in update_dmesg()
    - Set the dmesg levels the same as the previous implementation
    - Change PosixDmesg into LinuxDmesg and enforce that dmesg has
      timestamps

Signed-off-by: Dylan Baker <baker.dylan.c@gmail.com>
Adds unit tests for the dmesg module

This adds a few tests for the dmesg class.

It also adds a test hook into core.Test. This is a little ugly, but I
just couldn't come up with any other solution that didn't involve
making the dmesg code more invasive or harder to read.

v2: - Adds tests to simulate dmesg 'wrapping'
v3: - Replace assert with nose.test assert helpers. These have the
      advantage of providing the option to add a message explaining what
      when wrong.
    - Adds test for LinuxDmesg's enforcement of timestamps

Signed-off-by: Dylan Baker <baker.dylan.c@gmail.com>
Use the new dmesg class

This actually makes use of the new dmesg class rather than the dmesg
functions. It touches a lot of files, but almost all of these changes
are code removal rather than code addition.

Signed-off-by: Dylan Baker <baker.dylan.c@gmail.com>
piglit-run.py: Restrict dmesg to serial runs

Dmesg reporting has always been inaccurate with concurrent runs, and the
solution to concurrent runs would be to have each run take out a lock,
removing the chance that another test generated an error in dmesg while
it was running. But this effectively makes them a serial run, and at the
cost of greater code complexity. With that in mind it makes more sense
to just force --dmesg to imply -1.

Signed-off-by: Dylan Baker <baker.dylan.c@gmail.com>