| Summary: | Implement Extended Swizzle (OPCODE_SWZ) for vertex programs | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Tilman Sauerbeck <tilman> |
| Component: | Drivers/DRI/r300 | Assignee: | Default DRI bug account <dri-devel> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | high | Keywords: | patch |
| Version: | git | ||
| Hardware: | x86 (IA32) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | Patch | ||
|
Description
Tilman Sauerbeck
2006-04-25 01:00:26 UTC
Created attachment 5457 [details] [review] Patch applied to cvs. 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.) OPCODE_ADD uses MAD/MAD_2, too, so I assumed I should use them for OPCODE_SWZ, too (r300_vertexprog.c:656). 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). 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.