Bug 1648 - R200 SWTCL path doesn't do projtex right
Summary: R200 SWTCL path doesn't do projtex right
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/r200 (show other bugs)
Version: git
Hardware: x86 (IA32) FreeBSD
: high normal
Assignee: Eric Anholt
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-10-15 20:37 UTC by Eric Anholt
Modified: 2009-08-24 12:22 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments
fixes this projtex problem for me; needs cleanup and maybe optimization (1.91 KB, patch)
2005-01-01 19:13 UTC, Andreas Stenglein
Details | Splinter Review
r200_projtex_fix2.diff.txt (2.33 KB, patch)
2005-01-03 13:55 UTC, Andreas Stenglein
Details | Splinter Review
slightly different projtex fix (2.05 KB, patch)
2005-01-27 08:31 UTC, Roland Scheidegger
Details | Splinter Review

Description Eric Anholt 2004-10-15 20:37:54 UTC
In the projtex demo, while the scaling of the projection is correct, the corners
are in the wrong places.  Need to fix.
Comment 1 Andreas Stenglein 2004-12-07 13:48:25 UTC
I discovered that projected textures work well
on radeon / r200 only if you send the w-coord to the card.
-> tiny vertex format isn't allowed for projtex!

The old template based swtcl code (which is still
used by radeon driver) worked that way:
tiny vertex format isn't used when texturing.

The new "t_vertex" code emits the w-coord only if
its really necessary: it prefers a "tiny" vertex format.
You could try to just always disable that tiny vertex
format in r200ChooseVertexState().
Comment 2 Andreas Stenglein 2005-01-01 19:13:58 UTC
Created attachment 1609 [details] [review]
fixes this projtex problem for me; needs cleanup and maybe optimization

please test.
feel free to cleanup/optimize/commit

Question:
Do we need w component for specular color? (the old code used the NOTEX_VERTEX
format for that) If not, cut that piece out of the patch.


unfortunately the glut menues are broken on r200 atm., but thats another
problem...
Comment 3 Andreas Stenglein 2005-01-03 13:55:52 UTC
Created attachment 1625 [details] [review]
r200_projtex_fix2.diff.txt

+ cleanup
+ possible fixes for points and transition swtnl<->hwtcl

(when testing make sure to test the sw-tcl case...)
Comment 4 Roland Scheidegger 2005-01-27 08:31:55 UTC
Created attachment 1759 [details] [review]
slightly different projtex fix

new version of the fix, which eliminates the additional statechange.
I'm not really sure this is sufficient & correct, but it works for projtex.
Some of the vte / vap combinations look a little odd, though maybe it wouldn't
if I'd know what those registers actually do...
Comment 5 Andreas Stenglein 2005-02-06 10:50:09 UTC
your patch seems to work well at least for projtex.
First I thought
if (tnl->render_inputs & _TNL_BITS_TEX_ANY)
might not be up to date, but at least in projtex it seems so.

Someone here to try this patch with other programs that make use of projtex ?
Comment 6 Roland Scheidegger 2005-02-10 10:31:42 UTC
(In reply to comment #5)
> First I thought
> if (tnl->render_inputs & _TNL_BITS_TEX_ANY)
> might not be up to date, but at least in projtex it seems so.
Thought that too first, but then I guessed if _TNL_BITS_TEX_ANY wouldn't be up
to date, it would not work correctly at all, since the code would incorrectly
select the tiny vertex format in cases where it shouldn't.
Applied to cvs.
Comment 7 Adam Jackson 2009-08-24 12:22:47 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.