Hello everybody, I'm currently struggling with the said system.Is there somewhere a *full* sample code for Linux that does create an EGLImage for a texture and demonstrates how to update it with the CPU ?
Reference documentation seems ok but eglGetError keeps telling me I don't know what I'm doing
I won't post my various tries here because they don't work and therefore have no value for the reader, but I've been romaing the web and trying stuff for a while.
Cheers, Tramb
I'm working on a R16 board, Cortex A7 with Mali400, without X11 support (fbdev instead).
No libGLES_mali.so here
# strings libMali.so | grep 'r[0-9]p[0-9]-'
1.4 Linux-r4p0-00rel0
Mali online shader compiler r4p0-00rel0 [Revision 96995].
I know the swizzle to be costly (and CPU-bound) because of my profiling with DS-5 Streamline.
The offenders are _mali_convert_tex8_l_to_tex8_b if I do my palette lookup on the GPU and _mali_convert_tex32_l_to_tex32_b in the other case.
I expect this to be the swizzling code (l_to_b => linear to block?) but it might be a wrong assumption.
I'll just be rendering a full-screen quad every frame (maybe scaled with bilinear filtering), so I'm not sure that the swizzling is worth it (and if it is, I could probably do it with a lower latency than the implementation in libMali.so by using several cores and NEON code).
We're just shipping on one definite platform so I'm definitely willing to specialize stuff to hit 60Hz and hardcode the swizzling pattern.
I thought PBO was not an option because we have only OpenGL ES 2.0, which doesn't support it.
But the main goal would be to have 0 copy and generate the texture in-place with the CPU, with double-buffering and fences to synchronize all this.
When I first tried to address the problem I noticed that the following extensions are provided:
EGL_KHR_image
EGL_KHR_image_base
EGL_KHR_gl_texture_2D_image
EGL_KHR_reusable_sync
EGL_KHR_fence_sync
EGL_KHR_lock_surface
EGL_KHR_lock_surface2
and it seemed to me they were there to address exactly my problem. In a quite-portable way moreso, without using the mali_ namespace.
I just can't for the life of me connect the dots, and that's why I'm asking for help.
(I have looked at the dma stuff but EXT_image_dma_buf_import is not available for me)
Thanks for reading all this !
Bertrand
If dma_buf is not supported in your BSP the only other way is to use UMP.
I will have to double check whether the magic code I have will work for that version of the driver or not but before I do that can you tell me if your driver is built with UMP?
I'm not sure, I'll ask the system team but their first gut feeling is "I don't think so".
I still don't have the answer. We contacted our supplier, ie your partner, to get some answers.
When you're speaking about dma_buf vs UMP, you're thinking about the way to update device memory ?
Is there a way to query the driver to know how glTexImage2D does it ? I was thinking the upload was done through DMA, after the swizzling is done on the CPU, but EXT_image_dma_buf_import is not exposed.
UMP driver is usually built as a kernel module so if you look into your kernel whether its loaded or not. You will get an answer. I am actually trying to see if this technique mentioned How to share texture memory between CPU/GPU for firefly's/rk3288 fbdev Mali-T764 will work with UMP or not.
tramboi wrote:Is there a way to query the driver to know how glTexImage2D does it ?
tramboi wrote:
Is there a way to query the driver to know how glTexImage2D does it ?
I don't think so.