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’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.
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.
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.
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.
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) ?
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 ). Anyway, maybe these new ones fix your problems ( assuming they are driver bugs ).
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”) ?
Originally posted by Ysaneya:
[b]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.[/b]
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.
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
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.
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 . See issue (3) in the spec ( “Operations not subsumed by vertex programs” ).
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.
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 ?
>>>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).]