OpenGL ES 2.0, FBO, low performance

Started by
5 comments, last by L. Spiro 9 years, 9 months ago

Hi

I added FBO support but looks like the performance is much lower than I expected. I'm using two screens (scene rendered for two cameras). Without FBO I have 55 fps. After adding it (texture 1024x768) - it's only 26 fps.

I also checked different configurations:

1. "Slower" - scene rendered 4 times + 2 quads with texture:

Camera1 to FBO1

Camera2 to FBO2

Screen1: Camera1 - fullscreen, Camera2 - FBO2, shown on small quad

Screen2: Camera2 - fullscreen, Camera1 - FBO1, shown on small quad

Results (for different texture size):

256x256 - 50 fps
1024x768 - 30 fps
2048x2048 - 9 fps

2. "Faster" - scene rendered 2 times + 4 quads with texture:

Camera1 to FBO1

Camera2 to FBO2

Screen1: Camera1 - FBO1, fullscreen, Camera2 - FBO2, shown on small quad

Screen2: Camera2 - FBO2, fullscreen, Camera1 - FBO1, shown on small quad

256x256 - 43 fps
1024x768 - 23 fps
2048x2048 - 8 fps

I'm using device with Vivante gc2000.

Part of code:


// ## rendering to texture1 ##:

glViewport(0, 0, 1024, 768);
glBindFramebuffer(GL_FRAMEBUFFER, m_FBO);
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);

// drawing scene

glBindFramebuffer(GL_FRAMEBUFFER, 0);
glViewport(0, 0, 1024, 768);

// ## rendering to texture2 ##:
// (performed for 2nd FBO)


eglMakeCurrent(...);// setting screen1
// drawing fullscreen quad with FBO1
// drawing small quad with FBO2
eglSwapBuffers(...);// for screen1

eglMakeCurrent(...);// setting screen2
// drawing fullscreen quad with FBO2
// drawing small quad with FBO1
eglSwapBuffers(...);// for screen2

Do I need to change/add something or the device is not enough fast for using FBO?

Advertisement

Have you tried with a power of 2 size texture? Say, 1024x1024. It shouldn't matter on desktop hardware but in embedded it might.

"I AM ZE EMPRAH OPENGL 3.3 THE CORE, I DEMAND FROM THEE ZE SHADERZ AND MATRIXEZ"

My journals: dustArtemis ECS framework and Making a Terrain Generator

I tried for 1024x1024 - 22 fps and 512x512 - 36 fps.

I also checked it for single FBO (still rendering twice, the same amount of bind/unbind operations etc.) - 30 fps instead of 23 (1024x768). Strange. Maybe if we use another buffer, the data needs to be moved somewhere and we have performance loss?

FPS should not be used as development performance metric. Have you tried getting the actual CPU time incurred by the FBO issue?

Looks like the rendering takes only small part of each frame. I'm loosing ~90% of performance because of using eglMakeCurrent funcion in each frame (twice).

Drawing scene - 1-2ms, eglMakeCurrent - 10-20ms.

I found info that better not to use it so often but I need to draw on two screens.

I don't think you should be using two contexts. You should probably be using a single context, two off screen FBOs to textures, and then compositing both FBOs to the actual context render buffer.

SlimDX | Ventspace Blog | Twitter | Diverse teams make better games. I am currently hiring capable C++ engine developers in Baltimore, MD.
I second the above.
There is no reason to have 2 contexts in this situation—at most you have 1-per-thread and in any case you set the context(s) as active once and then never mess with it/them again.

The number of screens has no relationship with the number of contexts you should have. Especially considering that if you have only 1 thread (as you do) then there is nothing you can do on that thread with 2 contexts that you can’t do with only 1—the 2nd context is superfluous.


L. Spiro

I restore Nintendo 64 video-game OST’s into HD! https://www.youtube.com/channel/UCCtX_wedtZ5BoyQBXEhnVZw/playlists?view=1&sort=lad&flow=grid

This topic is closed to new replies.

Advertisement