Re: QtMultimedia on i.MX6

[Thomas Senyk <thomas.senyk@pelagicore.com>]

On Monday, 15 July, 2013 11:18:34 Robert Winkler wrote:
> On Fri, Jul 12, 2013 at 1:56 AM, Thomas Senyk
> 
> <thomas.senyk@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@blackmoth.com.au>
> > 
> > wrote:
> > > > On Wed, Jul 10, 2013 at 8:41 PM, Thomas Senyk
> > > > 
> > > > <thomas.senyk@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

There is a '*' behind "ES 3.0" ... which indicates a footnote or something .. 
can't find any ;)

> 
> 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.

http://www.khronos.org/news/permalink/vivante-shipping-gpu-cores-designed-to-support-the-latest-opengl-es-3.0-spe

quote: "...GC Cores starting with the GC800..."

No clue if this is in any way reliable ... it's khronos so it should, but it's 
more of a 'somebody stated'-news then a 'that's how it is'-news.

> 
> Also multisample buffers/rasterization/antialiasing and multitexturing are
> all supported
> in OpenGL ES 2.0. 

Yes, but they are a extension in es2.0 and core feature of es3.0, that's what 
I meant with es3.0 feature.

> 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

Yes, this wasn't present right from the beginning,
It come in with 4.0.0 .. or 1.1.0? .. or maybe earlier and I saw it to late :)

> > > > 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@yoctoproject.org
> > > > https://lists.yoctoproject.org/listinfo/meta-freescale