Porting a mali_egl_image* Utgard application to Midgard

Hi all

We are currently migrating an embedded application from a Mali 400MP2 Utgard platform to one with a Mali T720 Midgard GPU. The application uses the following (probably fairly common) mali_egl_image* code to achieve zero-copy update of a texture:

EGLImageKHR eglImage = eglCreateImageKHR( display, EGL_NO_CONTEXT, EGL_NATIVE_PIXMAP_KHR, (EGLClientBuffer)(&fbPixMap), NULL );
glEGLImageTargetTexture2DOES(GL_TEXTURE_2D, eglImage);
...
...
mali_egl_image *mimg = mali_egl_image_lock_ptr( eglImage );
unsigned char *buffer = mali_egl_image_map_buffer( mimg, attribs_rgb );

// update buffer here

mali_egl_image_unmap_buffer( mimg, attribs_rgb );
mali_egl_image_unlock_ptr( eglImage );

These mali_egl_image_* functions do not appear to be available in the mali_midgard driver we received from our chip vendor.

Our application is written in C with, apart from the above, standard openGL ES2 calls.

What would be the equivalent approach for updating a texture directly (ie not using glTexSubImage2D() ) with the T720 Midgard driver? Thankfully the above code exists in a single function and called from many places, so ideally a direct replacement would be fantastic!

Regards

Chris

Parents
  • Hi Chris,

    It appears you found an Utgard extension to speed up your image access that was never publicly released! So it is probably distinctly uncommon. It took a little tracking down, but I found someone who remembers its implementation.

    The extension was to cover issues in Utgard, of a slow bus and slow memcpy translation to GPU memory formats, that have long been solved. This means that most options for fixes that will work in Midgard will be faster.

    EGL Pixmaps are now very out of date, and indeed pixmaps are to be avoided if possible - better to use a more GPU friendly format. So rather than importing a pixmap surface handle /creating a pixmap surface and then promoting it to a GLES texture through the EGL Image interface, you're best either (depending on what the app is doing) replacing the EGL Pixmap/EGL Image setup using a normal texture or using eglCreateWindowSurface to use a window surface instead of a pixmap surface.

    Then replace the Mali EGL Image interface block with glTexSubImage2D.  More specifically - if you don't even want direct access but just want to modify the image without reallocating it, glTexSubImage is best. If you don't even care if it's reallocated and want to replace all the image data, glTexImage is even faster as you avoid any existing data dependencies.

    The Mali EGL Image interface does have some locking scheme - it is possible you may need some EGL fences if this is relied upon.

    Hope this solves your issue, it's been a very interesting history lesson finding this out!

Reply
  • Hi Chris,

    It appears you found an Utgard extension to speed up your image access that was never publicly released! So it is probably distinctly uncommon. It took a little tracking down, but I found someone who remembers its implementation.

    The extension was to cover issues in Utgard, of a slow bus and slow memcpy translation to GPU memory formats, that have long been solved. This means that most options for fixes that will work in Midgard will be faster.

    EGL Pixmaps are now very out of date, and indeed pixmaps are to be avoided if possible - better to use a more GPU friendly format. So rather than importing a pixmap surface handle /creating a pixmap surface and then promoting it to a GLES texture through the EGL Image interface, you're best either (depending on what the app is doing) replacing the EGL Pixmap/EGL Image setup using a normal texture or using eglCreateWindowSurface to use a window surface instead of a pixmap surface.

    Then replace the Mali EGL Image interface block with glTexSubImage2D.  More specifically - if you don't even want direct access but just want to modify the image without reallocating it, glTexSubImage is best. If you don't even care if it's reallocated and want to replace all the image data, glTexImage is even faster as you avoid any existing data dependencies.

    The Mali EGL Image interface does have some locking scheme - it is possible you may need some EGL fences if this is relied upon.

    Hope this solves your issue, it's been a very interesting history lesson finding this out!

Children
More questions in this forum