[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 #89 from Francisco Jerez <currojerez at riseup.net> ---
(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()).

> 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/20160606/598cc0b2/attachment.html>