[Interest] Utilizing the GPU, how to start?

[Shawn Rutledge]

> On 6 Jul 2016, at 08:34, André Somers <andre at familiesomers.nl> wrote:
> 
> Op 06/07/2016 om 02:56 schreef Scott Aron Bloom:
>> 
>> -----Original Message-----
>> From: Interest [mailto:interest-bounces+scott=towel42.com at qt-project.org] On Behalf Of Thiago Macieira
>> Sent: Tuesday, July 5, 2016 5:42 PM
>> To: interest at qt-project.org
>> Subject: Re: [Interest] Utilizing the GPU, how to start?
>> 
>> On terça-feira, 5 de julho de 2016 11:45:41 PDT Jason Kretzer wrote:
>>> How does one get Qt widgets to take advantage of a GPU?  If this
>>> question seem naïve, it is because it is.
>>> 
>>> With my application, I am displaying different types of media —
>>> mp4 (using QMedia Player)
>>> Html (folders containing a "mini-site” using QWebView) Images (using a
>>> Qlabel)
>>> 
>>> This Qt 5.5, Windows7/10, running on a low end compute stick.

Hmm, how low-end can it be if it can run Windows?

Why 5.5?  At least 5.6 is LTS, so if you find any bugs, they’d have a chance of getting fixed in future 5.6 releases.

>>>  The CPU
>>> seems to take the brunt of the performance.  Just wondering how to
>>> offload some of that?
>> Stop using QtWidgets, including QtWebView and QLabel, and transition to Qt Quick instead. Qt Quick uses the GPU, QtWidgets do not.
>> ==========
>> 
>> That’s a pretty horrible answer... There are MANY of us, who prefer for all sorts of reasons, to use C++ as our primary development language.

Yeah we hear that feedback a lot.

>> Is there no outlook for QtWidgets to start using the GPU?
>> 
> No, there is not. Not realisticly. First of all, widgets are "done", so not much development is going on there. But more important is that the way widgets are rendered simply doesn't suit the way modern GPU's work. It is the main reason Quick (2) was created in the first place: render the contents in such a way that it can utilize the GPU the way its meant to be used. That can't be retrofitted to the widgets world.

What that means (from my understanding so far) is that if you try to render widgets with OpenGL, you will end up with a lot of draw calls, because widgets are rendered individually, in paint order (bottom up).  So there might not be a worthwhile speedup.  Whereas OpenGL works better to render a larger number of vertices in one draw call, which is why the QtQuick scene graph uses batching to group together items which use the same shaders and same uniforms, and which aren’t separated by other different items at intervening Z layers.  But it doesn’t sound like rendering the widgets themselves is going to be the bottleneck in your application anyway, as long as you can prevent the widgets themselves from being re-rendered too often.  I.e. no animations, and no widget overlays on top of the dynamic content.

Multimedia and web rendering are a different story.  Others are better qualified to comment on the details of how WebEngine, QtMultimedia, and the older alternatives are implemented - but they are all wrappers around other libraries.  Just because widgets don’t render their own pixels on the GPU doesn’t mean those libraries can’t render the framed content on the GPU, AFAIK.  At least theoretically, but I’m not up-to-date on whether the widget implementations are currently doing that efficiently.

> Note that even if you define your GUI in QML, you can still do everything else in C++. The QML doesn't have to be much more than what you already have as .ui files now, and they are not C++ either are they? Difference is of course that they get compiled into C++, where QML is not.

But you can use the QML compiler.  It translates the QML to C++ and compiles that.

It doesn’t hurt to try QtQuick, anyway.  If your UI is not complex, you can throw together a QML prototype in a few hours and see whether it performs better.  We have examples for both media-playing and web browsing, so you could start by checking performance of those.