Age | Commit message (Collapse) | Author | Files | Lines |
|
Upload a texture with random data, use it in rendering, and attempt to read
the texture data back with glGetTexImage.
This catches yet another r300+bufmgr regression that was found via Sauerbraten.
Signed-off-by: Nicolai Haehnle <nhaehnle@gmail.com>
|
|
This exceedingly silly bug caused false negatives in the test results...
Signed-off-by: Nicolai Haehnle <nhaehnle@gmail.com>
|
|
|
|
This catches issues with offset handling that were missed by the original path
that copied the whole teximage at once.
|
|
This patch fixes a few issues with piglet on Cygwin/X (which uses Mesa
for OpenGL):
1) Cygwin requires that all dependencies be explicitly passed in
dependency order during linking. This means that static libraries must
precede the shared libraries on which they depend.
2) Cygwin defines log2 as a macro instead of a function.
3) Cygwin doesn't provide lspci(8).
|
|
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
|
|
Reveals problems on i965 accelerated copytexsubimage when using i915 code.
|
|
|
|
|
|
|
|
Old implementation of r300 driver fails this test.
|
|
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.
|
|
Very basic test of
- ARB_depth_texture
- ARB_shadow
- ARB_shadow_ambient
- EXT_shadow_funcs
|
|
Relaxed version of texturing/cubemap, intended to watch for major cubemap
regressions until we can figure out how to pass the texturing/cubemap test.
|
|
|
|
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.
|
|
|
|
This test has seen only limited testing. The GM945 driver fails in the
expected way from code inspection. More concerning is that Mesa software
appears to select a mipmap one level smaller than it should.
|