[Development] Status of Qt3D in 5.5

[Sean Harmer]

On Monday 09 Feb 2015 07:25:38 Thiago Macieira wrote:
> On Monday 09 February 2015 13:55:29 Sean Harmer wrote:
> > * Replacement for Threadweaver to allow commercial licensing. This is
> > underway  thanks to Mika and is under review on gerrit at present.
> 
> (As discussed in the release team meeting) The rest sounds like API reviews
> and only the above is a gating issue for the feature freeze and alpha
> release. If you can't get the code in shippable state by next Monday, then
> it misses the freeze. However, since it is an entire module, it can still
> re-join the rest of the modules for the beta.

Some bits are API review, some are missing API.

> 
> > As these parts of the API are not finished just yet and the feature freeze
> > is today
> 
> It's one week from today.

We'll get done what we can in the meantime.

> PS: why do you need a complex threaded job-dispatching mechanism in a 3D
> library?

Just within the renderer there are many tasks that can be performed 
distributed but which have some degree of dependencies between them. For 
example, rendering a complete frame may require several distinct 
configurations of the renderer. In Qt3D these correspond to the leaf nodes of 
the framegraph. For example:

0) Update the world transformations of objects that have moved and their 
children

1) build render commands that will draw the scene from camera 1 into a 
texture, then

2) build render commands that will draw the scene to the default framebuffer 
using camera 2 but using the texture from step 1 to texture a tv screen in the 
world.

3) Submit render commands built in earlier steps to OpenGL

Steps 1) and 2) can be executed in parallel but only after step 0) has 
completed. And even within steps 1) and 2) it may be beneficial to spawn 
additional jobs off as the scenegraph is traversed and converted to render 
commands and each batch is sorted to minimise state changes during submission. 
Similar for step 0) in fact. 

Step 3) can only be executed once the earlier jobs of creating rendercommands 
has completed. This happens on a dedicated OpenGL submission thread due to the 
nature of OpenGL vs threads.

This is just a very simple example. The framegraphs can have many more steps 
involved to render a frame and Qt3D also allows additional aspects to be added 
which can add their own sets of jobs with dependencies between them.

Trying to come up with a generic way to manage all this whilst making good use 
of n cores is a good fit for ThreadWeaver or Intel TBB or something else along 
the same lines.

Hope that explains it a little.

Cheers,

Sean
-- 
Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - Qt Experts - Platform-independent software solutions