Also, api_speed.py does not work.

Which driver are you using?  Most of the tests you list work fine for me with software rendering.  I'm committing a few minor fixes for vptest1.c and jkrahntest.c

Note that many of the programs in the tests/ directory are hacks and aren't actively maintained.  They're not included in the Mesa releases either.  I'm not going to spend too much time on them.

(In reply to comment #2)
> Which driver are you using?  Most of the tests you list work fine for me with
> software rendering.  I'm committing a few minor fixes for vptest1.c and
> jkrahntest.c

They works fine with softare rendering indeed. All them segfaults with r300 driver from mesa 7.4. Some of them segfault with the r300 driver (from master or radeon-rewrite, e.g. shader_api), other works (but they start slowly than sw render), other lockup my system (e.g. progs/tests/random).

Backtrace of shader_api using r300 driver from radeon-rewrite (similar backtrace with r300 from master):

#0  0x00000000 in ?? ()
#1  0x08068590 in test_uniform_size_type1 (
    glslType=0xbf899078 "#version 120\nuniform float m[60];\nvoid main() { gl_Position[0] = m[59]; }\n", glType=5126, el=0x807d648 "")
    at shader_api.c:121
#2  0x080687c6 in test_uniform_size_type () at shader_api.c:139
#3  0x08067685 in run_test (name=<value optimized out>, callback=0x8068790 <test_uniform_size_type>) at shader_api.c:317
#4  0x080676e0 in main (argc=380536, argv=0xb7fc1000) at shader_api.c:328

(In reply to comment #3)
> Backtrace of shader_api using r300 driver from radeon-rewrite (similar
> backtrace with r300 from master):
I think this is expected since this test doesn't check if glsl is supported (it's not with r300 driver) before using the glsl functions.

With swrast from current master all segfaults are gone, however:

api_speed.py still does not work

vptest1 shows a:
glGetError = 1282

With r300 driver from master, there are also other problems:

fbotest1 segfaults:
[Thread debugging using libthread_db enabled]
[New Thread 0xb79deb40 (LWP 4549)]
GL_EXT_framebuffer_object not found!
GL_RENDERER = Mesa DRI R300 20060815 x86/MMX/SSE2 TCL

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb79deb40 (LWP 4549)]
0x00000000 in ?? ()
(gdb) bt
#0  0x00000000 in ?? ()
#1  0xb7c56775 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#2  0x08067b11 in _start () at ../sysdeps/i386/elf/start.S:119


random : lockups (already reported at https://bugs.freedesktop.org/show_bug.cgi?id=21559)

rubberband about 8/10 of the times show an empty window (i.e. the window shows the content under the window itself), 2/10 works fine


quads segfaults:
[Thread debugging using libthread_db enabled]
[New Thread 0xb7b86b40 (LWP 4540)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7b86b40 (LWP 4540)]
0x00000000 in ?? ()
(gdb) bt
#0  0x00000000 in ?? ()
#1  0xb7dfe775 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#2  0x08067a41 in _start () at ../sysdeps/i386/elf/start.S:119

"random" lockups and "rubberband" behaviour are fixed now.

Mass version move, cvs -> git

Do these problems still exist in current Git master?

Note that many of the progs/ do not properly deal with missing extensions and might crash due to that. That's hardly the driver's fault.

(In reply to comment #8)
> Do these problems still exist in current Git master?

All r300 related problems are fixed now.

> Note that many of the progs/ do not properly deal with missing extensions and
> might crash due to that. That's hardly the driver's fault.

Yes, indeed the bug was originally filed against demos.

Remaining problems:

fbotest1 segfaults when fbo is missing:
GL_EXT_framebuffer_object not found!
GL_RENDERER = Mesa DRI R300 (RV530 71C5) 20090101 x86/MMX/SSE2 TCL
Segmentation fault

api_speed.py does not work

I've restored the disabled exit() call in fbotest1.c so that should no longer segfault.

As for api_speed.c, it's old and doesn't compile any more so just ignore it.

(In reply to comment #10)
> I've restored the disabled exit() call in fbotest1.c so that should no longer
> segfault.
> 
> As for api_speed.c, it's old and doesn't compile any more so just ignore it.
> 

OK, closing.

> As for api_speed.c, it's old and doesn't compile any more so just ignore it.

What about removing the execute bit from api_speed.py , just to make sure no one try to run it?