Bug 7082

Summary:	extended swizzle fails in vertex programs
Product:	Mesa	Reporter:	Roland Scheidegger <sroland>
Component:	Mesa core	Assignee:	mesa-dev
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	high
Version:	git
Hardware:	x86 (IA32)
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:
Attachments:	attempt to fix swz in mesa

Description Roland Scheidegger 2006-05-31 12:07:07 UTC

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.

Comment 1 Brian Paul 2006-05-31 12:23:04 UTC

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.

Comment 2 Roland Scheidegger 2006-05-31 16:16:34 UTC

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).

Comment 3 Keith Whitwell 2006-05-31 23:42:33 UTC

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

Comment 4 Roland Scheidegger 2006-06-01 16:04:39 UTC

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...

Comment 5 Adam Jackson 2009-08-24 12:23:56 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.