[meta-freescale] QtMultimedia on i.MX6

[Robert Winkler]

On Fri, Jul 12, 2013 at 1:56 AM, Thomas Senyk
<thomas.senyk at pelagicore.com>wrote:

> On Thursday, 11 July, 2013 12:58:34 Robert Winkler wrote:
> > On Wed, Jul 10, 2013 at 6:30 AM, Philip Craig <phil at blackmoth.com.au>
> wrote:
> > > On Wed, Jul 10, 2013 at 8:41 PM, Thomas Senyk
> > >
> > > <thomas.senyk at pelagicore.com> 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.
>
> Possibly ... partly! :)
> You're still missing YUV support.
> So you either have a hardware-converter (unlikely) or you got a opengl-YUV-
> extensions (which is part of the vivante api)
>
> So opengl es 3.0 + yuv-extension ... might be possible :)
>
> But then you're back to needing a extension ;) (at least it could be vendor
> independent)
>
>
> When does the imx6 get opengl es 3.0 anyway?
> I've read that the chip (gc2000) is opengl es3.0 capable ..?... so it's
> just a
> matter of drivers?
> I've already seen opengl 3.0 features ... e.g. multisample-texture support!
>

I don't think it ever will.  Where did you read that it is 3.0 capable?
That'd be awesome but I've never seen it.  I've only ever seen them say
it supports ES 2.0.

Actually the closest thing I can find right now is this page which lists
several of there GPU's.
http://www.vivantecorp.com/en/technology/3d.html

Unfortunately it doesn't say specifically which ones support 3.0 and I
can't find a footnote to go with the *.
I thought I read once that the GC4000 was the first/lowest to support 3.0.

Also multisample buffers/rasterization/antialiasing and multitexturing are
all supported
in OpenGL ES 2.0.  I think that probably includes what you've seen.  When I
grep for multisample in the gpu packages/examples
I see stuff about rendering to a texture which is probably this which says
it's written to the 2.0 spec:
http://www.khronos.org/registry/gles/extensions/EXT/EXT_multisampled_render_to_texture.txt





> >
> > > 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
> > > meta-freescale at yoctoproject.org
> > > https://lists.yoctoproject.org/listinfo/meta-freescale
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/meta-freescale/attachments/20130715/53aeff25/attachment.html>