EGLImages with renderbuffer as source sibling and texture as target sibling

Question

I am trying to setup an EGLImage where the source sibling is a GL_RENDERBUFFER (the EGLClientBuffer specified as an argument to eglCreateImageKHR). In another context, I create a GL_TEXTURE_2D and specify it as the target sibling of the EGLImage by using glEGLImageTargetTexture2DOES. Unfortunately, the latter call leads to a GL_INVALID_OPERATION. If both the source and target siblings are GL_TEXTURE_2D's, the setup works like a charm.

From my reading of the specification, this should be a permissable operation. It is also possible that my reduced test case has some other orthogonal issue. Though I doubt this since the setup works fine when both the source and target siblings are GL_TEXTURE_2D's. However, if this were the issue (and this kind of usage of EGLImages was permissable), what could be the possible issue that may lead to to a GL_INVALID_OPERATION. Or am I just mistaken in my interpretation of the specification?

Referenced Extensions:

http://www.khronos.org/registry/gles/extensions/OES/OES_EGL_image.txt

http://www.khronos.org/registry/egl/extensions/KHR/EGL_KHR_image_base.txt

Clarifications:

• I do check for the presence of all extensions in the specification (EGL_KHR_image, EGL_KHR_image_base, EGL_KHR_gl_texture_2D_image, EGL_KHR_gl_renderbuffer_image, etc..).
• I also realize that there may be differences in the internal format of the EGLImage when I am using a GL_RENDERBUFFER vs a GL_TEXTURE_2D as the source. So I tried using the OES_EGL_image_external extension first with the texture as the source and then the renderbuffer. The texture works fine as always, the same GL_INVALID_OPERATION for the renderbuffer. Using external images when binding makes no difference to the error generated.
• Both GL and EGL errors are checked after each call.

Answer 1

I spent a lot more time on this and EGLImage's in general after running into this issue. alonorbach's hypothesis was correct.

If for any reason, the driver cannot create a texture sibling from the supplied EGLImage, then a rather ambiguous GL_INVALID_OPERATION is returned. I was under the impression that if I was able to create a valid EGLImage (i.e., not an EGL_NO_IMAGE_KHR) and the appropriate extensions were supported, I would be able to bind to the same using either a rendebuffer or texture sibling (in GL_OES_EGL_image). This is certainly not the case. It also seems to vary a lot from device to device. I was able to get this working on NVidia Tegra units but not on the Adreno 320.

Does this mean it is impossible to reliably use EGLImages on Android? Not quite. Specifically for the issue I was running into, I was able to bind a texture sibling to an EGLImage created using a renderbuffer source by specifying GL_RGBA8_OES in extension GL_OES_rgb8_rgba8 as the internal format of the source renderbuffer (argument 2 to glRenderbufferStorage). This is less than ideal but proves the point that somehow the internal formats of the source and target siblings must match, and, in case of a mismatch, the driver is under no obligation to accomodate the variation and is free to give up.

Another source of entropy when trying to use EGLImages successfully (at least generically on Android) is the way in which the EGLImages themselves are created. I found that it was far more reliable to create an EGLImage using the EGL_NATIVE_BUFFER_ANDROID target specified in the EGL_ANDROID_image_native_buffer extension. If such extensions are available for your platform, it is highly advisable to use them in a fallback manner.

In summary, the solution that seems to work reliably for me seems to be to first try and create a valid EGLImage using any and all available extensions in a fallback manner. Then using that EGLImage try binding to the target sibling kind. If this pair of operations yields no errors, then that EGLImage/TargetKind pair is supported on that device and can be used for subsequent operations. If either operation fails, the next item in the fallback chain is checked. If all else fails, a solution that does not use EGLImages should likely be present. I have not encountered such an Android device yet (fingers crossed)

I am still discovering corner cases and optimizations and will keep this answer updated with findings.

Answer 2

I'm afraid this could be a legitimate failure point. A GL_INVALID_OPERATION error can arise if the driver is unable to create a texture from the EGLImage supplied.

http://www.khronos.org/registry/gles/extensions/OES/OES_EGL_image.txt

If the GL is unable to specify a texture object using the supplied eglImageOES (if, for example, refers to a multisampled eglImageOES), the error INVALID_OPERATION is generated.

Do you call glFramebufferRenderbufferOES with the renderbuffer before passing it to eglCreateImageKHR? If so, suggest you try tweaking how your create your renderbuffer (e.g. try a different format, size) to pin down what conditions get you this error.