From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-bk0-f53.google.com (mail-bk0-f53.google.com [209.85.214.53]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id F33D8E013E8 for ; Tue, 16 Jul 2013 01:16:06 -0700 (PDT) Received: by mail-bk0-f53.google.com with SMTP id e11so125697bkh.12 for ; Tue, 16 Jul 2013 01:16:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:subject:date:message-id:organization:user-agent :in-reply-to:references:mime-version:content-transfer-encoding :content-type:x-gm-message-state; bh=GTTuRxPp4aFmPW2bM0OHw2fEhOvaNZsH+rSzxSNYGqo=; b=GRSS5Ge/cnogbyuoY2UuLR0iArfuRsd/e8UMdaXlr9xEoADW0MXN4BrwnGKQHfF1MM s/RVhFwByzqKeqRVN5APrHjJ/b34lKD8kIyrz+rPvt8ArQovgXIOsX1Eas0C/qANH/8a 8FW7/wK6Qnzgl0YUdKFR8K3I9dO9PWZV8f0FNT7xOlP/5MJUQXXHKDkY7ttHK/laRLcB aX1nZpFuV7csB3i46adRN8qEPO/C5M3nSep9KELe7eElhz3LMbj6cgOlcBmN22N6q4Rk mmElZhCRjXPg0bn8Bo4JWJpoBr6W9gwvut2CXz27NSgxXGu/EqeLi//3dOnHgweCHniY PnUw== X-Received: by 10.204.77.72 with SMTP id f8mr78178bkk.28.1373962565787; Tue, 16 Jul 2013 01:16:05 -0700 (PDT) Received: from rudolf.localnet (ppp-82-135-88-177.dynamic.mnet-online.de. [82.135.88.177]) by mx.google.com with ESMTPSA id m6sm136793bki.7.2013.07.16.01.16.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 16 Jul 2013 01:16:05 -0700 (PDT) From: Thomas Senyk To: Robert Winkler Date: Tue, 16 Jul 2013 10:15:40 +0200 Message-ID: <1573228.p45skXyFp1@rudolf> Organization: Pelagicore AG User-Agent: KMail/4.10.5 (Linux/3.9.9-1-ARCH; KDE/4.10.5; x86_64; ; ) In-Reply-To: References: <1797012.Po2ZnTUHJW@rudolf> <45819715.P7POsvGn3d@rudolf> MIME-Version: 1.0 X-Gm-Message-State: ALoCoQm6hkQAsrlPW7blteHNYyIX1FqnnHhertCNptPhr4ZZ/BPcTjIkq8X+mZttcdWwZoUdPTcV Cc: "meta-freescale@yoctoproject.org" , Rogerio Nunes , Otavio Salvador Subject: Re: QtMultimedia on i.MX6 X-BeenThere: meta-freescale@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Usage and development list for the meta-fsl-* layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 08:16:11 -0000 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" On Monday, 15 July, 2013 11:18:34 Robert Winkler wrote: > On Fri, Jul 12, 2013 at 1:56 AM, Thomas Senyk > > wrote: > > On Thursday, 11 July, 2013 12:58:34 Robert Winkler wrote: > > > On Wed, Jul 10, 2013 at 6:30 AM, Philip Craig > > > > wrote: > > > > On Wed, Jul 10, 2013 at 8:41 PM, Thomas Senyk > > > > > > > > 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