Bug 2766

Summary:	texgen GL_SPHERE_MAP should not cause a tcl fallback
Product:	Mesa	Reporter:	Roland Scheidegger <sroland>
Component:	Drivers/DRI/r200	Assignee:	Default DRI bug account <dri-devel>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	high
Version:	git
Hardware:	x86 (IA32)
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:
Attachments:	proposed fix for tcl texgen

Description Roland Scheidegger 2005-03-18 19:21:35 UTC

currently, GL_SPHERE_MAP texgen causes a tcl fallback, which should not be
necessary (and this fallback causes lots of z fighting with for instance
tuxracer or nwn, though this is supposedly the apps fault).
The fallback is used since the results with hw tcl are wrong. Some analysis with
fglrx shows that this driver sets R200_LOCAL_VIEWER in the tcl lighting model
control with at least the simple samples/sphere app, and when hacking this into
the r200 driver (I have really no idea where and when...) this indeed fixes at
least isosurf (in reflect mode) and sphere as far as I can tell, and tuxracer
also seems to look correct. This also easily explains why sometimes the
GL_SPHERE_MAP indeed worked correctly (for instance in gloss, this sets the
GL_LIGHT_MODEL_LOCAL_VIEWER to true).
I do not really understand the lighting model nor its interaction with the r200
chip, so I have no idea how a proper fix would look like unfortunately. I guess
always setting this bit would cause errors in other places?

Comment 1 Eric Anholt 2005-05-31 17:00:18 UTC

I've turned the fallback off, since it seems GL_SPHERE_MAP should work, and
apparently works in some cases.  I've confirmed that R200_LOCAL_VIEWER did fix
texcyl (just drop it into the TCL_LIGHT_MODEL_CTL_0 of r200_state_init.c to
see), though reading gl specs and ati specs, I can't come up with a reason why.
 Perhaps Michel could shed some light on this?

Comment 2 Roland Scheidegger 2005-09-28 15:54:47 UTC

(In reply to comment #1)
> I've turned the fallback off, since it seems GL_SPHERE_MAP should work, and
> apparently works in some cases.  I've confirmed that R200_LOCAL_VIEWER did fix
> texcyl (just drop it into the TCL_LIGHT_MODEL_CTL_0 of r200_state_init.c to
> see), though reading gl specs and ati specs, I can't come up with a reason why.
I think this is a common hardware limitation, Direct3d has a caps bit for
exactly that (D3DVTXPCAPS_NO_TEXGEN_NONLOCALVIEWER, though it needs to be said
the radeons do not set it). I believe the reason is that some calculations
related to eye-coordinate transforms are shared between lighting and texgen.
However, I'm wondering is it possible (and if not, what sort of lights will
break?) to always set R200_LOCAL_VIEWER if texgen is enabled? It seems it's
necessary to set _mesa_allow_light_in_model to 0 (same as fog already does) in
that case, with that set lighting still seems to be correct if R200_LOCAL_VIEWER
is always enabled, but the math behind it escapes me a bit.
I think it would be needed for all texgen modes, not just GL_SPHERE_MAP, with
probably the exception of the GL_OBJECT_LINEAR mode, on both r100 and r200.
I'll code that up if someone else thinks this might be the correct thing to do :-).

Comment 3 Roland Scheidegger 2005-09-30 13:59:36 UTC

Created attachment 3445 [details] [review]
proposed fix for tcl texgen

proposed fix. It just puts the chip in LOCAL_VIEWER mode whenever texgen needs
eye coords - this seems to be what fglrx is doing (though I'm not sure, maybe
it does more than that). This may break specular highlights if at the same time
lighting is enabled and the light model is not set to local viewer. I'm not
sure it's worth worrying about that.
I've not yet confirmed it's necessary for all those 4 texgen modes, only for
GL_SPHERE_MAP. But if it's necessary for all of them then the radeon driver
would need the same patch probably.

Comment 4 Roland Scheidegger 2005-10-05 15:47:14 UTC

fixed in cvs - the only change to the last patch is that GL_EYE_LINEAR mode does
not seem to need the R200_LOCAL_VIEWER bit (as per fglrx).

Comment 5 Adam Jackson 2009-08-24 12:23:07 UTC

Mass version move, cvs -> git

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.