PDA

View Full Version : ARB_vp issue on ATI



V-man
07-14-2003, 09:22 PM
I'm surprised that this ultra simple code doesn't work on ATI cards. When I render a quad and I rotate it, sometimes half of it doesn't render.

PARAM mvp[4]={state.matrix.mvp};
ATTRIB iPos=vertex.position;
OUTPUT oPos=result.position;

DP4 r0.x, iPos, mvp[0];
DP4 r0.y, iPos, mvp[1];
DP4 r0.z, iPos, mvp[2];
DP4 r0.w, iPos, mvp[3];
RCP temp.w, r0.w;
MUL r0, r0, temp.w;
MOV oPos, r0;

You can output any color you want.

That's not the only problem I'm having. All my vp's that *worked* on NVidia are screwing up on ATI (9500 with catalyst 3.5) with no error messages.

At least my fragment program stuff is working.

Are other people experiencing such issues on ATI?

Relic
07-14-2003, 09:57 PM
How do you feed it?
Make sure you didn't hit a different vertex attribute aliasing implementation dependend behaviour.
Use the new vertex attribute commands throughout to be on the safe side.

Ostsol
07-14-2003, 10:02 PM
Well. . . I don't see your temporary registers declared anywhere. . .

Asgard
07-14-2003, 10:45 PM
I'm experiencing similar problems with some shaders. All of them run fine on NVIDIA hardware, but on ATI hardware I sometimes get wrong colors, incorrect texturing (some triangles just stay white), and other strange behavior even though no error is reported...and I exclusively use generic vertex attributes. Really strange.
Unfortunately, I haven't had time to debug this in detail and make some bug reports to ATI, if necessary.

Mazy
07-15-2003, 12:24 AM
Why are you dividing thre result with w? just output r0 of you want a simple iPos * mvp?

V-man
07-15-2003, 05:57 AM
Originally posted by Relic:
How do you feed it?
Make sure you didn't hit a different vertex attribute aliasing implementation dependend behaviour.
Use the new vertex attribute commands throughout to be on the safe side.

I have this demo that uses glCallList. Look inside RenderScene().
http://www.geocities.com/vmelkon/verybasicvp.html

On NVidia, the ARB, NV, NV2 work just fine.
On ATI, the ARB version gives a completely blue objects. Sometimes multicolor (red, green, blue. It depends on which object you select (sphere, cube, ...)

I have one other code that does "mix" attributes with the old style. I'll fix it.

V-man
07-15-2003, 06:01 AM
Originally posted by Mazy:
Why are you dividing thre result with w? just output r0 of you want a simple iPos * mvp?

Cause I need it. The code I posted above is not complete. I just posted that part because I think that's the issue. If I do it like you said, then there is no problem.

Ysaneya
07-15-2003, 08:26 AM
Hum, it might be that ATIs are dividing the xyz by w _after_ the VP, and not NVidia's ? Did you try to set r0.w to 1 and see how it behaves ? Or what about clamping issues (ATIs have more precision) ?

Y.

titan
07-15-2003, 08:30 AM
I've had a couple problems with ARB_vertex_program on ATI cards (8500/9500) as well (3.5 drivers). Different problems for the two generations though.

On the bright side ATI's vp support is much better than SiS's! SiS gives errors if you use option invarient. http://www.opengl.org/discussion_boards/ubb/frown.gif

PH
07-15-2003, 08:50 AM
I haven't had any problems myself but I just noticed that ATI has released Catalyst 3.6 ( today it seems, downloading right now ). I have a feeling they contain the glslang ( as the specs were just released http://www.opengl.org/discussion_boards/ubb/smile.gif ). Anyway, maybe these new ones fix your problems ( assuming they are driver bugs ).

vincoof
07-15-2003, 10:12 AM
Originally posted by Ysaneya:
Hum, it might be that ATIs are dividing the xyz by w _after_ the VP, and not NVidia's ? Did you try to set r0.w to 1 and see how it behaves ?

The result of the current VP is that W is always set to 1 (since divided by himself, unless it was zero obviously). Or do you mean that he might "force" the W coordinate after the division (Something like "mov r0.w, 1") ?

Ysaneya
07-15-2003, 10:46 AM
After the division, obviously. Ie. just just before the last instruction.

Y.

V-man
07-15-2003, 12:10 PM
Originally posted by Ysaneya:
Hum, it might be that ATIs are dividing the xyz by w _after_ the VP, and not NVidia's ? Did you try to set r0.w to 1 and see how it behaves ? Or what about clamping issues (ATIs have more precision) ?

Y.

Yes I tried it, but it doesn't help. The screen looks totally screwed up because polygons appear disseaper in all sorts of positions. Some of them look like they are rendered from some infinite corner to another infinite corner.

I guess I should try Cat 3.6.

V-man
07-16-2003, 06:48 AM
No, looks like 3.6 doesn't make a difference.
Could be a hw bug in the R300 line.

As for the link I posted above, that too still doesn't work and there are no error messages given.

As for another bug I saw (screen corruption), looks like that is not fixed as well.

You can have a look at some screen shots.
Warning: this site takes while to load (9 large pics).
ONLY visit it if you have a ATI hardware and can comment on the bugs, because this site has limited bandwidth.
http://www.geocities.com/vmelkon/atibugs.html

Thanks

zeckensack
07-16-2003, 06:55 AM
Originally posted by V-man:
RCP temp.w, r0.w;
MUL r0, r0, temp.w;
MOV oPos, r0;Please be aware that this breaks perspective correction (most obvious on texture lookups).

That doesn't seem to be the cause for your bugs but it's worth mentioning.

PH
07-16-2003, 07:45 AM
I tried your vertex program ( after declaring the temp variables ) and it works as long at the geometry doesn't "intersect" the near plane. GL handles the division by w even in vertex program mode and clipping is done before the division by w.

I don't think this is a driver or hardware issue but rather an application bug http://www.opengl.org/discussion_boards/ubb/smile.gif. See issue (3) in the spec ( "Operations not subsumed by vertex programs" ).

ymxie
07-16-2003, 08:31 AM
Dear V-man ,
my display adapter is ATI 9700 pro with catalyst 3.6.

PARAM mvp[4]={state.matrix.mvp};
ATTRIB iPos=vertex.position;
OUTPUT oPos=result.position;
TEMP r0;
TEMP temp;
DP4 r0.x, iPos, mvp[0];
DP4 r0.y, iPos, mvp[1];
DP4 r0.z, iPos, mvp[2];
DP4 r0.w, iPos, mvp[3];
RCP temp.w, r0.w;
MUL r0, r0, temp.w;
MOV oPos, r0;

It runs well in my computer. you can use VR Shader man to solve you problem, since it can do real-time modification on the shader code. If you need it, I can send you by email.

vincoof
07-16-2003, 10:31 AM
I've tried to divide the w component into the vertex program and it works fine on my Radeon8500 with latest drivers (the ones released yersterday). But when I enable vertex buffer objects, the system freezes (reboot needed) whenever the 3D model goes behind the near plane. Anyway, be it with or without vertex buffer objects, it does NOT freeze when the perspective division is NOT performed in the vertex program, and it does NOT freeze as long as the 3D model is rendered ENTIRELY in the field of view.

So, my question is : do you use vertex buffer objects ?

CatAtWork
07-16-2003, 06:07 PM
No bugs for me.

Windows XP, Driver version: 6.14.1.6307
(Can't remember what Catalyst I installed last.)

SSE2 (P4)

Radeon 9700 Pro.

V-man
07-16-2003, 06:32 PM
>>>I don't think this is a driver or hardware issue but rather an application bug . See issue (3) in the spec ( "Operations not subsumed by vertex programs" ).<<<

I know that but I think this is not an issue.

Nope, I don't use VBO. I don't use glVertexAttrib calls.

It looks like the problem occurs only when the geometry intersects the near, but no problem with the far and the rest.

-I tried using glOrtho, but there were no problems.
-I tried computing the perspective matrix myself, and I uploaded with glLoadMatrix, the problem remains.
-I tried computing the ortho matrix myself, no problems.
-I computed my own MVP matrix and uploaded using program environment parameters, and at the same time I put a ortho matrix on the projection. The problem remained.


Plus, the 9500 I have is a cut back 9700. It has 4 of the pipes disabled.

I'm out of ideas.

Are you guys able to run this one OK http://www.geocities.com/vmelkon/verybasicvp.html
(PS: this is a different issue! be sure to turn on ARB_vp and observe the result. Does it look like the same as the fixed pipeline?)

Could it be my card is damaged?

[This message has been edited by V-man (edited 07-16-2003).]

V-man
07-16-2003, 07:48 PM
OK, I was able to fix the very basic vp thing.

It looks like

PARAM AmbientColor0=state.lightprod[0].ambient;
PARAM DiffuseColor0=state.lightprod[0].diffuse;
PARAM SpecularColor0=state.lightprod[0].specular;
PARAM AmbientColor1=state.lightprod[1].ambient;
PARAM DiffuseColor1=state.lightprod[1].diffuse;
PARAM SpecularColor1=state.lightprod[1].specular;

contain invalid values, so I just calculated them myself in the VP.

Too many obvious bugs if you ask me.

vincoof
07-17-2003, 12:59 AM
On my Radeon8500, your program does display a flat blue model with ARB_vp, whereas the model is red and shaded by lighting with fixed function.

V-man
07-17-2003, 05:44 AM
Originally posted by vincoof:
On my Radeon8500, your program does display a flat blue model with ARB_vp, whereas the model is red and shaded by lighting with fixed function.

Yes, that's the cause and looks like it may be widespread.

ATI doesn't seem strong in quality control. This is laughable.

zeckensack
07-17-2003, 07:15 AM
Originally posted by V-man:
OK, I was able to fix the very basic vp thing.

It looks like

PARAM AmbientColor0=state.lightprod[0].ambient;
PARAM DiffuseColor0=state.lightprod[0].diffuse;
PARAM SpecularColor0=state.lightprod[0].specular;
PARAM AmbientColor1=state.lightprod[1].ambient;
PARAM DiffuseColor1=state.lightprod[1].diffuse;
PARAM SpecularColor1=state.lightprod[1].specular;

contain invalid values, so I just calculated them myself in the VP.

Too many obvious bugs if you ask me.

Were the corresponding lights enabled? Was lighting enabled? Just a wild guess ...
This may be an issue of state not propagating through the pipe if the fixed function controls are disabled. Just like fixed function fog and NV_register_combiners.

V-man
07-17-2003, 12:36 PM
Originally posted by zeckensack:
Were the corresponding lights enabled? Was lighting enabled? Just a wild guess ...
This may be an issue of state not propagating through the pipe if the fixed function controls are disabled. Just like fixed function fog and NV_register_combiners.

Yes and yes. You can have a look at the code if you wish.

But I'm not sure if it's necessary to have the lights and lighting enabled. I don't know the spec that well at this point.

bumphoney
07-22-2003, 05:22 PM
Originally posted by V-man:
Are you guys able to run this one OK http://www.geocities.com/vmelkon/verybasicvp.html
(PS: this is a different issue! be sure to turn on ARB_vp and observe the result. Does it look like the same as the fixed pipeline?)


Runs just fine, ARB_vp and fixed pipeline look the same on Radeon 9000Pro with Catalyst 3.5.

[This message has been edited by bumphoney (edited 07-22-2003).]

vince
07-23-2003, 06:27 AM
Originally posted by V-man:
I have this demo that uses glCallList. Look inside RenderScene().
http://www.geocities.com/vmelkon/verybasicvp.html

On NVidia, the ARB, NV, NV2 work just fine.
On ATI, the ARB version gives a completely blue objects. Sometimes multicolor (red, green, blue. It depends on which object you select (sphere, cube, ...)



I had similar problems and I discussed it with ATI tech support. They understood the problem and the even told me they managed to fix it. It was about a month ago. They told me the fix would be in their next driver release. Not sur if it's there yet...

vince
07-23-2003, 09:20 AM
I juste installed ATI's latest driver. It's significantly worst than before...