Hi,
I've just noticed that texture lookups using samplerExternalOES (as specified in the OES_EGL_image_external extension) seem to come with a performance impact on Mali-400, at least if the instruction counts reported by Mali Offline Compiler are correct.
While a texture2D sampler lookup takes 1 cycle, the Mali Offline compiler reports the following for a samplerExternalOES access:
Number of instruction words emitted: 5Number of cycles for shortest code path: 2Number of cycles for longest code path: 5
Could someone shed some light on why accessing a samplerExternalOES would be so expensive?
How can I ensure that the fast path is hit (2 cycles)?
Is there a - perhaps less flexible - alternative to OES_EGL_image_external, which would allow for zero-copy textures without this overhead?
Could the cycle counts just be misreported by the Mali Offline Compiler?
External samplers require support for sampling from YUV camera or video data sources, and Mali uses shader-based color conversion to convert from YUV to RGB. The shortest path will be used when sampling from RGB external images, the longest path will be used when sampling from YUV external images with color conversion.
HTH, Pete
Hi Pete,
as always, thank you for your quick reply!
Is is perhaps possible to avoid the conversion overhead using the OES_EGL_image extension instead, as this uses the standard TEXTURE2D target? We're trying to render a texture via EGL_EXT_image_dma_buf_import.
thanks!
For imported memory I'm pretty sure you'd need to use the external samplers, because the driver isn't in control of the format allocated. Will ask around and see if anyone has any ideas though ...
Cheers, Pete
thanks a lot for asking around.
The story has an exciting twist (too exciting for my taste!). We've found out that we in fact did not incur the externalSampler2D cost, because - by accident -, we generated precompiled shaders using a normal sampler2D, but accessing textures bound to a EXTERNAL_TEXTURE_OES target.
So apparently the conversion overhead can be avoided in our case, but we really do not want be out of spec here! Still, it's encouraging that the driver and hardware support this.
My hope is that the OES_EGL_image extension, which binds to the usual TEXTURE_2D texture target, might do the trick. To be honest, I am a bit unclear on the exact differences between OES_EGL_image and OES_EGL_image_external, although I found this pretty good write up: https://waynewolf.github.io/2014/05/17/eglimage-in-surfaceflinger/ , which assumes the difference to be merly in the color space conversion - " I guess the main purpose of this extension is allow driver to support color space converter."
I'd be really greateful if you could verify this.
thanks again for your help!
Manuel
Checking with the driver team here and the answer is to just use OES_EGL_image with a TEXTURE_2D sampler - the EGL_EXT_image_dma_buf_import extension adds the necessary functionality to eglCreateImageKHR to import from dmabuf file handles.
Using sampler2D() on an EXTERNAL_TEXTURE target isn't officially supported - that works by chance, but is out of spec.
Great to hear, thank you for looking into this. My only worry is the following wording in the OES_EGL_image spec.
As a result of this referencing operation, all of the pixel data in the <buffer> used as the EGLImage source resource (i.e., the <buffer> parameter passed to the CreateImageOES command that returned <image>) will become undefined.
This is a significant departure from the OES_EGL_image_external, which states:
A EGLImageTargetTexture2DOES() call with <target> set to TEXTURE_EXTERNAL_OES will not modify the pixel data values in the EGLImage.
Not sure if the undefined data applies to dma imports? If you could get some reassurance from the driver team that this would leave our source data untouched I would greatly appreciate :-)Thanks Pete for all the input, it's greatly appreciated!
For Mali at least, the driver team have confirmed that we will always leave the data untouched so OES_EGL_image is safe. On other vendors you might get different behavior of course,
Wow, perfect, that's a relief :-) Thanks for verifying & your excellent support!