OpenGL on i.MX6 : bad performance

Nicolas Dufresne nicolas.dufresne at collabora.com
Sat Oct 25 05:54:03 PDT 2014


Le 2014-10-07 09:23, Jean-Michel Hautbois a écrit :
> These are static images, but in a real case, it could be a webcam, or
> something else like a decoded video, how could these elements be more
> efficient ? Maybe is it a pipeline problem, I may have forgotten some
> things ?
Personally I do have the impression most of the cost is en-globed in GL 
upload. In high water mark, we see kernel side work (probably copy 
there), memory flushing (common when acquiring contiguous memory). The 
GL stack in upload could also be doing SW color conversion, I do have 
seen that in the past.

If your use case is capture from imx camera with vendor kernel, I would 
recommend that you learn how their custom contiguous memory stuff work. 
This if large hacks in the V4L2 driver. Then find a way to turn this 
memory into EGL image, wrapping it with libgstgl. This should let you 
skip the upload phase (does not guaranty there will be no GPU copy, but 
still already better). I have no idea if Freescale has proper GL 
extension for this though.

If you are looking for more test, you should try with gltestsrc, at 
least in this test there won't be any upload as gltestsrc will generate 
textures.

regards,
Nicolas


ps. Vendor specific set of elements: 
https://github.com/Freescale/gstreamer-imx


More information about the gstreamer-devel mailing list