Page 1 of 1
Incorrect use of GL_ARB_vertex_progam in celestia 1.4.1
Posted: 05.09.2006, 20:20
by chrisjr
Hi,
I was chasing a bug that only appeared in celestia 1.4.1 after a cold reboot, when GL_ARB_vertex_program was enabled. I forwarded the bug to the Linux DRI developers (Radeon R200), who replied:
I can confirm the celestia problem - the shadow on the ring doesn't flicker
here, but is just missing instead though. However, this is actually not our bug,
this is a celestia bug. Celestia's shader do not properly initialize the output
registers, so the q tex coordinate ends up uninitialized. This is an important
difference to NV_vertex_program, where you do not need to initialize the output
(and temp) regs. In particular, in rings_vp.arb only s and t (x,y) coords are
written to tex coord sets 0 and 1, r and q (z,w) are not touched. (Other shaders
have the same problem, but it doesn't seem to cause problems). Apparently, if
you use the multitexturing path, that coordinate is written (even if it doesn't
really work), and it seems that this state even survives a reboot.
Here's the warning from the ARB_vp extension:
"If conventional OpenGL texture mapping operations are performed, a
program should always write to the "w" coordinate of any texture
coordinates result registers it needs to use. Conventional OpenGL
texture accesses always use projective texture coordinates (e.g.,
s/q, t/q, r/q), even though q is almost always 1.0. An undefined q
coordinate (coming from the "w" component of the result register)
may produce undefined coordinates on the texture lookup."
Posted: 05.09.2006, 22:26
by dirkpitt
I wonder if this could lead to a fix for the infamous "Radeon 9000/9200 crash".
Posted: 05.09.2006, 22:44
by chrisjr
Well, if someone would like to give me a patch for celestia 1.4.1 then I could at least test whether the bug that I'm seeing is fixed. But ATI's own driver doesn't like my DFP monitor and so I can't test that.
Posted: 06.09.2006, 12:51
by mczak
chrisjr wrote:Well, if someone would like to give me a patch for celestia 1.4.1 then I could at least test whether the bug that I'm seeing is fixed. But ATI's own driver doesn't like my DFP monitor and so I can't test that.
Patch for the shaders (I didn't check for the shaders which are only used when fragment programs are in use, as it shouldn't matter there, unless the fragment program assumes that the 4th component is 1).
Code: Select all
--- shadowtex_arb.vp~ 2003-02-18 08:24:43.000000000 +0100
+++ shadowtex_arb.vp 2006-09-06 14:22:01.000000000 +0200
@@ -12,6 +12,7 @@
PARAM texgen_s = program.env[10];
PARAM texgen_t = program.env[11];
PARAM halfW = { 0, 0, 0, 0.5 };
+PARAM one = 1;
OUTPUT oPos = result.position;
OUTPUT oTex0 = result.texcoord[0];
OUTPUT oTex1 = result.texcoord[1];
@@ -25,10 +26,12 @@
DP4 oPos.w, mvp[3], iPos;
# Generate texture coordinates
+MOV oTex0, one;
DP4 oTex0.x, texgen_s, iPos;
DP4 oTex0.y, texgen_t, iPos;
# Generate 1D coordinates for the 'mask' texture
+MOV oTex1, one;
ADD t, lightDir, halfW;
DP4 oTex1.x, t, iPos;
MOV oTex1.y, halfW.x;
--- rings_arb.vp~ 2006-09-05 21:18:21.000000000 +0200
+++ rings_arb.vp 2006-09-06 14:23:18.000000000 +0200
@@ -47,6 +47,7 @@
# The second texture is the shadow; we need to compute the
# it from the vertex coordinate.
+MOV oTex1, one;
DP4 oTex1.x, texgen_s, iPos;
DP4 oTex1.y, texgen_t, iPos;
--- ringshadow_arb.vp~ 2006-09-05 21:02:49.000000000 +0200
+++ ringshadow_arb.vp 2006-09-06 14:39:42.000000000 +0200
@@ -14,7 +14,7 @@
PARAM ringSize = program.env[10];
PARAM rcpSunY = program.env[11];
PARAM zero = 0;
-PARAM half = 0.5;
+PARAM half = { 0.5, 0.5, 0.5, 1.0 };
OUTPUT oPos = result.position;
OUTPUT oColor = result.color;
OUTPUT oTex0 = result.texcoord[0];
@@ -48,7 +48,7 @@
# Now we have our s coordinate . . .
MOV oTex0.x, s.x;
# The t coordinate is always 0.5
-MOV oTex0.y, half;
+MOV oTex0.yzw, half;
MOV oColor, diffuse;
The one causing problems is rings_arb.vp but there is no guarantee the others can't cause trouble.
dirkpitt wrote:I wonder if this could lead to a fix for the infamous "Radeon 9000/9200 crash".
I doubt it, but what infamous crash would that be?
Posted: 06.09.2006, 20:56
by chrisjr
Yes, that patch fixed my ring-shadow problem.
Thanks.
Posted: 06.09.2006, 22:58
by dirkpitt
mczak wrote:dirkpitt wrote:I wonder if this could lead to a fix for the infamous "Radeon 9000/9200 crash".
I doubt it, but what infamous crash would that be?
On certain machines, turning on ring shadows and viewing Saturn would result in a hard crash. It was always assumed this was a driver issue of some sort - I'll see if I can get the crashing user to test with these revised vertex programs.
Posted: 07.09.2006, 10:32
by mczak
dirkpitt wrote:mczak wrote:dirkpitt wrote:I wonder if this could lead to a fix for the infamous "Radeon 9000/9200 crash".
I doubt it, but what infamous crash would that be?
On certain machines, turning on ring shadows and viewing Saturn would result in a hard crash. It was always assumed this was a driver issue of some sort - I'll see if I can get the crashing user to test with these revised vertex programs.
Until recently, the r200 dri driver didn't support vertex programs (in hardware at least). The celestia multitexture render path doesn't work correctly for the ring shadows neither (and this IS a driver bug, though actually the driver code looks correct the chip just doesn't do what we think it should do...) but I'd be somewhat surprised if that would cause gpu lockups (should just cause bogus texture coordinates in the chip).
Posted: 21.09.2006, 14:26
by dirkpitt
I went ahead and got a friend to test the patched vertex programs on a Radeon 9200 that would always crash.
Sadly, it still crashes, so the driver bug causing the crash appears to be something else. I don't know why I bothered to get my hopes up over this P.O.S. graphics chipset and its shoddily written Mac drivers.
Posted: 21.09.2006, 16:14
by chris
dirkpitt wrote:I went ahead and got a friend to test the patched vertex programs on a Radeon 9200 that would always crash.
Sadly, it still crashes, so the driver bug causing the crash appears to be something else. I don't know why I bothered to get my hopes up over this P.O.S. graphics chipset and its shoddily written Mac drivers.
Too bad . . . I was really hoping that the fix would work. You should check in the patched vertex programs anyway.
--Chris
Posted: 23.09.2006, 05:35
by dirkpitt
chris wrote:dirkpitt wrote:I went ahead and got a friend to test the patched vertex programs on a Radeon 9200 that would always crash.
Sadly, it still crashes, so the driver bug causing the crash appears to be something else. I don't know why I bothered to get my hopes up over this P.O.S. graphics chipset and its shoddily written Mac drivers.
Too bad . . . I was really hoping that the fix would work. You should check in the patched vertex programs anyway.
--Chris
Done.