https://bugs.freedesktop.org/show_bug.cgi?id=107524
Roland Scheidegger <srol...@vmware.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |airl...@freedesktop.org
--- Comment #1 from Roland Scheidegger <srol...@vmware.com> ---
I think your analysis is correct, gallivm code cannot handle this (I believe it
should work with softpipe?).
I'm not too familiar with the double support, in particular I'm not entirely
sure if such swizzles are even supposed to be supported for double opcodes,
though I don't really see a compelling reason why not (otherwise could of
course always get rid of them with a mov).
But at a quick glance, lp_build_tgsi_inst_llvm() will ignore the second and
fourth channel when fetching the arguments, emit_fetch_temporary() and others
will instead for 64bit src do a second fetch themselves, however they will
always use swizzle + 1 for it. This probably means that when the swizzle is .yx
it will instead actually fetch .yz for the double src (if you'd try .wz I think
you'd get an assertion failure).
I don't quite know how to fix this in some elegant way (as those fetch args are
propagated through lots of function, so those emit_fetch_temporary() and
friends functions simply have no knowledge what the second channel actually
should be for 64bit opcodes). Maybe Dave has some idea? I think one way or
another (at least if such swizzles are considered valid), the swizzle for the
second source has to be propagated through explicitly.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug._______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
