Incorrect use of GL_ARB_vertex_progam in celestia 1.4.1

Report bugs, bug fixes and workarounds here.
Topic author
chrisjr
Posts: 12
Joined: 26.08.2006
With us: 18 years 2 months
Location: UK

Incorrect use of GL_ARB_vertex_progam in celestia 1.4.1

Post #1by chrisjr » 05.09.2006, 20:20

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."

Avatar
dirkpitt
Developer
Posts: 674
Joined: 24.10.2004
With us: 20 years

Post #2by dirkpitt » 05.09.2006, 22:26

I wonder if this could lead to a fix for the infamous "Radeon 9000/9200 crash".

Topic author
chrisjr
Posts: 12
Joined: 26.08.2006
With us: 18 years 2 months
Location: UK

Post #3by chrisjr » 05.09.2006, 22:44

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.

mczak
Posts: 3
Joined: 31.08.2006
With us: 18 years 2 months

Post #4by mczak » 06.09.2006, 12:51

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?

Topic author
chrisjr
Posts: 12
Joined: 26.08.2006
With us: 18 years 2 months
Location: UK

Post #5by chrisjr » 06.09.2006, 20:56

Yes, that patch fixed my ring-shadow problem.
Thanks.

Avatar
dirkpitt
Developer
Posts: 674
Joined: 24.10.2004
With us: 20 years

Post #6by dirkpitt » 06.09.2006, 22:58

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.

mczak
Posts: 3
Joined: 31.08.2006
With us: 18 years 2 months

Post #7by mczak » 07.09.2006, 10:32

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).

Avatar
dirkpitt
Developer
Posts: 674
Joined: 24.10.2004
With us: 20 years

Post #8by dirkpitt » 21.09.2006, 14:26

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.

chris
Site Admin
Posts: 4211
Joined: 28.01.2002
With us: 22 years 9 months
Location: Seattle, Washington, USA

Post #9by chris » 21.09.2006, 16:14

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

Avatar
dirkpitt
Developer
Posts: 674
Joined: 24.10.2004
With us: 20 years

Post #10by dirkpitt » 23.09.2006, 05:35

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.


Return to “Bugs”