<html>
    <head>
      <base href="https://bugs.freedesktop.org/" />
    </head>
    <body>
      <p>
        <div>
            <b><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#c67">Comment # 67</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 <span class="vcard"><a class="email" href="mailto:currojerez@riseup.net" title="Francisco Jerez <currojerez@riseup.net>"> <span class="fn">Francisco Jerez</span></a>
</span></b>
        <pre>(In reply to Iago Toral from <a href="show_bug.cgi?id=92760#c66">comment #66</a>)
<span class="quote">>[..] 
> 2. It seems that the ExecMask in fp64 instructions is interpreted as 1-bit
> per fp64 component and not as 1-bit per 32-bit component. This has
> implications for non-uniform control flow. For example, in a gen7 VS SIMD4x2
> execution (2 logical threads, one for each vertex) of a dvec2 fp64 ALU
> operation subject to control-flow, the execution of the operation for the
> first vertex is done according to the ExecMask bits 0 and 1, which map
> components X/Y of the first logical thread and execution of the second
> vertex will consider bits 2 and 3 of the ExecMask which map to components
> Z/W , also of the first thread. This means that the operation will execute
> for the second vertex or not depending on whether the operation executes for
> the first vertex. Piglit does have any instances of fp64 tests involving
> non-uniform control flow like this which is why we did not observe this
> behavior before, but we did write an ad-hoc test that seems to verify that
> this problem exists. 

> Curro suggested that we can work around this problem in HSW+ by taking
> advantage of the fact that in these gens it is possible to process 8 DF
> elements in ALU operations, so we can simply not split dvec4 operations in
> dvec2 chunks, which would fix the problem automatically. Unfortunately, this
> also means that we need to figure out a solution to the problem with
> swizzles and writemasks working on 32-bit elements (more on that topic
> below).

> Unfortunately, that solution would not work for IVB, since that hardware
> cannot run ALU instructions operating on more than 4 DF components. Curro
> thinks that in this case we could divide the SIMD4x2 execution in 2 SIMD4x1
> instructions. That is, we generate one dvec4 instruction for each logical
> thread and use NibCtrl to fixup execution masking for the second instruction.
> </span >

I don't think that getting this to work on IVB would be particularly difficult
-- You can just emit 8-wide instructions universally and then hook up the FS
back-end's SIMD lowering pass so things are chopped up in pieces IVB parts will
be able handle.  NibCtrl seems to work okay on IVB for this purpose, we just
need some way to represent it in the VEC4 IR.

<span class="quote">>[...]
> 5) It seems that gen7 hardware has a bug by which writes that span more than
> one register and operate on 32-bit components won't work. Unfortunately, we
> use this all the time in fp64 since accessing data in 32-bit element chunks
> is a common pattern, Curro verified this in the simulator, apparently there
> is inconsistent execmasking in this situation with the second half of the
> instruction which results in the second part of the write not happening
> reliably. Curro thinks that the best way to deal with this is to split the
> operations in two, each one operating on a single register, which would
> require to monkey with NibCtrl again.</span >

For completeness, the problem is that pre-Gen8 EUs are hardwired to use the
QtrCtrl+1 (where QtrCtrl is the 8-bit quarter of the execution mask signals
specified in the instruction control fields) for the second compressed half of
any single-precision instruction (for double-precision instructions it's
hardwired to use NibCtrl+1), which means that the EU will apply the wrong
execution controls for the second sequential GRF write if the number of
channels per GRF is not exactly eight in single-precision mode (or four in
double-float mode).

<span class="quote">> 
> Opinions?</span ></pre>
        </div>
      </p>
      <hr>
      <span>You are receiving this mail because:</span>
      
      <ul>
          <li>You are the QA Contact for the bug.</li>
      </ul>
    </body>
</html>