GPU Timing GL_TIMESTAMP Usage

269 views
Skip to first unread message

Bryan Angelo

unread,
Sep 15, 2021, 4:05:51 PM9/15/21
to Graphics-dev
I encountered the following error on Chromium stable 93.0.4577.63

> Mesa: User error: GL_INVALID_ENUM in glGetInteger64v(pname=GL_TIMESTAMP)

Digging into the code, I saw that glGetInteger64v with GL_TIMESTAMP is called in ui/gl/gpu_timing.cc if the timer type is kTimerTypeDisjoint or kTimerTypeARB.

> int64_t GPUTimingImpl::CalculateTimerOffset() {
>   if (!offset_valid_) {
>     if (timer_type_ == GPUTiming::kTimerTypeDisjoint ||
>         timer_type_ == GPUTiming::kTimerTypeARB) {
>       GLint64 gl_now = 0;
>       glGetInteger64v(GL_TIMESTAMP, &gl_now);

The timer type is determined based on available GL extensions and there is a GL/GLES version check to ensure glGetInteger64v is available.

>  if (context->HasExtension("GL_EXT_disjoint_timer_query")) {
>    timer_type_ = GPUTiming::kTimerTypeDisjoint;
>  } else if (context->HasExtension("GL_ARB_timer_query")) {
>    timer_type_ = GPUTiming::kTimerTypeARB;
>  } else if (context->HasExtension("GL_EXT_timer_query")) {
>    timer_type_ = GPUTiming::kTimerTypeEXT;
>    force_time_elapsed_query_ = true;
>    timestamp_bit_count_gl_ = 0;
>  }
>  // The command glGetInteger64v is only supported under ES3 and GL3.2. Since it
>  // is only used for timestamps, we workaround this by emulating timestamps
>  // so WebGL 1.0 will still have access to the extension.
>  if (!version_info->IsAtLeastGLES(3, 0) && !version_info->IsAtLeastGL(3, 2)) {
>    force_time_elapsed_query_ = true;
>    timestamp_bit_count_gl_ = 0;
>  }

However, the GL_TIMESTAMP enum does not appear to be supported in GLES3 based on the reference page for glGet.


So it would appear to me that ui/gl/gpu_timing.cc incorrectly calls glGetInteger64v with GL_TIMESTAMP when using GLES3.  I considered filing a bug, but due to my inexperience with chromium and GL I wanted to post this information here first to see if I am be overlooking something.

Thanks.

Zhenyao Mo

unread,
Sep 15, 2021, 5:05:02 PM9/15/21
to Bryan Angelo, Graphics-dev

Bryan Angelo

unread,
Sep 15, 2021, 5:40:29 PM9/15/21
to Graphics-dev, z...@chromium.org, Graphics-dev, Bryan Angelo
Interesting, thanks.


>    The extension is written against the OpenGL ES 2.0 specification.
>    
>    The GetInteger64vEXT command is required only if OpenGL ES 3.0 or
>    later is not supported (see the Interactions section for details).

And defines the new token for GLES2.

>    Accepted by the <target> parameter of GetQueryiv and QueryCounter.
>    Accepted by the <value> parameter of GetBooleanv, GetIntegerv,
>    GetInteger64v, and GetFloatv:
>
>        TIMESTAMP_EXT                                0x8E28

However, I cannot find any reference to GL_TIMESTAMP being a supported pname for GetInteger64v in the GLES3 reference documentation


So I am still confused on whether calling glGetInteger64v with GL_TIMESTAMP as the pname is valid when using GLES3.

Given that mesa is what generated the error on my system, I took a look at the mesa3d source code and I only see the TIMESTAMP enum defined for the GL APIs and not GLES.

Zhenyao Mo

unread,
Sep 15, 2021, 6:15:02 PM9/15/21
to Bryan Angelo, Graphics-dev, Gu, Yang
On Wed, Sep 15, 2021 at 2:40 PM Bryan Angelo <ban...@gmail.com> wrote:
Interesting, thanks.


>    The extension is written against the OpenGL ES 2.0 specification.
>    
>    The GetInteger64vEXT command is required only if OpenGL ES 3.0 or
>    later is not supported (see the Interactions section for details).

And defines the new token for GLES2.

>    Accepted by the <target> parameter of GetQueryiv and QueryCounter.
>    Accepted by the <value> parameter of GetBooleanv, GetIntegerv,
>    GetInteger64v, and GetFloatv:
>
>        TIMESTAMP_EXT                                0x8E28

However, I cannot find any reference to GL_TIMESTAMP being a supported pname for GetInteger64v in the GLES3 reference documentation


Likely the extension spec is written before ES3 is out, but it should apply to ES3 as well. It's not part of the core ES3 spec, that's why you won't find it in the ref page.

 


So I am still confused on whether calling glGetInteger64v with GL_TIMESTAMP as the pname is valid when using GLES3.

Given that mesa is what generated the error on my system, I took a look at the mesa3d source code and I only see the TIMESTAMP enum defined for the GL APIs and not GLES.


At this point I am not sure if the error is in Chrome or Mesa. I am also not sure if it came from the location where you think it came from. Unfortunately I don't have a Linux/Mesa device to test and debug on.

Could you please file an issue at crbug.com and attach your about:gpu info?

+ Intel colleagues. Maybe they can take a look.

Bryan Angelo

unread,
Sep 15, 2021, 6:32:53 PM9/15/21
to Zhenyao Mo, Graphics-dev, Gu, Yang
Hm, I think you are correct and that the issue may be that Mesa does not accept GL_TIMESTAMP as a pname for glGetInteger64v for GLES.

After looking at the Mesa code some more, I opened https://gitlab.freedesktop.org/mesa/mesa/-/issues/5361.

Reply all
Reply to author
Forward
0 new messages