• Locked Locked
  • Replies 11 replies
  • Subscribers 136 subscribers
  • Views 10655 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

Screen Dark working with FBOs

enzo sacchi
Note: This was originally posted on 7th November 2010 at http://forums.arm.com

Hi Guys,

Trying to port an akready well running Sw from Fedora PC to the Mali400 on ST7108 chip, with GLES-2.0, I got a problem working with Framebuffer Objects.
Everything is ok, debugging ok, framebuffer objects completes, no errors, but the screen remains completely dark.
My environment on Mali/ST7108 is OK, other applications can run nicely.

But I think to have not completely understood (or better: not understood at all) how to set display and surfaces while working woth FBOs (maybe the problem could be also found somewhere else)

Basic setting is more or less as below, where I have put only the relevant setting and call for Display and Surfaces.

In does seem that the eglSwapBuffers does't work at all while working with FBOs
(even a monocolor screen cannot be seen...).
In contrast, while working out of FBOs, everything seems to be ok.

After binding with glBindFramebuffer(GL_FRAMEBUFFER,0), then everything is working and can be displayed.

In contrast, after glBindFramebuffer(GL_FRAMEBUFFER, framebuffer), I cannot see anything after he eglSwapBuffers, even if the debug seems to be ok.

Could someone pls help me in giving me suggestions on how to properly set Display and Surfaces?
Does there is a running examples while using FBOs on ST7108 chip?
Thanks a lot in advance for this
(here below I have just put a rough skeleton of the used code)

"
EGLDisplay eglDisplay = 0;
EGLSurface eglSurface = 0;
EGLint major, minor, num_configs;

..........
eglDisplay = eglGetDisplay(EGL_DEFAULT_DISPLAY));

eglInitialize(eglDisplay, &major, &minor);
eglBindAPI(EGL_OPENGL_ES_API);

eglChooseConfig(eglDisplay, configAttribs, &eglConfig, 1, &num_configs);

eglSurface = eglCreateWindowSurface(eglDisplay, eglConfig, NULL, NULL);
eglContext = eglCreateContext(eglDisplay, eglConfig, NULL, contextAttribs)));
eglMakeCurrent(eglDisplay, eglSurface, eglSurface, eglContext);
...........
...........


egl_setup(&eglDisplay,&eglSurface);


GLuint framebuffer;
GLuint depthRenderbuffer;
GLuint texture;

.....

glGenFramebuffers(1, &framebuffer);
glGenRenderbuffers(1, &depthRenderbuffer);
glGenTextures(1, &texture);
glBindTexture(GL_TEXTURE_2D, texture);
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB, texWidth, texHeight, 0, GL_RGB, GL_UNSIGNED_SHORT_5_6_5, NULL);


glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);

glBindRenderbuffer(GL_RENDERBUFFER, depthRenderbuffer);
glRenderbufferStorage(GL_RENDERBUFFER, GL_DEPTH_COMPONENT16, texWidth, texHeight);

glBindFramebuffer(GL_FRAMEBUFFER, framebuffer);

glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_TEXTURE_2D, texture, 0);

glFramebufferRenderbuffer(GL_FRAMEBUFFER, GL_DEPTH_ATTACHMENT, GL_RENDERBUFFER, depthRenderbuffer);

Switch (glCheckFramebufferStatus(GL_FRAMEBUFFER))
{
case GL_FRAMEBUFFER_COMPLETE:
fprintf(stdout, "\n o Framebuffer Complete");
break;
......
}


GLCheckError(glClearColor(1.0f, 0.0f, 0.0f, 1.0f));
.....
eglSwapBuffers(eglDisplay, eglSurface);


// glBindFramebuffer(GL_FRAMEBUFFER,0);
.........

eglSwapBuffers(eglDisplay, eglSurface);
""


Many Thanks
Parents
  • Note: This was originally posted on 13th September 2011 at http://forums.arm.com


    Without knowing more about what you're trying to do or what hardware you're using it's hard to really answer this. It sounds like you might be using the texture in the scene with the FBO still bound, so it's trying to write to the framebuffer using content from the frame buffer. Is that what you're doing?


    It doesn't require a depth or stencil buffer but if you want to use depth or stencil features you'll need to have one bound.


    There are certain actions with frame buffers  (such as binding an FBO to a texture and renderbuffer simultaneously, which it sounds like you might be doing) which have undefined or poorly defined behaviours in the spec. Depending on your GPU (or more specifically how strict the drivers are) some things will error, others will fail silently and simply have that texture appear messed up.

    I can't really give a more specific answer without details of what you're doing...

    -Stacy


    Hi Stacy!

    Thanks for your reply. I was able to solve this on my own. Apparently Mali requires that you specify the data type GL_UNSIGNED_SHORT_5_6_5 when creating an empty texture object rather than GL_UNSIGNED_BYTE.

    I'm still left with the other problem I described in the other thread if you would care to address that. For that one I've provided you with some sample code that works on other hardware.

    Cheers...


Reply
  • Note: This was originally posted on 13th September 2011 at http://forums.arm.com


    Without knowing more about what you're trying to do or what hardware you're using it's hard to really answer this. It sounds like you might be using the texture in the scene with the FBO still bound, so it's trying to write to the framebuffer using content from the frame buffer. Is that what you're doing?


    It doesn't require a depth or stencil buffer but if you want to use depth or stencil features you'll need to have one bound.


    There are certain actions with frame buffers  (such as binding an FBO to a texture and renderbuffer simultaneously, which it sounds like you might be doing) which have undefined or poorly defined behaviours in the spec. Depending on your GPU (or more specifically how strict the drivers are) some things will error, others will fail silently and simply have that texture appear messed up.

    I can't really give a more specific answer without details of what you're doing...

    -Stacy


    Hi Stacy!

    Thanks for your reply. I was able to solve this on my own. Apparently Mali requires that you specify the data type GL_UNSIGNED_SHORT_5_6_5 when creating an empty texture object rather than GL_UNSIGNED_BYTE.

    I'm still left with the other problem I described in the other thread if you would care to address that. For that one I've provided you with some sample code that works on other hardware.

    Cheers...


Children
No data