[Bug 92760] Add FP64 support to the i965 shader backends

[bugzilla-daemon at freedesktop.org]

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

--- Comment #90 from Iago Toral <itoral at igalia.com> ---
(In reply to Francisco Jerez from comment #89)
> (In reply to Juan A. Suarez from comment #88)
> >[..]
> > Related with this topic, current liveness analysis code (and also DCE
> > optimization) just ignore the types when dealing with the swizzles. This
> > works fine, except when reading/writing a channel from DF type (64-bit
> > channel), and write/read it later as F (32-bit channel).
> > 
> > For instance, for this piece is code:
> > 
> >     mov(8) vgrf3.0.x:UD[1], 2576980378U[1] NoMask
> >     mov(8) vgrf3.0.y:UD[1], 1071225241U[1] NoMask
> >     mov(8) vgrf3.1.x:UD[1], 2576980378U[1] NoMask
> >     mov(8) vgrf3.1.y:UD[1], 1071225241U[1] NoMask
> >     mov(8) vgrf2.0.xy:DF[2], vgrf3.0.xxxx:DF[2]
> > 
> > Our liveness analysis just decide vgrf3.0.y channel is not live anymore and
> > thus DCE removes it. That is because in latest instruction it doesn't
> > realize vgrf3.0.x:DF is reading both vgrf3.0.x:F and vgrf3.0.y:F.
> > 
> > In order to avoid introducing too many changes in our current code, I've
> > added a pair of commits[1][2] that basically try to check if a 32-bit
> > channels was previously read as 64-bit (and the other way around). This
> > seems to fix above problem.
> 
> Seems very sketchy.  You need to fix the current dataflow analysis logic to
> flip/check as many bits per channel from the live, use or def bitsets as the
> corresponding source or destination datatype takes, just like the FS back-end
> handles multi-GRF defs and uses.
> 
> > But as it was said in previous comments HSW interprets all swizzles channels
> > as 32 bits, no matter the type. Iago added a pass that expands the 64bit
> > swizzles in 32bits. But this means once we expand them, we need to read all
> > the channels as 32bits,no matter the type.
> 
> I'd recommend against mixing logical and physical swizzle representations in
> the IR, because you lose the main benefit of the logical representation which
> is you don't need to think about the physical representation (which is hard
> because there is no longer a 1:1 correspondence between swizzle units and
> instruction component units), and OTOH because some of the logical swizzle
> combinations (the ones that require vstride to be set to zero) are currently
> irrepresentable if you use physical swizzles.  I think the most sensible
> approach would be to have the swizzle and writemask lowering passes output
> IR with swizzles encoded according to the logical representation (or rather
> the subset of it which can be directly supported by the hardware), and then
> do
> the logical to physical translation at codegen time (e.g. during
> convert_to_hw_regs()).

Yes, I was thinking about doing the same thing. If we call the swizzle
translation pass from convert_to_hw_regs directly we should never have to worry
about someone adding another opt pass that runs after it.

> > In order to control this, I've added a boolean to specify if all the
> > channels must be interpreted as 32bit or not[3]. This is used both in
> > liveness analysis and DCE.
> 
> *Shudder* I'd rather not have the semantics of the IR depend on an external
> boolean flag stored in the visitor class.
> 
> > Just dropping here this comment to get feedback if the approach sounds
> > reasonable, or if we must change it.
> > 
> > [1]
> > https://github.com/Igalia/mesa/commit/
> > 7bb5dd6b8263f73ecf2f10ff1efc85130cc87bcd
> > [2]
> > https://github.com/Igalia/mesa/commit/
> > 06ad62a92515af242ba105e635f24e5c5117dda7
> > [3]
> > https://github.com/Igalia/mesa/commit/
> > ca8cf009aa2eb61c145211c3461e29e4bf9a62ac

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-3d-bugs/attachments/20160607/b10f9add/attachment.html>