glTexSubImage2D killed the performance in my 2D game

[Eric Wang]

Hi,

I rendered the game frame in native code, and send the pixels to screen via glTexSubImage2D as below:

gl.glTexSubImage2D(GL10.GL_TEXTURE_2D, 0, 0, 0, 320, 480,

GL10.GL_RGB, GL10.GL_UNSIGNED_SHORT_5_6_5, sBuff); // sBuff updated in native side which is short[320*480]

By now, I got 38 FPS(only draw a single image(320x480) in native code). If I change the 480 into 120 in glTexSubImage2D, the FPS increased to 61. So, my question is, copying 320*(480-120) more 16bits pixels reduced the FPS from 61 to 38? How can I optimize it?

[Jack Palevich]

This is just a guess, but you might be running into an issue where the OpenGL ES driver is stalling waiting for the GPU to finish using the texture before updating it. Try double-buffering or triple-buffering the texture. (Create two or three copies of the texture, and use them in a cycle, so that the GPU can be using the old version of the texture to draw frame "N" while the CPU is updating the texture used to draw frame N + 1. In desktop OpenGL drivers the driver does this for you automatically, but in OpenGL ES drivers I think you're expected to do it manually.

...I am sorry to say that I have not done extensive driver analysis, so I don't know exactly how the driver behaves in this situation.

You might also want to read through this presentation and see if it provides any hints for your application:

http://www.khronos.org/developers/library/sf_2005/opengles_general/Imagination_A-to-Z-of-OpenGL-ES.ppt

--

You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to andro...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.

[Pradip Bhattacharya]

Hi Eric,
Here is my analysis of your problem,
Time required to render frames (approx)

38 FPS => 26 ms (320x480 = 153600 pixels)
61 FPS => 16 ms (320x120 = 38400 pixels)

There is difference of
153600 - 38400 = 115200 pixels which is lowering the FPS.

It seems you had a drop of 26-16=10 milliseconds. I think this is
pretty ok as compared of data being used to render. I can be wrong
because I dont know what else is going around in the application. Try
using glDrawElements to draw a textured quad in ortho view.

[Eric Wang]

Thanks to Jack and Pradip. By now, I use canvas and mutable bitmap to update my frame buffer to screen, and I can get 61 fps. But maybe it is not the fastest, I will try glDrawElements as Pradip said later.

在 2009 年 11 7 日，4:32 上午，"Pradip Bhattacharya" <pradip.bh...@gmail.com>编写：

Hi Eric,
Here is my analysis of your problem,
Time required to render frames (approx)

38 FPS =>  26 ms  (320x480 = 153600 pixels)
61 FPS =>  16 ms  (320x120 = 38400 pixels)

There is difference of
153600 - 38400 = 115200 pixels which is lowering the FPS.

It seems you had a drop of 26-16=10 milliseconds. I think this is
pretty ok as compared of data being used to render. I can be wrong
because I dont know what else is going around in the application. Try
using glDrawElements to draw a textured quad in ortho view.

On Nov 5, 4:36 am, Eric Wang <eric.wan...@gmail.com> wrote: > Hi, > > I rendered the game frame in ...

-- You received this message because you are subscribed to the Google Groups "android-ndk" group. T...