<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Add FP64 support to the i965 shader backends" href="https://bugs.freedesktop.org/show_bug.cgi?id=92760#c90">Comment # 90</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Add FP64 support to the i965 shader backends" href="https://bugs.freedesktop.org/show_bug.cgi?id=92760">bug 92760</a> from <a class="email" href="mailto:itoral@igalia.com" title="Iago Toral <itoral@igalia.com>"> Iago Toral</a> <pre>(In reply to Francisco Jerez from <a href="show_bug.cgi?id=92760#c89">comment #89</a>) > (In reply to Juan A. Suarez from <a href="show_bug.cgi?id=92760#c88">comment #88</a>) > >[..] > > 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] > > <a href="https://github.com/Igalia/mesa/commit/">https://github.com/Igalia/mesa/commit/</a> > > 7bb5dd6b8263f73ecf2f10ff1efc85130cc87bcd > > [2] > > <a href="https://github.com/Igalia/mesa/commit/">https://github.com/Igalia/mesa/commit/</a> > > 06ad62a92515af242ba105e635f24e5c5117dda7 > > [3] > > <a href="https://github.com/Igalia/mesa/commit/">https://github.com/Igalia/mesa/commit/</a> > > ca8cf009aa2eb61c145211c3461e29e4bf9a62ac</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>