On Wed, Jul 10, 2013 at 6:30 AM, Philip Craig <[email protected]> wrote:
> On Wed, Jul 10, 2013 at 8:41 PM, Thomas Senyk > <[email protected]> wrote: > > On Wednesday, 10 July, 2013 20:32:05 Philip Craig wrote: > >> I'm not sure why it needs to be imx6 specific. Doesn't the opengl API > make > >> it so that it doesn't need to be specific? The Qt eglfs platform is > using > >> the vivante opengl libraries. As I understand it, the parts that need > to be > >> imx6 specific are confined to the eglfs platform plugin. > >> > >> qt-gstreamer is at http://cgit.freedesktop.org/gstreamer/qt-gstreamer > > > > No. There is no vendor-independent way to map cpu/vpu based memory into > gpu > > (/opengl) memory. > > Without 'mapping' one needs to copy/upload via glTexImage2D. > > This one single line(!) consumes >100% cpu of one iMX6 core for 1080p. > > If you 'map' the cpu load is very easily <10% > I was under the same impression as Philip that OpenGL does provide the functions glMapBuffer and glMapBufferRange. Standard OpenGL does provide both. Then I checked and OpenGL ES 2.0 does not have those functions but OpenGL ES 3.0 has the latter ( https://www.khronos.org/opengles/sdk/docs/man3/xhtml/glMapBufferRange.xml). So to clarify, if the i.MX 6 did support OpenGL ES 3 would that qualify as a vendor-independent way to map memory? Sorry it's slightly unrelated I'm just curious. > Thanks for the explanation. Just to be sure I understand you: there is > no standard way to allocate dma buffers, so the gpu cannot do the copy > itself? I see that gst-plugins-gl relies on gstbufmeta from the > gst-fsl-plugins package to determine the physical address of dma > buffers allocated by the vpu plugin or by the v4l2src. > > And yes, qt-gstreamer is using glTexImage2D. I guess that could be > patched, but then you may as well just patch QtMultimedia like you > were planning. > _______________________________________________ > meta-freescale mailing list > [email protected] > https://lists.yoctoproject.org/listinfo/meta-freescale >
_______________________________________________ meta-freescale mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-freescale
