<html>
    <head>
      <base href="https://bugs.freedesktop.org/">
    </head>
    <body>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_NEEDINFO "
   title="NEEDINFO - [Regression] mpv, high rendering times (two to three times higher)"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=102597#c3">Comment # 3</a>
              on <a class="bz_bug_link 
          bz_status_NEEDINFO "
   title="NEEDINFO - [Regression] mpv, high rendering times (two to three times higher)"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=102597">bug 102597</a>
              from <span class="vcard"><a class="email" href="mailto:bugs.freedesktop@haasn.xyz" title="Niklas Haas <bugs.freedesktop@haasn.xyz>"> <span class="fn">Niklas Haas</span></a>
</span></b>
        <pre>Hello, this is the author of the affected `mpv` code.

I've reproduced and bisected the mesa issue, and the first bad commit is:

bd4b224fa6630262df2b70fd6a6fc8080ad59086 is the first bad commit
commit bd4b224fa6630262df2b70fd6a6fc8080ad59086
Author: Marek Olšák <<a href="mailto:marek.olsak@amd.com">marek.olsak@amd.com</a>>
Date:   Mon May 15 17:27:25 2017 +0200

    gallium/radeon: use a top-of-pipe timestamp for the start of TIME_ELAPSED

    Reviewed-by: Nicolai Hähnle <<a href="mailto:nicolai.haehnle@amd.com">nicolai.haehnle@amd.com</a>>

:040000 040000 22f52d00a837608d7a43e50498519850bf6ccdf6
eebe49b7fe167a7d6f96fe2a18218f350dededce M      src

This leads me to believe it's just a cosmetic issue, rather than a geneuine
performance regression. In order to figure out whether the results were more
correct before or after the change, I compared the numbers of all of my render
passes (added together) against the measurements of a single TIME_ELAPSED query
that surrounds the entire frame. The numbers matched perfectly before this
commit. Since the commit, the per-pass numbers are all way higher than they
should be.

I suspect this is because the driver is now “over-estimating” the amount of
time taken in between successive passes. Consider the following call sequence:

glBeginQuery(GL_TIME_ELAPSED)
// submit some draw calls
glEndQuery(GL_TIME_ELAPSED)
glBeginQuery(GL_TIME_ELAPSED)
// submit some more draw calls
glEndQuery(GL_TIME_ELAPSED)

If what I suspect is right, and these are assembled into the same command
buffer, then the “record TOP_OF_PIPE timestamp” for both queries would possibly
fire at the same time (out of order with the draw calls), leading to an
over-counting of the time taken for the second set of draw calls.

Perhaps it would be more correct to submit all of the timestamps with the
pipeline stage set to BOTTOM_OF_PIPE bit, so that the timestamps are
(respectively) only recorded once the previous commands in the command buffer
have been fully realized?</pre>
        </div>
      </p>


      <hr>
      <span>You are receiving this mail because:</span>

      <ul>
          <li>You are the QA Contact for the bug.</li>
          <li>You are the assignee for the bug.</li>
      </ul>
    </body>
</html>