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

Mali T604 and eglImageKHR and FBO

Note: This was originally posted on 12th June 2013 at http://forums.arm.com

Hi,

i'm implementing an Android application using the GPU and especially ImageKHR and FrameBuffer Objects.
In a thread and its GLES context i'm creating a texture and its eglImageKHR then i share the eglImageKHR handle with another thread. In this second thread i'm creating a FrameBuffer Object with the given eglImageKHR as color buffer and a renderbuffer (for the depth) . Then from this second thread i'm drawing using openGLES 1.x commands into the just created FBO. The result is displayed on screen by the First thread.

All that is working well with a MALI-400 but running that application on a nexus 10 which use MALI-T604 i have some issue.
1- NO GL ERROR appear.
2- the FBO status is OK

but the screen is sometime OK sometime completely black.

I try to replace the drawing operation by a simple clear color where the color is changing at each call and sometime i can see part of the screen with a color and part that is black.

Is someone aware of differences between MALI-400 and MALI-T604 that could cause such kind of issue. unfortunately i do not have any documentation on T604 to really understand what is happening. I tried to enable auto MIMAP generation in case of T604 as for (NVidia GPU it was a mandatory condition the make the texture "complete") but nothing has changed.

I suspect that it is coming from ImageKHR because i have a JAVA application where i'm uising FBO without ImageKHR and it seems to work fine.

Here is the sequence to create the FBO with EGLImageKHR:
glGenFramebuffersOES(1, (GLuint*) 0x777ada1c);
glBindFramebufferOES(GL_FRAMEBUFFER_OES, 1);

glGenRenderbuffersOES(1, (GLuint*) 0x777ada1c);
glBindRenderbufferOES(GL_RENDERBUFFER_OES, 1);

glRenderbufferStorageOES(GL_RENDERBUFFER_OES, GL_DEPTH_COMPONENT16_OES, 1184, 694);
glFramebufferRenderbufferOES(GL_FRAMEBUFFER_OES, GL_DEPTH_ATTACHMENT_OES, GL_RENDERBUFFER_OES, 1);

glGenTextures(1, (GLuint *) 0x777ada0c);
glBindTexture(GL_TEXTURE_2D, 3);
glEGLImageTargetTexture2DOES(GL_TEXTURE_2D, (GLeglImageOES) 0x752d700c);

glFramebufferTexture2DOES(GL_FRAMEBUFFER_OES, GL_COLOR_ATTACHMENT0_OES, GL_TEXTURE_2D, 3, 0);

glCheckFramebufferStatusOES(GL_FRAMEBUFFER_OES);

I hope someone will be able to help me to understand what i'm missing .

Br

Seb

Parents

Peter Harris over 11 years ago

Note: This was originally posted on 24th July 2013 at http://forums.arm.com

Some initial thoughts ...

I assume each thread has it's own GLES context, and you are trying to get some kind of streaming load working?

Exchange of surface and buffer data across contexts in GLES is not automatically synchronized; each context gets its own command stream and it will only be synchronized against other command streams if you force it to be so. Do you have any synchronization in your application to ensure the glCopyTex call has actually run before you use the image in the other thread?

As a simple test if you insert a glFinish after the call to glCopyTex, and only use the EGL image in the other thread after that call has completed, does it work correctly? You can build something as a non-blocking equivalent using EGL fences (although it does require the consumer thread to poll or wait on the fence object).

As a footnote - if you could cut down your application into a standalone test case it does make it much easier for us to help - the devil in most cases is in the detail, and if we can't see exactly what you are doing it is often very hard to reproduce, especially in cases with multiple contexts or threads!

HTH, Iso
Cancel
Up 0 Down

Cancel

Reply

Peter Harris over 11 years ago

Note: This was originally posted on 24th July 2013 at http://forums.arm.com

Some initial thoughts ...

I assume each thread has it's own GLES context, and you are trying to get some kind of streaming load working?

Exchange of surface and buffer data across contexts in GLES is not automatically synchronized; each context gets its own command stream and it will only be synchronized against other command streams if you force it to be so. Do you have any synchronization in your application to ensure the glCopyTex call has actually run before you use the image in the other thread?

As a simple test if you insert a glFinish after the call to glCopyTex, and only use the EGL image in the other thread after that call has completed, does it work correctly? You can build something as a non-blocking equivalent using EGL fences (although it does require the consumer thread to poll or wait on the fence object).

As a footnote - if you could cut down your application into a standalone test case it does make it much easier for us to help - the devil in most cases is in the detail, and if we can't see exactly what you are doing it is often very hard to reproduce, especially in cases with multiple contexts or threads!

HTH, Iso
Cancel
Up 0 Down

Cancel

Children

No data