[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] frame timing

On Sat, Jan 18, 2014 at 5:10 PM, Brandon Jones <bajones@google.com> wrote:
At the very least the query API is coming in WebGL 2.0, and it seems like everyone is OK with the API format described in that spec. That gets us over one of the bigger hurdles, and may open the way for queries to be exposed to WebGL 1.0 as an extension.
I'm not sure about the rest of the arguments surrounding support or non-intuitive results.
That still leaves most of the issues open for question.

Both http://www.opengl.org/registry/specs/ARB/timer_query.txt (GL) and http://www.khronos.org/registry/gles/extensions/EXT/EXT_disjoint_timer_query.txt (ES)

Fit for production deployment?
glFinish() can be used to determine when previous rendering commands have
    been completed, but will idle the graphics pipeline and adversely affect
    application performance.
This susggests that ARB_timer_query and EXT_disjoint_timer_query are meant as a solution to that problem (of measuring performance, performantly). It's been mentioned that using timer queries slows down some machines substantially (so that it can't be deployed in non debug code). Can anybody comment on this?

It's also been suggested that using timer queries may frequently result in driver bugs/context loss, any comment on this?

Tiled rendering

Tiled renderers are also referred in both extensions with this passage from issues:

(10) What about tile-based implementations? The effects of a command are
        not complete until the frame is completely rendered. Timing recorded
        before the frame is complete may not be what developers expect. Also
        the amount of time needed to render the same primitives is not
        consistent, which conflicts with issue (8) above. The time depends on
        how early or late in the scene it is placed.

    RESOLVED: The current language supports tile-based rendering okay as it
    is written. Developers are warned that using timers on tile-based
    implementation may not produce results they expect since rendering is not
    done in a linear order. Timing results are calculated when the frame is
    completed and may depend on how early or late in the scene it is placed.
My interpration of this statement is that:
  • Timer queries might not be finished until the frame is finished (how is "frame-end" defined?)
  • Intraframe queries might be garbage because of tile scheduling.
However this would still seem viable for using timer-queries after the frame is finished, to measure time of the whole frame correct?

Disjoint extra handling

The EXT_disjoint_timer_query extension also has additional wording over ARB_timer_query under additions to Chapter 5 of the ES 2 spec:

In order to know if the value returned from GetIntegerv or GetQuery is valid
GPU_DISJOINT_EXT needs to be used to make sure the GPU did not perform any
disjoint operation. This can be done through GetIntegerv by using GPU_-
DISJOINT_EXT for <pname>. <params> will be filled with a non-zero value if
a disjoint operation occurred since the last time GetIntegerv was used with
GPU_DISJOINT_EXT. A zero value will be returned if no disjoint operation
occurred, indicating the values returned by this extension that are found
in-between subsequent GetIntegerv calls will be valid for performance
Disjoint operations occur whenever a change in the GPU occurs that will
make the values returned by this extension unusable for performance
metrics. An example can be seen with how mobile GPUs need to proactively
try to conserve power, which might cause the GPU to go to sleep at the
lower levers. This means disjoint states will occur at different times on
different platforms and are implementation dependent. When the returned
value is non-zero, all time values that were filled since the previous
disjoint check should be considered undefined."

My interpretation of this is that unless  you call gl.getParameter(gl.GPU_DISJOINT_EXT) and it returns non-zero, the timing information is garbage, and as long as you observe that rule, timer queries can be used for performance metrics?

The desktop version of the extension also lacks the disjoint get, will this be an issue?

Support status

This statistic suggests that for gamer desktops, the support for timer queries is around 50% http://feedback.wildfiregames.com/report/opengl/

Both the Nexus4 and the Nexus5 have disjoint timer queries, but I haven't checked all devices.

If it's not available, would there be any way to provide a still usable frame-time fallback for UAs (not intraframe)?