[Bug 92760] Add FP64 support to the i965 shader backends
bugzilla-daemon at freedesktop.org
bugzilla-daemon at freedesktop.org
Mon Feb 1 03:15:46 PST 2016
https://bugs.freedesktop.org/show_bug.cgi?id=92760
--- Comment #41 from Iago Toral <itoral at igalia.com> ---
Hi Connor, I have a question about the brw_nir_split_doubles pass that you
wrote for the vec4 backend. The pass does not lower nir_op_vec3/4 on purpose
with this comment:
/* These ops are the ones that group up dvec2's and doubles into dvec3's
* and dvec4's when necessary, so we don't lower them. If they're
* unnecessary, copy propagation will clean them up.
*/
However, this obviously leads to 64-bit instructions writing to channels ZW,
which we don't want to have since our Nir->vec4 pass expects that any 64-bit
operation won't have a writemask including channels other than XY.
Right now, the lower_vec_to_movs pass that we run right after the nir_from_ssa
pass seems to generate MOVs that write to each channel of the vecN instruction
dest, so with this, it generates MOVs with 64-bit things that write to
components Z and W of a dvec3/4.
I suppose your idea was to break up ALU operations, then group them back as
vec3/vec4 operations so we don't lose track of the original size of the data
elements involved in the operations. If that is the case, I think we can
disable lower_vec_to_movs() on dvec3/dvec4 and let the nir-vec4 pass handle
those. Does this make sense to you? Did you have a different idea about how
this should work?
--
You are receiving this mail because:
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/intel-3d-bugs/attachments/20160201/3444deef/attachment.html>
More information about the intel-3d-bugs
mailing list