*** Original commit ***

Effect: glFlush instead of glFinish on tex output

This is much faster (~2-3x) than glFlush. While there's a risk that GL commands
queued to the GL server may not be complete by the time non-GL commands access
the texture, this should be unlikely as we only access the texture from GL.

If we see stability issues in the future, we can reconsider and move this back
to glFinish (or GL synchronization mechanisms like fences, which are more
complex)

***

PiperOrigin-RevId: 527848094
This commit is contained in:
tofunmi 2023-04-28 12:32:52 +01:00 committed by Marc Baechinger
parent 24343f55af
commit 4b75397f4e

View File

@ -360,13 +360,7 @@ import org.checkerframework.checker.nullness.qual.MonotonicNonNull;
outputTexture.fboId, outputTexture.width, outputTexture.height); outputTexture.fboId, outputTexture.width, outputTexture.height);
GlUtil.clearOutputFrame(); GlUtil.clearOutputFrame();
checkNotNull(defaultShaderProgram).drawFrame(inputTexture.texId, presentationTimeUs); checkNotNull(defaultShaderProgram).drawFrame(inputTexture.texId, presentationTimeUs);
GLES20.glFinish();
// glFlush is used here instead of glFinish due to the performance regression that blocking this
// thread would do when calling glFinish. As glFlush is non-blocking, it's possible that non-GL
// access to the output texture may read stale data (ex. from the prior frame). If we see issues
// (ex. flakiness) from glFlush, consider requiring apps reading the texture to call glFinish,
// or reconsider using glFinish here.
GLES20.glFlush();
checkNotNull(textureOutputListener).onTextureRendered(outputTexture, presentationTimeUs); checkNotNull(textureOutputListener).onTextureRendered(outputTexture, presentationTimeUs);
} }