Bug 6727 - Implement Extended Swizzle (OPCODE_SWZ) for vertex programs
Implement Extended Swizzle (OPCODE_SWZ) for vertex programs
Status: RESOLVED FIXED
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/r300
git
x86 (IA32) Linux (All)
: high normal
Assigned To: Default DRI bug account
: patch
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-04-25 01:00 UTC by Tilman Sauerbeck
Modified: 2009-08-24 12:23 UTC (History)
0 users

See Also:


Attachments
Patch (973 bytes, patch)
2006-04-25 01:00 UTC, Tilman Sauerbeck
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Tilman Sauerbeck 2006-04-25 01:00:26 UTC
Attached patch implements support for the Extended Swizzle vertex program
opcode. Tested with progs/vp/swz2.txt and different swizzle components.
Comment 1 Tilman Sauerbeck 2006-04-25 01:00:50 UTC
Created attachment 5457 [details] [review]
Patch
Comment 2 Brian Paul 2006-04-25 02:33:35 UTC
applied to cvs.
Comment 3 Roland Scheidegger 2006-04-26 02:57:01 UTC
Any reason why it uses OP_MAD (or OP_MAD_2) instead of OP_ADD? Maybe it never
makes a difference, but even then I would think it's a better strategy to not
force that multiplier to get used. (Not to mention that a architecture-dependant
optimizer should always be able to optimize that whole instruction away on r300.)
Comment 4 Tilman Sauerbeck 2006-04-26 03:19:30 UTC
OPCODE_ADD uses MAD/MAD_2, too, so I assumed I should use them for OPCODE_SWZ,
too (r300_vertexprog.c:656).
Comment 5 Roland Scheidegger 2006-04-26 11:28:14 UTC
ah right, some of the things I don't quite understand why - mul is also handled
as MAD or MAD_2, and at least on r200 fglrx doesn't do that neither. The OP_ADD
is used however currently (for the move and move-like stuff if there are
different sources).
Comment 6 ajax at nwnk dot net 2009-08-24 12:23:53 UTC
Mass version move, cvs -> git