[Interest] Quick2 OpenGL inefficiency?

Tue Mar 8 09:57:22 CET 2016

The best option is if you can create the surfaces on the GPU as a framebuffer object and just share the texture like Filip points out. http://doc.qt.io/qt-5/qtquick-scenegraph-textureinthread-example.html and http://doc.qt.io/qt-5/qtquick-scenegraph-textureinsgnode-example.html show much of how this can be done in Qt Quick.

However, if the surface content has to be produced on the CPU side as an RGB buffer and uploaded on a per-frame basis, you probably want to investigate using a pixel buffer object to perform the transfer. If you set up a pipeline with one or more frames of latency, you can make use of asynchronous DMA texture uploads which then imposes little to no cost on the CPU and have very little stalling in the driver. See http://www.roxlu.com/2014/048/fast-pixel-transfers-with-pixel-buffer-objects for an explanation.

cheers,
Gunnar

> On 08 Mar 2016, at 09:29, Jani Tykka <jtykka at broadsoft.com> wrote:
> 
> Thanks a lot for the info! Will check that out.
> 
> Jani
> 
> On Tue, Mar 8, 2016 at 9:40 AM, Filip Piechocki <fpiechocki at gmail.com> wrote:
> I don't know how you produce the video frames, but check that the software you are using might be able to produce OpenGL texture directly (not the buffer data). If not then here are some useful links:
> http://stackoverflow.com/questions/9863969/updating-a-texture-in-opengl-with-glteximage2d
> http://www.gamedev.net/topic/641283-fastest-way-to-stream-video-to-texture/
> 
> So basically you'll need to use glTexSubImage2D directly (and you probably do not need QImage at all) and for custom OpenGL rendering you can use QQuickFramebufferObject as your DisplayItem:
> http://blog.qt.io/blog/2015/05/11/integrating-custom-opengl-rendering-with-qt-quick-via-qquickframebufferobject/
> 
> On Tue, Mar 8, 2016 at 7:00 AM, Jani Tykka <jtykka at broadsoft.com> wrote:
> I'm creating the image from buffer which is unsigned char buffer containing video frame data
> QImage( buffer, width, height, QImage::Format_RGB32 );
> 
> 
> 
> On Mon, Mar 7, 2016 at 10:05 PM, Filip Piechocki <fpiechocki at gmail.com> wrote:
> >
> > How are you generating those images? What do they represent?
> >
> > On Mar 7, 2016 20:55, "Jani Tykka" <jtykka at broadsoft.com> wrote:
> >>
> >> Images are passed from another thread in rate 15-30 fps. Is there an example available how to achieve Image to OpenGL texture and use it in scene graph?
> >>
> >> On Mon, Mar 7, 2016 at 5:11 PM, Filip Piechocki <fpiechocki at gmail.com> wrote:
> >>>
> >>> And where it comes from? How frequent it happens? Probably the best thing here would be to generate this image as an OpenGL texture and then use in the Qt's scene graph.
> >>>
> >>> On Mon, Mar 7, 2016 at 4:04 PM, Jani Tykka <jtykka at broadsoft.com> wrote:
> >>>>
> >>>> Yes, the image is always changed when the update is invoked.
> >>>>
> >>>> On Mon, Mar 7, 2016 at 4:43 PM, Filip Piechocki <fpiechocki at gmail.com> wrote:
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> Why are you re-creating the texture on every node update? Does the m_Renderer->getImage() really changes? My first guess would be that the texture creation from image is the most costly part here (uploading the texture to GPU?) and I would do this only if necessary (the image really changes).
> >>>>>
> >>>>> BR,
> >>>>> Filip
> >>>>>
> >>>>> On Mon, Mar 7, 2016 at 3:04 PM, Jani Tykka <jtykka at broadsoft.com> wrote:
> >>>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> We are rendering QImages on QQuickItem as following:
> >>>>>>
> >>>>>> QSGNode * DisplayItem::updatePaintNode( QSGNode * node, UpdatePaintNodeData * /*data*/ )
> >>>>>>
> >>>>>> {
> >>>>>>
> >>>>>> QSGSimpleTextureNode * n = static_cast< QSGSimpleTextureNode* >( node );
> >>>>>>
> >>>>>> if ( !n )
> >>>>>>
> >>>>>> n = new QSGSimpleTextureNode;
> >>>>>>
> >>>>>>
> >>>>>> n->setRect( 0, 0, width(), height() );
> >>>>>>
> >>>>>>
> >>>>>> delete m_Texture;
> >>>>>>
> >>>>>>
> >>>>>> m_Texture = window()->createTextureFromImage( m_Renderer->getImage() );
> >>>>>>
> >>>>>> n->setTexture( m_Texture );
> >>>>>>
> >>>>>>
> >>>>>> return n;
> >>>>>>
> >>>>>> }
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> It seems that computers with separate GPU there is a decent amount of CPU utilised. We are running into problems if the machine lacks GPU, then with large images the CPU usage grows drastically. Any suggestions how to improve large image painting on QQuickItem? With Quick1 and painting directly on HWND/CocoaWindow we didn't experience this high CPU usage.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> This email is intended solely for the person or entity to which it is addressed and may contain confidential and/or privileged information. If you are not the intended recipient and have received this email in error, please notify BroadSoft, Inc. immediately by replying to this message, and destroy all copies of this message, along with any attachment, prior to reading, distributing or copying it.
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> Interest mailing list
> >>>>>> Interest at qt-project.org
> >>>>>> http://lists.qt-project.org/mailman/listinfo/interest
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Jani Tykkä 
> >>>> Development Manager | BroadSoft, Inc. | +358 44 596 0587 | jtykka at broadsoft.com
> >>>>
> >>>>
> >>>> This email is intended solely for the person or entity to which it is addressed and may contain confidential and/or privileged information. If you are not the intended recipient and have received this email in error, please notify BroadSoft, Inc. immediately by replying to this message, and destroy all copies of this message, along with any attachment, prior to reading, distributing or copying it.
> >>>
> >>>
> >>
> >>
> >>
> >> --
> >> Jani Tykkä 
> >> Development Manager | BroadSoft, Inc. | +358 44 596 0587 | jtykka at broadsoft.com
> >>
> >>
> >> This email is intended solely for the person or entity to which it is addressed and may contain confidential and/or privileged information. If you are not the intended recipient and have received this email in error, please notify BroadSoft, Inc. immediately by replying to this message, and destroy all copies of this message, along with any attachment, prior to reading, distributing or copying it.
> 
> 
> 
> 
> --
> Jani Tykkä 
> Development Manager | BroadSoft, Inc. | +358 44 596 0587 | jtykka at broadsoft.com
> 
> 
> 
> This email is intended solely for the person or entity to which it is addressed and may contain confidential and/or privileged information. If you are not the intended recipient and have received this email in error, please notify BroadSoft, Inc. immediately by replying to this message, and destroy all copies of this message, along with any attachment, prior to reading, distributing or copying it.
> 
> 
> 
> 
> -- 
> Jani Tykkä 
> Development Manager | BroadSoft, Inc. | +358 44 596 0587 | jtykka at broadsoft.com
> 
> 
> 
> This email is intended solely for the person or entity to which it is addressed and may contain confidential and/or privileged information. If you are not the intended recipient and have received this email in error, please notify BroadSoft, Inc. immediately by replying to this message, and destroy all copies of this message, along with any attachment, prior to reading, distributing or copying it.
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest