[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