the SWZ opcode is not handled correctly in mesa's tnl module (in t_vb_arbprogram.c). The results are more or less obvious wrong (for instance use the swz2.txt test case but use only x/y/z/w and not 0/1), but I can't quite see how it's supposed to work. It seems strange that in fact somtimes 3 RSW instructions are generated for a single SWZ, I'd think 2 should be sufficient. Anyway, it just plain doesn't work.
Yes. If you look at the cvp_emit_arg() function I have a comment about some failed assertions in glean. The GET_SWZ() macro returns one of six possible values: SWIZZLE_X,Y,Z,W,ZERO,ONE. But at line 849 we're assuming the value fits into two bits. The result is the rsw.rsw.swz field can be garbage (if the assertions are disabled). I tried to fix all this a while back, but never got to the bottom of it.
Created attachment 5777 [details] [review] attempt to fix swz in mesa Is there a good reason why the swz field only must be 8 bits? This patch changes it to be the same as the prog_src Swizzle field (so 37 bits instead of 33 bits out of 64 are used). And, the OPCODE_SWZ handling is completely changed (no longer tries to emulate it with multiple RSW instructions), the code got much, much easier to understand and as a bonus it seems to work... However, I haven't looked at the codegen stuff yet. Maybe there's some bad interference there (it certainly won't work without changes).
Roland, Go ahead and make the simplification. The increase in instruction size doesn't really matter. The idea behind the RSW instruction was 1) to keep the instruction size small, but it's probably not that important, and 2) as a partial step towards something that could be implemented with SSE. I don't think either goal is valid any more -- the SSE approach I'd use now is quite different. Keith
Seems to work now. I've also implemented the necessary changes in t_vb_arbprogram_sse.c. The codegen stuff still appears quite broken when testing with glean (lots of free(): invalid pointer 0x3b4f5800, half the tests don't pass, some of the Mesa/progs/vp cases are quite broken too) but at least the swizzle tests pass, so that's beyond the scope of this bug...
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.