[SuneT]

Driver info:
EGL_VENDOR: ARM
EGL_VERSION: 1.4 Linux-r2p0-05rel0
GL_RENDERER: Mali-400 MP

Sample code:

GLuint texHandle;
GLuint fboHandle;
GLenum format = GL_RGB;

glGenTextures(1, &texHandle);
glBindTexture(GL_TEXTURE_2D, texHandle);
glTexImage2D(GL_TEXTURE_2D, 0, format, width, height, 0, format, GL_UNSIGNED_BYTE, NULL);

glGenFramebuffers(1, &fboHandle));
glBindFramebuffer(GL_FRAMEBUFFER, fboHandle));
glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_TEXTURE_2D, texHandle, 0);

GLenum res = glCheckFramebufferStatus(GL_FRAMEBUFFER);

If I set format to GL_RGBA, the framebuffer status is GL_FRAMEBUFFER_COMPLETE
If I set format to GL_RGB instead, the framebuffer status is GL_FRAMEBUFFER_UNSUPPORTED

So, does this mean that mali does not support rendering to GL_RGB textures? And if so, is support for it implemented in newer driver versions?

[Doug Day]

Hi,

In your example, you are trying to create a framebuffer object with RGB of 8-bits per channel. Mali doesn't support this because of memory alignment issues that would impact performance.

It would be better to either try rendering to RGB (565) or, for more precision, use RGBA (8 bit per channel) and just ignore the alpha channel (assuming you don't need it).

Best regards,
Doug

[SuneT]

Hi Doug,

Thanks for the clarification, I'll use GL_RGBA instead then.

[Habba]

Sorry to dig up this topic after it has been solved, but I have a question regarding this same issue.

Even though GL_RGB could be considered evil, how is it that it is not supported? More importantly, how am I, as an android developer, to know that GL_RGB is not supported?

I thought that supporting GL_RGB is part of the OpenGL ES 1.1 standard, because it's listed as an accepted value here. I may be wrong, since I'm not an OpenGL ES expert.

[KarthikH]

Hi Habba,

Framebuffer object support is a GLES extension that is defined here. If you look towards the end, the document states which formats are required and optional. It clearly mentions that RGB8_OES (sized internal format) is optional.

As Doug mentioned previously, having a 24 bit format causes memory alignment issues. When reading a texel from memory, we would always have to read four bytes (R,G,B,R) with only three (R, G, being used. Also, if you need to read the next texel, you would have to read 8 bytes (R from the previous four bytes and next four - G,B,R,G). This is rather inefficient and will cause unnecessary bandwidth on the system. As a result the best formats would either be a 16 bit or a 32 bit format depending on the precision required.

Please let me know if you need any more clarifications.

Best Regards
Karthik