<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">Hi Rainer,<br>
      <br>
      well at the end of the pipeline the page flip waits for all
      previous operations on a buffer to be completed before displaying
      it. But even that wait is asynchronous.<br>
      <br>
      So as long as you don't wait for the page flip your render thread
      won't be blocked.<br>
      <br>
      Using vaSyncSurface is only good in two occasions:<br>
      1. You want to access the data with the CPU. And even then it is
      not necessary most of the time because of how Mesa is designed.<br>
      2. You need to limit how many jobs are in flight. Depending on how
      you do resource management that is necessary to prevent the
      application from scheduling mass amount of jobs and running away
      with all the resources for that.<br>
      <br>
      Regards,<br>
      Christian.<br>
      <br>
      Am 11.02.2018 um 13:26 schrieb <a class="moz-txt-link-abbreviated" href="mailto:rainer.hochecker@onlinehome.de">rainer.hochecker@onlinehome.de</a>:<br>
    </div>
    <blockquote type="cite"
cite="mid:trinity-d7638660-16d7-4a58-941f-7459f3f9981a-1518351999075@3c-app-1and1-bs05">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      <div style="font-family: Verdana;font-size: 12.0px;">
        <div>Hi Christian,</div>
        <div> </div>
        <div>Finally something in the render pipeline has to wait until
          decoding is finished or the</div>
        <div>frame can't be rendered and this will result in blocking
          the render thread.</div>
        <div> </div>
        <div>Regards,</div>
        <div>Rainer</div>
        <div> </div>
        <div name="quote" style="margin:10px 5px 5px 10px; padding: 10px
          0 10px 10px; border-left:2px solid #C3D9E5; word-wrap:
          break-word; -webkit-nbsp-mode: space; -webkit-line-break:
          after-white-space;">
          <div style="margin:0 0 10px 0;"><b>Gesendet:</b> Sonntag, 11.
            Februar 2018 um 13:13 Uhr<br>
            <b>Von:</b> "Christian König"
            <a class="moz-txt-link-rfc2396E" href="mailto:christian.koenig@amd.com"><christian.koenig@amd.com></a><br>
            <b>An:</b> <a class="moz-txt-link-rfc2396E" href="mailto:rainer.hochecker@onlinehome.de">"rainer.hochecker@onlinehome.de"</a>
            <a class="moz-txt-link-rfc2396E" href="mailto:rainer.hochecker@onlinehome.de"><rainer.hochecker@onlinehome.de></a><br>
            <b>Cc:</b> "Philipp Kerling" <a class="moz-txt-link-rfc2396E" href="mailto:pkerling@casix.org"><pkerling@casix.org></a>,
            <a class="moz-txt-link-abbreviated" href="mailto:sw@jkqxz.net">sw@jkqxz.net</a>, <a class="moz-txt-link-abbreviated" href="mailto:peter.fruehberger@gmail.com">peter.fruehberger@gmail.com</a>,
            <a class="moz-txt-link-abbreviated" href="mailto:michel@daenzer.net">michel@daenzer.net</a>, <a class="moz-txt-link-abbreviated" href="mailto:mesa-dev@lists.freedesktop.org">mesa-dev@lists.freedesktop.org</a>,
            <a class="moz-txt-link-abbreviated" href="mailto:harry.wentland@amd.com">harry.wentland@amd.com</a>, <a class="moz-txt-link-abbreviated" href="mailto:lrusak@libreelec.tv">lrusak@libreelec.tv</a><br>
            <b>Betreff:</b> Re: [Mesa-dev] 10bit HEVC decoding for
            RadeonSI v2</div>
          <div name="quoted-content">
            <div style="background-color: rgb(255,255,255);">
              <div class="moz-cite-prefix">Hi Rainer,<br>
                <br>
                the render thread doesn't wait either.</div>
              <div class="moz-cite-prefix"><br>
                See when you dispatch some work the AMD drivers always
                wait for prerequisites in the background, not in the
                foreground.<br>
                <br>
                The older radeon driver uses hardware semaphores for
                this while amdgpu has a GPU scheduler which handles that
                stuff.<br>
                <br>
                This is very important because when you hold back
                rendering work in the application the driver stack won't
                know about it and power management starts to stutter.<br>
                <br>
                Not so important for 1920p because power management
                should be able to compensate the work peaks, but for 4K
                that's something mandatory to let the driver be able to
                estimate future load.<br>
                <br>
                We even discussed in our multimedia meeting if we
                shouldn't limit 3D power management when UVD/VCN
                decoding is active because of that problem. But I'm not
                very keen about those workarounds because it's really
                counterproductive for transcode use cases to have the 3D
                engine idling around with high clocks.<br>
                <br>
                Regards,<br>
                Christian.<br>
                <br>
                Am 11.02.2018 um 12:51 schrieb <a
                  class="moz-txt-link-abbreviated"
                  href="mailto:rainer.hochecker@onlinehome.de"
                  onclick="parent.window.location.href='rainer.hochecker@onlinehome.de';
                  return false;" target="_blank" moz-do-not-send="true">rainer.hochecker@onlinehome.de</a>:</div>
              <blockquote>
                <div style="font-family: Verdana;font-size: 12.0px;">
                  <div>Hi Christian,</div>
                  <div> </div>
                  <div>For Kodi it is better to wait on the thread that
                    does decoding than later </div>
                  <div>by the render thread. Means it is desired to call
                    it.</div>
                  <div> </div>
                  <div>Does vaSyncSurface block as stated by the docs?</div>
                  <div> </div>
                  <div>Regards,</div>
                  <div>Rainer</div>
                  <div> 
                    <div style="margin: 10.0px 5.0px 5.0px
                      10.0px;padding: 10.0px 0 10.0px
                      10.0px;border-left: 2.0px solid rgb(195,217,229);">
                      <div style="margin: 0 0 10.0px 0;"><b>Gesendet:</b> Sonntag,
                        11. Februar 2018 um 11:02 Uhr<br>
                        <b>Von:</b> "Christian König" <a
                          class="moz-txt-link-rfc2396E"
                          href="mailto:christian.koenig@amd.com"
                          onclick="parent.window.location.href='christian.koenig@amd.com';
                          return false;" target="_blank"
                          moz-do-not-send="true"><christian.koenig@amd.com></a><br>
                        <b>An:</b> "Philipp Kerling" <a
                          class="moz-txt-link-rfc2396E"
                          href="mailto:pkerling@casix.org"
                          onclick="parent.window.location.href='pkerling@casix.org';
                          return false;" target="_blank"
                          moz-do-not-send="true"><pkerling@casix.org></a>,
                        <a class="moz-txt-link-abbreviated"
                          href="mailto:sw@jkqxz.net"
                          onclick="parent.window.location.href='sw@jkqxz.net';
                          return false;" target="_blank"
                          moz-do-not-send="true">sw@jkqxz.net</a><br>
                        <b>Cc:</b> <a class="moz-txt-link-abbreviated"
                          href="mailto:rainer.hochecker@onlinehome.de"
                          onclick="parent.window.location.href='rainer.hochecker@onlinehome.de';
                          return false;" target="_blank"
                          moz-do-not-send="true">rainer.hochecker@onlinehome.de</a>,
                        <a class="moz-txt-link-abbreviated"
                          href="mailto:peter.fruehberger@gmail.com"
                          onclick="parent.window.location.href='peter.fruehberger@gmail.com';
                          return false;" target="_blank"
                          moz-do-not-send="true">peter.fruehberger@gmail.com</a>,
                        <a class="moz-txt-link-abbreviated"
                          href="mailto:michel@daenzer.net"
                          onclick="parent.window.location.href='michel@daenzer.net';
                          return false;" target="_blank"
                          moz-do-not-send="true">michel@daenzer.net</a>,
                        <a class="moz-txt-link-abbreviated"
                          href="mailto:mesa-dev@lists.freedesktop.org"
                          onclick="parent.window.location.href='mesa-dev@lists.freedesktop.org';
                          return false;" target="_blank"
                          moz-do-not-send="true">mesa-dev@lists.freedesktop.org</a>,
                        <a class="moz-txt-link-abbreviated"
                          href="mailto:harry.wentland@amd.com"
                          onclick="parent.window.location.href='harry.wentland@amd.com';
                          return false;" target="_blank"
                          moz-do-not-send="true">harry.wentland@amd.com</a>,
                        <a class="moz-txt-link-abbreviated"
                          href="mailto:lrusak@libreelec.tv"
                          onclick="parent.window.location.href='lrusak@libreelec.tv';
                          return false;" target="_blank"
                          moz-do-not-send="true">lrusak@libreelec.tv</a><br>
                        <b>Betreff:</b> Re: [Mesa-dev] 10bit HEVC
                        decoding for RadeonSI v2</div>
                      <div>Am 09.02.2018 um 21:35 schrieb Philipp
                        Kerling:<br>
                        > Hi,<br>
                        ><br>
                        > resurrecting this thread again since
                        there's been some progress on the<br>
                        > Kodi side.<br>
                        ><br>
                        >> For the EGL part, see <<a
                          href="https://github.com/01org/libva/pull/125"
                          target="_blank" moz-do-not-send="true">https://github.com/01org/libva/pull/125</a>><br>
                        >> and <<a
href="https://lists.freedesktop.org/archives/mesa-dev/2017-October/171246.html"
                          target="_blank" moz-do-not-send="true">https://lists.freedesktop.org/archives/mesa-dev/2017-October/171246.html</a>>.<br>
                        > We recently started testing
                        vaExportSurfaceHandle support, so we will<br>
                        > have this covered soon.<br>
                        ><br>
                        >> I have been testing with mpv and
                        ffmpeg; any thoughts from the<br>
                        >> Kodi point of view would be most
                        welcome.<br>
                        > It generally works quite well, but we still
                        have the unresolved<br>
                        > vaSyncSurface problem.<br>
                        > To recap: vaExportSurfaceHandle requires
                        calling vaSyncSurface to make<br>
                        > sure that the decode is actually finished
                        and the buffer is usable<br>
                        > before rendering the frame. However,
                        vaSyncSurface was largely<br>
                        > unimplemented on mesa back then and it was
                        unclear how to proceed with<br>
                        > regard to decode (VAAPI)/present (EGL+GL)
                        synchronization.<br>
                        ><br>
                        > So on to the question: Is this still the
                        case, or has there been<br>
                        > progress on implementing vaSyncSurface in
                        mesa? In either case, do we<br>
                        > need that support or does this syncing work
                        implicitly somehow on AMD?<br>
                        ><br>
                        > I've noticed that mpv does not seem to call
                        vaSyncSurface, although it<br>
                        > technically should.<br>
                        <br>
                        Actually the mpv approach is correct.<br>
                        <br>
                        Calling vaSyncSurface is unnecessary and
                        undesired for AMD hardware<br>
                        because it moves synchronization to the CPU
                        while it should happen on<br>
                        the GPU and/or GPU scheduler.<br>
                        <br>
                        E.g. our 3D pipeline can wait for hardware video
                        decoding to finish<br>
                        before starting the rendering. We even have some
                        implementations which<br>
                        allow the 3D pipeline to start when only the
                        first halve of the picture<br>
                        is decoded etc..<br>
                        <br>
                        If we don't do this the 3D pipeline runs dry
                        between frame decoding<br>
                        which leads to problems with power management.<br>
                        <br>
                        We should probably add a flag or bit or feature
                        or something like this<br>
                        to note that the application explicitly should
                        NOT call vaSyncSurface<br>
                        before exporting the surface.<br>
                        <br>
                        Regards,<br>
                        Christian.<br>
                        <br>
                        ><br>
                        > Best regards,<br>
                        > Philipp<br>
                        >
                        _______________________________________________<br>
                        > mesa-dev mailing list<br>
                        > <a class="moz-txt-link-abbreviated"
                          href="mailto:mesa-dev@lists.freedesktop.org"
                          onclick="parent.window.location.href='mesa-dev@lists.freedesktop.org';
                          return false;" target="_blank"
                          moz-do-not-send="true">mesa-dev@lists.freedesktop.org</a><br>
                        > <a
                          href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev"
                          target="_blank" moz-do-not-send="true">https://lists.freedesktop.org/mailman/listinfo/mesa-dev</a><br>
                         </div>
                    </div>
                  </div>
                </div>
              </blockquote>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
  </body>
</html>