we ported an application to use OpenGL 2.0es (from legacy OpenGL). when enabling angle (that will convert the calls to DirectX), we incur severe performance penalty.
On profiling the code:
glDrawArrays on angle takes about 200ms as opposed to about 10 ms when running without angle.
The display is sluggish.
Also if we draw the same object (that is do not bind different buffers, generally this is the only state we change), then the performance increases and the display is not sluggish.
Has anybody else come across a similar issue and any tips on how to solve this
I tried using glcalllist but it will not work with angle (its not part of QOpenGLFunctions)
Random guess (there’s just not enough information about how you specify your vertex data or setup state for your draw calls for anything else): I suspect you (unintentionally perhaps?) store your vertex data in CPU memory and Angle has to copy it to a GPU buffer on every draw. Are you calling glVertexAttribPointer with an actual pointer to some CPU memory as opposed to having an OpenGL Buffer Object bound to GL_ARRAY_BUFFER and passing the offset from the start of the buffer object as last argument to glVertexAttribPointer?
Are you using the Direct3D 9 or Direct3D 11 backend? Direct3D 9 had very slow draw calls, so you would have to batch quite aggressively; a combination of Direct3D 9 plus lots of draw calls will cause this kind of performance loss.
Hi, I have this problem with d3d9 and d3d11, also I use glbindbuffer to bind to GL_ARRAY_BUFFER and then use glVertexAttribPointer with the required offsets values (no copying from CPU to GPU). The code runs fine (smooth) without angle, but with angle, it is sluggish.
Also:
If pointer is not NULL, a non-zero named buffer object must be bound to the GL_ARRAY_BUFFER target (see glBindBuffer), otherwise an error is generated. pointer is treated as a byte offset into the buffer object’s data store. (this is for GL4) , I believe that gl2es allows us to pass CPU memory
I would have been surprised if using CPU memory was the cause - you wouldn’t have had that much performance drop from it.
You’re doing something that’s legal in the GL ES spec but is tripping up Direct3D, so it’s a bit of a guessing game to try determine what exactly.
Are you updating VBOs dynamically? If so, how? Depending how, you might be putting Direct3D down a path where it destroys and creates new buffers for each update; that’s the kind of behaviour that might cause this kind of performance drop.
Hi,
I am cooking up a small sample, I am guessing that it might be due to a large uniform being passed to it. I even tried using the call list, but that being part of legacy opengl “only”, angle would not be able to use this.
I ran renderdoc, it seems to be creating element buffer every time the array buffer is changed. I have now changed my code to create & use the element buffer.
I am going to test this, will keep you all updated
