[Development] Status of Qt3D in 5.5
sean.harmer at kdab.com
Mon Feb 9 17:15:42 CET 2015
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
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
1) build render commands that will draw the scene from camera 1 into a
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
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.
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
More information about the Development