• Locked Locked
  • Replies 4 replies
  • Subscribers 133 subscribers
  • Views 5274 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

FBO with GL_RGB color attachment not supported?

Roger Johannesson
Offline
Note: This was originally posted on 26th October 2011 at http://forums.arm.com

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?
  • Offline
    Note: This was originally posted on 26th October 2011 at http://forums.arm.com

    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
  • Offline
    Note: This was originally posted on 28th October 2011 at http://forums.arm.com

    Hi Doug,

    Thanks for the clarification, I'll use GL_RGBA instead then.
  • Offline
    Note: This was originally posted on 15th March 2012 at http://forums.arm.com

    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.
  • Offline
    Note: This was originally posted on 15th March 2012 at http://forums.arm.com

    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, B) 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