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 | [email protected] | 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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
