[Development] Suggestion on QML portability

[Andreas Hartmetz]

On Wednesday 18 July 2012 07:26:55 gunnar.sletta at nokia.com wrote:
> On Jul 17, 2012, at 9:17 PM, ext Andreas Aardal Hanssen wrote:
> > 2012/7/17 <marius.storm-olsen at nokia.com>
> > 
> > > (2D accelerators are often bundled with GPUs and perform 2D rendering
> > > ops faster than GPUs, but are unusable with QML 2 / SceneGraph; see
> > > pvr2d).
> > 
> > 2D accelerators bundled with GPUs perform 2D rendering ops faster than
> > GPUs? Uhmm... that sentence is conflicting in my head, unless you mean
> > that you are using highly specialized boards with multiple GPUs (n*PVR)
> > on them to do things really really fast in parallel.
> > 
> > [OT]
> > 
> > No, I really mean dedicated 2D hardware chips outperform GPUs by far. It's
> > easy to do certain common simple 2D graphics faster than most embedded
> > GPUs I know of, even using the CPU. GPUs are built for (1) 3D
> > transformations on textures, (2) vertex-heavy objects and (3) per-pixel
> > shading operations. But it's easily beat for simple 2D operations like
> > blit (e.g., DMA), filtering/scaling (e.g., FPGAs). Most mobiles / tablet
> > UIs are 90% 2D.
> > 
> > My point is simply that Qt 5 is best served with a painting backend for
> > QML 2 that can support non-OpenGL technologies.
> Though true that 2D blitters support the basic features needed by many UI's
> it also comes with a lot of limitations.
> 
> They often operate on contiguous memory blocks, which need to be allocated
> by the kernel and comes which is limited in terms of what you can allocate.
> On several chips I've worked on, this is a system-wide pool, specified at
> boot-time.
> 
> They would also not support basic primitives, such as drawing rounded
> rectangles, antialiasing, free rotation, perspective transformation and
> 9-patch border images. So all of these would have to be rendered in
> software. This means a heavy mixing of CPU and accelerated drawing and we
> both know that combination does indeed suck. OpenGL is flexible enough to
> support what we need while at the same time providing us with very good
> performance, so it is the best thing we got.
> 
> If you know you are not using any of these features, then you could write
> your own renderer using the scene graph adaptation layer. A renderer that
> only looks at translate and scale transforms, maybe supports opacity and
> draws solid color boxes and pre-generated images. Text could be done using
> the adaptation for glyph nodes to render text using QPainter and then that
> could also be blitted in the renderer. This is doable today, but it would
> not support the full QML feature set, so it is not something we will invest
> time in.
> 
> There is also the possibility of using a software emulation library for the
> OpenGL stack to do all the rasterization in software, if there is no OpenGL
> chip. QML2 on llvmpipe beats QML1 on QPainter/raster, after all..
> 

In my experience your statement is not true. With llvmpipe I could run some 
~400x300 pixel QML2 demos(*) at 60 FPS on a 2.4 GHz Core 2 CPU with maybe 40% 
load. I have also seen a ~480x320 pixel QML1 UI I worked on run at 20 FPS on a 
300 MHz ARM9 CPU.
The desktop CPU is at least 15x faster.

The ratio of instructions per pixel and frame is then, approximately:
15 * 0.4 * (480 * 320 * 20) / (400 * 300 * 60) = 2.56
which is very good for the hard task llvmpipe is accomplisihing, but 
nevertheless it is slower.

(*) with surprisingly little frame rate and CPU load difference between the 
simplest Pong demo and some advanced ones using pixel shaders - I made sure 
that I was really using the software renderer, and I was, because the CPU load 
went to <10% after switching to hardware OpenGL.

Cheers,
Andreas