Is this not the correct approach to asynchronous texture loading on Android?
> Is this not the correct approach to asynchronous texture loading on Android?
Why do you need EGLImages for asynchronous upload? Assuming the source textures are coming from another thread in the application then OpenGL ES already allows you to upload data in one context and use it an another, provided that they are in the same share group.
In addition OpenGL ES 3.0 now includes support for Pixel Buffer Objects (PBOs) which can be used to implement asynchronous upload. OpenGL ES 3.0 is still relatively new, but all of the Mali-T600 and later GPUs support it, and it is supported in the new Android versions found in the Nexus 10 and Galaxy Note 3.
*EDIT* Footnote - we do still support EGLImages in the driver. It's not entirely clear from your post what you have tried and what isn't working.
Hope that helps,
Pete
EGLImage was given as a recommended option for loading dynamic textures ( I would assume that is why the example was added to the SDK ). If this is not the correct course of action, then the example should be removed from the SDK and a notice placed on all previous examples stating this is not the recommended means of achieving asynchronous texture loading. Using PBOs is not a options sometimes since the majority of ES devices out there are not 3.0 compatible. I've just added support for dynamic texture uploads via EGLImage to my rendering framework, since it was somewhat easy to drop in. However, the next step is to add support using a shared context. With that said, if EGLImage is not the recommended way, then an alternative using on of your suggested approach should be added to the SDK to aid developers to utilize the hardware efficiently and correctly.
> If EGLImage is not the recommended way,
EGLImages are still a good way of doing it - PBOs provide the same type of functionality in core OpenGL ES so you avoid a dependency on EGL providing the functionality. I was really just trying to point out that EGLImages are not the only option for asynchronous data transfer on current generation devices all three methods do much the same work at the end of the day - it is really just API nicety in terms of how you can access the functionality.
As Johnathan has mentioned as far as we are aware the EGLImage example in the SDK is still there, so have we answered your original question?
Regards, Pete
Hi cgrant78,
I would just add that EGLImage is useful for more than just asynchronous upload, for example making image data available to GLES from external sources such as a camera, so its inclusion in the SDK doesn't depend only on its relevance to uploading textures asynchronously.
Hope this helps,
Chris
Sorry, apparently I hadn't signed up for notifications, so I didn't realize anyone had answered me. This is all great info. I think I confused the Linux SDK with the Android SDK, and I got worried that there's some issue with EGLImage -- my mistake.
I've tried context sharing before, but I'm under the impression that it isn't universally supported, and I still need to support OpenGL ES 2.0 for now. I'll be looking into PBOs for the future though.
Thanks to everyone for their thoughtful replies.
Ah..yeah..thanks Chris..I did overlook the other aspects of EGLImage.