GitLab

Tests SGIS_generate_mipmap versus glTexImage2D.  Catches a mesa bug with
updating GL_GENERATE_MIPMAP state without flushing.

Tests that SGIS_generate_mipmap occurs after TexSubImage.  Catches bug #17077.

This is a very basic test that creates 3D textures of varying sizes,
renders them and compares the results with expected results.

It's still quite incomplete, e.g. a test for TexSubImage and mipmapped
textures is still missing.

Test some texture redefinition scenarios: Switching between different
texture sizes & mipmapping enable/disable

This is a regression test for the recently fixed KWin corruption bug.

Perhaps it'll help someone else, some day.

This test currently fails on R500.

Reveals problems on i965 accelerated copytexsubimage when using i915 code.

Current r500 fragment program implementation fails this test.

Old implementation of r300 driver fails this test.

Since 1D textures are really one-dimensional objects, the T texture coordinate
must be ignored completely. This is not the case for the r300 driver, which
simulates 1D textures via 2D textures, with "interesting" filtering results
depending on the TEXTURE_WRAP_T texture parameter.

Quote from his description:
In fp-fragment-position.c the 4th fragment program uses
fragment.position to index a 2D texture.  Since all the fragment
positions are integers > 1 the default GL_REPEAT texture wrap mode
converts all the texcoords to zero.  Actually, though, that's not true.
  Because of the way texcoords are processed, the fractional part of the
coords is not always zero but some epsilon value.  That caused us to
sample with different texcoords than the test expects.

I think it's more useful to scale the fragment position to put it into
the nominal [0,1] range to get a color that varies per pixel.

My patch does that, and adds some assorted comments to the code.

---

In fp-list-mask.c and texrect-many.c and texdepth.c I added GLUT_ALPHA
to glutInitDisplayMode().  We had failures because GLUT was sometimes
choosing visuals without an alpha channel.

---
<
The logic in vp-bad-program.c was incorrect.  When glProgramString() is
called with an invalid program, we raise an error, but the previous
program (if any) stays in effect.  So the subsequent glBegin() would
never raise an error.  The proper way to check for glBegin raising an
error with an invalid program is to simply bind a non-existant program.

I made the same fix in glean a while ago.

There's still some other failures I need to look into (and I'm not sure
where the faults are) but I need to move onto some other things now.

fp-generic executes arbitrary fragment programs, testing a single pixel value.
It should be helpful in writing regression tests for shader compilers.

This makes the test work again after a long time of brokenness. The original
test in Mesa uses a different projection matrix setup, which is why it doesn't
need that initial call to Reshape.

Very basic test of
 - ARB_depth_texture
 - ARB_shadow
 - ARB_shadow_ambient
 - EXT_shadow_funcs

The results files can get rather huge when tests fail, because tests like
glean/blendFunc output a lot of debugging data, which we all record.

Now, we generate an additional .../summary file, in which the info string
is simply truncated. Pretty stupid, but it should give enough info to get
an idea of the rough kind of failure.

Add a new option for piglit-summary-html.py, to choose between full or
abbreviated info when both are present.

This tests against a particular problem of the r300 driver, related to a
readcache coherency problem.

Note that while I had first found this problem via glean/texCube, the fact
that I did find the problem there was pure chance, because the bug depends
on the exact coordinate of the glReadPixels call (and thus on the window
position). This new test loops through many coordinates to make sure the
window coordinates are irrelevant.

Relaxed version of texturing/cubemap, intended to watch for major cubemap
regressions until we can figure out how to pass the texturing/cubemap test.

ARB_fragment_program only interacts with, but does not depend on
EXT_fog_coord, so simply skip the fog-related tests when the latter is
not present.

This test uses the maximum number of texture_rectangle textures simultaneously.

The current R300 driver fails this test because it generates unnecessary
texture indirections for rectangle textures.

The 'texturing' group was aliased to 'bugs' before, trivial change.