<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#c7">Comment # 7</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>> That seems kinda silly, because it means that TIME_ELAPSED should be (draw_finish_time - previous_draw_finish_time). What if they finish nearly at the same time? TIME_ELAPSED would be close to 0, and that is not how much time the draw call spent in the system. Doesn't it become a question of what these time_elapsed queries are supposed to be useful for? If a pass becomes "free" because it's executed in parallel with another pass, then I would (personally) expect the measured execution time to be low. Basically, what I'm interested in measuring is the critical path; rather than the “sum” of all GPU time spent in the program. I also highly rely on the additive property of pass queries, which is perhaps what khronos also intended when they advised using bottom_of_pipe queries. As for practical solutions - I've already experimented using GL_TIMESTAMP instead of GL_TIME_ELAPSED - the main problem I had with this approach was that it completely broke on OS X and Windows (ANGLE), because apparently google and apple are unwilling to implement them, citing “lack of a way to communicate overflow” as a reason (and apparently oblivious to the possibility of using 64-bit timestamps like everybody else). Worst comes to worst, I'll have to work around this particular issue by using GL_TIMESTAMP where available and falling back to GL_TIME_ELAPSED otherwise, but either way, I still think this is a rather silly violation of both “common sense” and the khronos specification. Specifically: > When BeginQuery and EndQuery are called with a <target> of > TIME_ELAPSED, the GL prepares to start and stop the timer used for > timer queries. The timer is started or stopped when the effects from all > previous commands on the GL client and server state and the framebuffer > have been fully realized. <a href="http://developer.download.nvidia.com/opengl/specs/GL_ARB_timer_query.txt">http://developer.download.nvidia.com/opengl/specs/GL_ARB_timer_query.txt</a> This is not just an advisal, this directly implies a dependency between the BeginQuery and the previous draw calls. My application is coded around the behavior described by this paragraph, which your patch appears to violate.</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>