<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <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 <a class="email" href="mailto:bugs.freedesktop@haasn.xyz" title="Niklas Haas <bugs.freedesktop@haasn.xyz>"> Niklas Haas</a> <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> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>