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