https://bugs.freedesktop.org/show_bug.cgi?id=102597
--- Comment #7 from Niklas Haas <bugs.freedesk...@haasn.xyz> ---
> 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.
http://developer.download.nvidia.com/opengl/specs/GL_ARB_timer_query.txt
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.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
