Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=8060
------- Additional Comments From [EMAIL PROTECTED] 2006-09-05 12:45 -------
(In reply to comment #32)
> I can confirm that the "flicking shadow" problem only happens if I cold-boot
> my
> machine. I.e. once I apply the fix (I run celestia with GL_ARB_vertex_program
> ignored), the fix survives a warm boot.
>
> The recent change to r200_state_init.c has not helped either the flickering,
> or
> the mis-rendering of Warcraft's login screen.
I'd have been surprised if it would have helped...
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."
> Also, wine's OpenGL developer has
> managed to get this same screen to render correctly with his NVIDIA graphics
> card, so I'm thinking that there's still something going wrong in r200_dri.so.
>
> In his opinion:
> "I would recommend to only disable vertex buffer objects. The extension
> provides
> a different way to upload geometry data to the gpu. If it isn't there another
> sometimes less efficient mechanism is used. The game will still use vertex
> shaders and other 3d effects.
>
> If disabling ARB_vertex_program helps as well it means that there's a bug in
> the
> use of VBOs in ARB_vertex_program."
It's quite possible there are bugs related to vertex programs in either core
Mesa or the driver code, though those weird vertex prog related queries suggests
something goes fundamentally wrong. You could compile mesa with debug options
(add -DDEBUG somewhere to your config) that would tell at least if mesa thinks
there was a user (i.e. WoW) error.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
