[Mesa-dev] [Bug 107524] Broken packDouble2x32 at llvmpipe

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Wed Aug 8 17:07:59 UTC 2018


https://bugs.freedesktop.org/show_bug.cgi?id=107524

Roland Scheidegger <sroland at vmware.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |airlied at freedesktop.org

--- Comment #1 from Roland Scheidegger <sroland at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20180808/75789e03/attachment.html>


More information about the mesa-dev mailing list