<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <br>
    <br>
    <div class="moz-cite-prefix">On 22/09/15 08:38, Thomas Helland
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAJOqoa334M5vqeo6i16hBzaOU5_Lpgzi-C6CFy5ozAu8Jr-dJA@mail.gmail.com"
      type="cite">
      <p dir="ltr">16. sep. 2015 21.47 skrev "Alejandro Piñeiro" <<a
          moz-do-not-send="true" href="mailto:apinheiro@igalia.com"><a class="moz-txt-link-abbreviated" href="mailto:apinheiro@igalia.com">apinheiro@igalia.com</a></a>>:<br>
        ><br>
        > On the review of the patch "i965/nir/vec4: fill the type of
        the dst<br>
        > and src when loading an uniform" Jason Ekstrand suggested
        to change<br>
        > the optimization pass in order to allow the copy
        propagation with<br>
        > MOVs even if there is a type mismatch, as was done on the
        fs path,<br>
        > instead of fixing the type for MOV instructions.[1]<br>
        ><br>
        > So using commit 472ef9 as reference I implemented the
        equivalent<br>
        > for the vec4 case. But that only worked if it was the
        current<br>
        > instruction the MOV with default types. It didn't fixed the
        shader-db<br>
        > instruction count regression I was working on, that was
        when it was<br>
        > the from instruction the MOV with default types. Or in
        other words,<br>
        > it didn't cover this case:<br>
        ><br>
        >    1: mov vgrf1.0:UD, u0.xyzw:UD<br>
        >    2: add vgrf2.0:F, vgrf0.xyzw:F, -vgrf1.xyzw:F<br>
        ><br>
        > So I extended the same idea by checking too against the
        from<br>
        > instruction. In order to do that, I needed to also track<br>
        > the vec4_instructions on the copy_entry struct.<br>
        ><br>
        > Submitting two patches because I think that it will be
        easier<br>
        > to review in this way. But if this solutions is approved, I<br>
        > think that it could be better to push them squashed on just<br>
        > one patch.<br>
        ><br>
        > Shader-db results for vec4 programs on Haswell:<br>
        > total instructions in shared programs: 1746280 ->
        1732159 (-0.81%)<br>
        > instructions in affected programs:     760595 -> 746474
        (-1.86%)<br>
        > helped:                                6132<br>
        > HURT:                                  0<br>
        > GAINED:                                0<br>
        > LOST:                                  0<br>
        ><br>
        ><br>
        > [1] <a moz-do-not-send="true"
href="http://lists.freedesktop.org/archives/mesa-dev/2015-September/094555.html">http://lists.freedesktop.org/archives/mesa-dev/2015-September/094555.html</a><br>
        ><br>
        > Alejandro Piñeiro (2):<br>
        >   i965/vec4: Change types as needed to propagate source
        modifiers using<br>
        >     current instruction<br>
        >   i965/vec4: Change types as needed to propagate source
        modifiers using<br>
        >     from instruction<br>
        ><br>
        >  .../drivers/dri/i965/brw_vec4_copy_propagation.cpp | 45
        ++++++++++++++++++++--<br>
        >  1 file changed, 41 insertions(+), 4 deletions(-)<br>
        ></p>
      <p dir="ltr">I don't know if it is of much use, but I implemented
        a function along these lines<br>
        for my value range propagation pass, but that works in NIR.<br>
        It tries to infer the type based on the users or the sources.<br>
        It lives in [1] as get_alu_type_from_sources / dest.<br>
        Just thought I'd mention it. It's not perfect, but I think it
        should<br>
        be quite clear how I wanted it to work. Maybe it's off use,
        maybe not,<br>
        just thought I'd point you to it.</p>
    </blockquote>
    <br>
    Thanks for pointing this. In any case, we don't need to infer types
    on this case. Take a look to the patch I originally proposed to
    solve the issues this patch solve:<br>
<a class="moz-txt-link-freetext" href="http://lists.freedesktop.org/archives/mesa-dev/2015-September/094547.html">http://lists.freedesktop.org/archives/mesa-dev/2015-September/094547.html</a><br>
    <br>
    It is possible to fill the proper types without any inference. But
    the point of Jason Ekstrand on his review:<br>
<a class="moz-txt-link-freetext" href="http://lists.freedesktop.org/archives/mesa-dev/2015-September/094547.html">http://lists.freedesktop.org/archives/mesa-dev/2015-September/094547.html</a><br>
    <br>
    Is that it is possible to do the copy propagation regardless the
    type, because on several specific cases they are not preventing us
    to do the optimization.<br>
    <br>
    Again, thanks for the suggestion<br>
    <br>
    <blockquote
cite="mid:CAJOqoa334M5vqeo6i16hBzaOU5_Lpgzi-C6CFy5ozAu8Jr-dJA@mail.gmail.com"
      type="cite">
      <p dir="ltr">[1] <a moz-do-not-send="true"
href="https://github.com/thohel/mesa/blob/gsoc-final-range-prop/src/glsl/nir/nir_opt_value_range.c">https://github.com/thohel/mesa/blob/gsoc-final-range-prop/src/glsl/nir/nir_opt_value_range.c</a></p>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Alejandro Piñeiro (<a class="moz-txt-link-abbreviated" href="mailto:apinheiro@igalia.com">apinheiro@igalia.com</a>)</pre>
  </body>
</html>