<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <br>
    <br>
    <div class="moz-cite-prefix">On 9/18/18 1:08 PM, Jason Ekstrand
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAOFGe95G0BsJ5nzXzh-aDcyPGp560Z0s25eWxMumR+908y9SMg@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <div class="gmail_quote">
          <div dir="ltr">On Tue, Sep 18, 2018 at 4:08 AM Danylo Piliaiev
            <<a href="mailto:danylo.piliaiev@gmail.com"
              moz-do-not-send="true">danylo.piliaiev@gmail.com</a>>
            wrote:<br>
          </div>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
            <div text="#000000" bgcolor="#FFFFFF">
              <div class="m_-6732043544054597089moz-cite-prefix">On
                9/17/18 7:03 PM, Jason Ekstrand wrote:<br>
              </div>
              <blockquote type="cite">
                <div dir="ltr">
                  <div class="gmail_quote">
                    <div dir="ltr">On Mon, Sep 17, 2018 at 10:08 AM
                      Danylo Piliaiev <<a
                        href="mailto:danylo.piliaiev@gmail.com"
                        target="_blank" moz-do-not-send="true">danylo.piliaiev@gmail.com</a>>
                      wrote:<br>
                    </div>
                    <blockquote class="gmail_quote" style="margin:0 0 0
                      .8ex;border-left:1px #ccc solid;padding-left:1ex">
                      <div text="#000000" bgcolor="#FFFFFF"> <br>
                        <br>
                        <div
                          class="m_-6732043544054597089m_8653083740311233362moz-cite-prefix">On
                          9/17/18 5:34 PM, Jason Ekstrand wrote:<br>
                        </div>
                        <blockquote type="cite">
                          <div dir="ltr">
                            <div class="gmail_quote">
                              <div dir="ltr">On Mon, Sep 17, 2018 at
                                8:34 AM Danylo Piliaiev <<a
                                  href="mailto:danylo.piliaiev@gmail.com"
                                  target="_blank" moz-do-not-send="true">danylo.piliaiev@gmail.com</a>>
                                wrote:<br>
                              </div>
                              <blockquote class="gmail_quote"
                                style="margin:0 0 0 .8ex;border-left:1px
                                #ccc solid;padding-left:1ex">
                                <div text="#000000" bgcolor="#FFFFFF">
                                  Hi Jason,<br>
                                  <br>
                                  I have implemented the extension and
                                  it works, however before sending the
                                  patch I decided to see how it can
                                  interact with other extension -
                                  VK_EXT_conditional_render<br>
                                  and got confused:<br>
                                  <br>
                                  From the spec it is not disallowed to
                                  call functions of
                                  VK_KHR_draw_indirect_count in
                                  conditional rendering block. So let's
                                  say that predicate of conditional
                                  rendering<br>
                                  will result in FALSE, we call <span
class="m_-6732043544054597089m_8653083740311233362m_8153322649885267684blob-code-inner&#xA;m_8653083740311233362m_8153322649885267684blob-code-marker-addition"><span
class="m_-6732043544054597089m_8653083740311233362m_8153322649885267684pl-s">vkCmdDrawIndirectCountKHR
                                      which sees that there is already a
                                      predicate emitted and it should be
                                      taken into account, since it will
                                      be FALSE<br>
                                      all next predicates should result
                                      in FALSE. The issue is that I
                                      don't see an easy way to do this.<br>
                                      <br>
                                      My current implementation uses the
                                      next predicate (it is same as in
                                      GL implementation):<br>
                                      <br>
                                      <tt>       /* While draw_index
                                        < maxDrawCount the
                                        predicate's result will be</tt><tt><br>
                                      </tt><tt>        *  (draw_index ==
                                        maxDrawCount) ^ TRUE = TRUE</tt><tt><br>
                                      </tt><tt>        * When draw_index
                                        == maxDrawCount the result is</tt><tt><br>
                                      </tt><tt>        *  (TRUE) ^ TRUE
                                        = FALSE</tt><tt><br>
                                      </tt><tt>        * After this all
                                        results will be:</tt><tt><br>
                                      </tt><tt>        *  (FALSE) ^
                                        FALSE = FALSE</tt><tt><br>
                                      </tt><tt>        */</tt><tt><br>
                                      </tt><tt>      
                                        anv_batch_emit(&cmd_buffer->batch,
                                        GENX(MI_PREDICATE), mip) {</tt><tt><br>
                                      </tt><tt>         
                                        mip.LoadOperation    =
                                        LOAD_LOAD;</tt><tt><br>
                                      </tt><tt>         
                                        mip.CombineOperation =
                                        COMBINE_XOR;</tt><tt><br>
                                      </tt><tt>         
                                        mip.CompareOperation =
                                        COMPARE_SRCS_EQUAL;</tt><tt><br>
                                      </tt><tt>       }</tt><br>
                                      <br>
                                      But if the initial predicate state
                                      is FALSE then when draw_index
                                      equals maxDrawCount the result
                                      will be<br>
                                        <tt>(FALSE) ^ TRUE = TRUE</tt><br>
                                      Which isn't something we want. But
                                      without "not equal" operation or
                                      without MI_MATH I don't see how to
                                      fix this.<br>
                                    </span></span></div>
                              </blockquote>
                              <div><br>
                              </div>
                              <div>First off, thanks for looking into
                                the combination of these two features. 
                                Getting them to work together nicely is
                                half of the difficulty of these two
                                extensions.<br>
                              </div>
                              <div><br>
                              </div>
                              <div>On platforms which support MI_MATH, I
                                think we're probably better off just
                                using it.  For Ivy Bridge, the only
                                thing I could think to do when both are
                                in use would be to do two MI_PREDICATEs
                                for every draw call.  The first would be
                                what you describe above and the second
                                would be the MI_PREDICATE for the
                                conditional render with COMBINE_AND. 
                                When the condition is true, the AND
                                would have no effect and you would get
                                the behavior above.  If the condition is
                                false, the above logic for implementing
                                draw_indirect_count wouldn't matter
                                because it would get ANDed with false. 
                                On Haswell and later, it's likely more
                                efficient to just use MI_MATH and avoid
                                re-loading the draw count and condition
                                on every draw call.  (We could just
                                leave the draw count in CS_GPR0, for
                                instance.)  Does that work?</div>
                            </div>
                          </div>
                        </blockquote>
                        Looks like a plan. I'll try to go this path.<br>
                        <br>
                        Also there is another interaction which wasn't
                        thought of before:<br>
                        Several <span
class="m_-6732043544054597089m_8653083740311233362m_8153322649885267684blob-code-inner&#xA;m_8653083740311233362m_8153322649885267684blob-code-marker-addition"><span
class="m_-6732043544054597089m_8653083740311233362m_8153322649885267684pl-s">vkCmdDrawIndirectCountKHR
                            in conditional render block but using
                            MI_MATH should solve it.<br>
                          </span></span></div>
                    </blockquote>
                    <div><br>
                    </div>
                    <div>In that case, we'll have to basically re-do the
                      conditional bit for every draw call.  There may be
                      some interesting interactions here with secondary
                      command buffers as well.  I don't remember what we
                      decided about inheriting conditions in
                      secondaries.  Again, if we decide we need MI_MATH,
                      then we'll just drop support for one or both
                      extensions on Ivy Bridge.</div>
                    <div><br>
                    </div>
                  </div>
                </div>
              </blockquote>
              About the secondary command buffers:<br>
              <br>
              If <a
href="https://www.khronos.org/registry/vulkan/specs/1.1-extensions/html/vkspec.html#features-features-inheritedConditionalRendering"
                target="_blank" moz-do-not-send="true">inherited
                conditional rendering</a> is supported it means that
              secondary buffers can be executed inside conditional
              rendering block and commands which can be affected by
              conditional rendering are affected by it in secondary
              buffer and also in primary, is it right?<br>
              However at this point the secondary buffer is already
              composed without commands for conditions and since our
              implementation depends on commands emitted to the buffer
              making its commands to depend on condition either highly
              tricky to do (secondary buffer needs to have certain
              points where to inject conditions?) or just impossible. <br>
              And this secondary buffer may have been formed inside
              conditional render block so they could be affected by two
              conditions if I understand correctly.<br>
              <br>
              Is is doable to implement?<br>
            </div>
          </blockquote>
          <div><br>
          </div>
          <div>I think it is.  The obvious way to implement it would be
            to have a boolean in the command buffer somewhere that tells
            you whether or not conditional rendering is enabled and use
            that to set the PredicateEnable bit on 3DPRIMITIVE
            commands.  For secondary command buffers, however, we would
            have to assume that predication is enabled and set the
            predicate to true in vkCmdExecuteCommands if conditional
            rendering is disabled.</div>
        </div>
      </div>
    </blockquote>
    For primary buffers I'm already doing it this way. <br>
    So if we want to support inherited conditional rendering all
    relevant commands in command buffers should be constructed with
    dependency on predicate. Just to be sure: is the dependency on
    predicate cheap?<br>
    <blockquote type="cite"
cite="mid:CAOFGe95G0BsJ5nzXzh-aDcyPGp560Z0s25eWxMumR+908y9SMg@mail.gmail.com">
      <div dir="ltr">
        <div class="gmail_quote">
          <div><br>
          </div>
          <div>The second issue is in communicating the predicate
            value.  If we don't have secondaries, we can just hang on to
            the condition buffer and re-read it whenever needed.  If
            we're going to use secondaries, we won't have it available
            in the secondary.  One obvious option would be to simply
            reserve one of the CS_GPR registers, say CS_GPR15, for
            storing the predicate value.  On Ivy Bridge, the CS_GPRs
            don't exist and we'd have to pick some other RW register. 
            Digging through the docs, I found the MI_PREDICATE_DATA
            which seems to exist for just this sort of thing. :-) 
            Exactly what register we use will have to depend on how we
            want to compute predicate values; I could see CS_GPR15 being
            more convenient if we use MI_MATH, for instance.<br>
          </div>
        </div>
      </div>
    </blockquote>
    Thanks for suggestion!<br>
    <blockquote type="cite"
cite="mid:CAOFGe95G0BsJ5nzXzh-aDcyPGp560Z0s25eWxMumR+908y9SMg@mail.gmail.com">
      <div dir="ltr">
        <div class="gmail_quote">
          <div><br>
          </div>
          --Jason<br>
        </div>
      </div>
    </blockquote>
    <br>
  </body>
</html>