While debugging a performance issue in Chromium, I saw glGetQueryObject(GL_QUERY_RESULT_AVAILABLE) calls blocking for >30ms, preventing Chrome's GPU dispatching process from doing other work. This is on a Pixel XL using a Qualcomm/Adreno GPU.
I confirmed this via adding event trace timing, and the specific slow call was this one:
TRACE_EVENT0("gpu", "glGetQueryObject_GL_QUERY_RESULT_AVAILABLE");
glGetQueryObjectuiv(gl_query_id_, GL_QUERY_RESULT_AVAILABLE, &done);
https://www.khronos.org/registry/OpenGL-Refpages/es3.0/html/glGetQueryOb... strongly implies that this is supposed to be an immediate check, the entire point is to avoid blocking on query objects that aren't ready yet:
GL_QUERY_RESULT_AVAILABLE
params returns whether the passed samples counter is immediately available. If a delay would occur waiting for the query result, GL_FALSE is returned. Otherwise, GL_TRUE is returned, which also indicates that the results of all previous queries of the same type are available as well.
Any ideas what may be going on here? I've seen this effect in other experiments when I was doing a server wait on a context (eglWaitSyncKHR), where I suspect it may be caused by the GL context being blocked due to that server wait, but as far as I know there's no server wait happening here. Is there some other context dependency or specific driver state that could cause this?
Version information:
OpenGLRenderer: HWUI GL Pipeline
Adreno : QUALCOMM build : 7142022, Ib5823dd10c
Adreno : Build Date : 06/23/17
Adreno : OpenGL ES Shader Compiler Version: EV031.18.00.00
Adreno : Local Branch : O11A
Adreno : Remote Branch :
Adreno : Remote Branch :
Adreno : Reconstruct Branch :
Adreno : PFP: 0x005ff087, ME: 0x005ff063
OpenGLRenderer: Initialized EGL, version 1.4
OpenGLRenderer: Swap behavior 2
For the record, I heard back separately from Qualcomm that this is indeed a bug and will be fixed in an upcoming driver release. Qualcomm tracker reference is QC Jira ESX-9218.