Forums - OpenGL ES 3 Rendering Glitch "The buffer is mapped"

1 post / 0 new
OpenGL ES 3 Rendering Glitch "The buffer is mapped"
Join Date: 30 Sep 19
Posts: 1
Posted: Thu, 2019-10-03 23:56


I'm porting a desktop OpenGL 3.2 Core based application to mobile GL ES 3.0. Everything seems fine on desktop, and mostly on mobile. However, there are a few cases where the mobile driver seems to be having trouble. Nothing is causing an issue via glGetError() but is seems the entire contents of my rendering pass seems to be ignored. I found that using the glDebugMessageCallbackKHR results in a message of

"The buffer is mapped" but no other details. Despite using


the error appears to be printed on the first drawcall of the frame, rather then the actual source error.

Driver Info:
019-10-04 16:43:04.390 3991-4045/<packagename>I/Adreno: QUALCOMM build                   : 7ff4f54, I4460aa6217
    Build Date                       : 12/30/18
    OpenGL ES Shader Compiler Version: EV031.25.03.02
    Local Branch                     : 
    Remote Branch                    : 
    Remote Branch                    : 
    Reconstruct Branch               : 
2019-10-04 16:43:04.390 3991-4045/<packagename> I/Adreno: Build Config                     : S P 6.0.7 AArch32
2019-10-04 16:43:04.393 3991-4045/<packagename> I/Adreno: PFP: 0x016ee176, ME: 0x00000000
It does appear to be related to a buffer being mapped because if I change some code that generates dynamic geometry to not use a mapping, but instead just a system memory CPU copy and then a call to glBufferData() at the end, the issue goes away. I'm reasonably confident we're not trying to render with the buffer while it is mapped, and no other hardware (desktop or mobile) appears to have the same issue. But I'd like to know what exactly is going on. My theory is that maybe some internal buffer for tiled processing is filling up and we're trying to flush, but we can't because the driver hasn't yet processed the call to glUnmapBuffer().
(I do hope to be able to port to Vulkan soon, but for right now OpenGL ES is the way we have to proceed)
  • Up0
  • Down0

Opinions expressed in the content posted here are the personal opinions of the original authors, and do not necessarily reflect those of Qualcomm Incorporated or its subsidiaries (“Qualcomm”). The content is provided for informational purposes only and is not meant to be an endorsement or representation by Qualcomm or any other party. This site may also provide links or references to non-Qualcomm sites and resources. Qualcomm makes no representations, warranties, or other commitments whatsoever about any non-Qualcomm sites or third-party resources that may be referenced, accessible from, or linked to this site.