There's some debate about whether TIME_ELAPSED should only contain the time spent in the current GL context's drawing, or if it should be a total wall time, including time when the GPU was off processing some other application's work.

<anholt> Kayden: so, i965's behavior really confused a developer trying to use GL_TIME_ELAPSED last night -- it doesn't bracket the batchbuffer, so his rendering randomly gets spikes of overhead from other clients' batchbuffers being counted.
<Kayden> anholt: isn't that how the query is supposed to work, though?
<anholt> Kayden: I don't think so
<anholt> I think the resolution text was intending to say "this is mesauring time elapsed on gpu, not the time between when you start the query and when commands are done."
<anholt> they're pretty unclear
<anholt> but I can't see how the current behavior could be useful
<anholt> if you wanted to know whole-system timelines, you'd be using timestamps on the cpu and gpu side.  you're using elapsed because you want to know how much gpu time was spent.

https://cvs.khronos.org/bugzilla/show_bug.cgi?id=5790#c2 is interesting.  It looks like there was originally intended to be language indicating the timer should be "paused" if the GL was "interrupted", but nobody was quite sure what "interrupted" meant.  The timer was meant to report the true run time of GL.

I think both implementations are legal.  We currently do the wall-time one, which is cheaper, but it might be more useful if we bookended batch buffers.  With MI_MATH this would be pretty straightforward.  On earlier platforms it would be somewhat irritating.