OpenGL ES Performance on MX31

Hi,

On comparing the performance of

  1. drawing a texture quad to a native display (glTexSubImage+glDrawArrays+eglSwapBuffers)

to

  1. Drawing a pixel buffer directly to the framebuffer without using any opengles

there was a VERY noticable difference. The direct draw to framebuffer was 3 times faster. Is there any way to tweak and optimize (1). What could be the cause of delay? Does a texture upload involve some inter process communication?

Thanks for your help.

How do you measure the time? What size is the rectangle you’re copying to the screen?

It’s extremely unlikely that the first method would be faster than the second, since it involves at least two copies: glTexSubImage copies from application memory to texture memory, and the renderer reads from texture memory and writes to the frame buffer.

In addition, texture upload is not just a straight copy. The texture data gets reformatted to optimize memory access patterns.

Why exactly are you using OpenGL ES?

How do you measure the time?

In ms… using a tick count i suppose

What size is the rectangle you’re copying to the screen?
800x480

It’s extremely unlikely that the first method would be faster than the second

I understand, but I dont think it should be three times(ogles texture upload(glSub2D+glDrawArrays+eglSwapBuffers)-150ms, memcpy to framebuffer-50ms).

The texture data gets reformatted to optimize memory access patterns.

What can we do to minimize the processing here?

Why exactly are you using OpenGL ES?

Fast and complicated animations on an ARM device.

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.