[Interest] [qt3d] Batching optimization
Xavier Bigand
flamaros.xavier at gmail.com
Mon Sep 26 17:48:10 CEST 2016
2016-09-26 15:03 GMT+02:00 Sean Harmer <sean.harmer at kdab.com>:
> Hi,
>
> On 26/09/2016 13:59, Xavier Bigand wrote:
>
>> Doesn't the scene graph of qt3d use the instancing and sort the draw
>> calls to reduce the number of state changes?
>> In our engine the win was big when I add the sort to reduce calls of
>> glUniform* and glBindTexture,... especially on Android and Windows.
>>
>
> Yes, we do that level of batching. What we do not do however, is
> dynamically combine geometry data into fewer numbers of VBOs or anything
> fancy with glMultiDrawIndirect.
Nice to read.
>
>
> We don't use instancing for the moment because it's hard for us to
>> maintain the backend, it's one of reasons I am planning the migration to
>> qt3d.
>>
>> In my opinion for qt3d the API have to expose a flag on entity to allow
>> or not automatic batching.
>>
>
> Yes I was thinking of something along those lines but the details have yet
> to be worked out and to what extent can/should we batch?
>
Here is what we are rendering :
A such scene is close to 10 000 draw calls, because we have 3 passes (light
scattering occlusion, Sun Shadow Map, Normal rendering).
As the user is able to paint all parts of objects those entities have
separated meshes and don't use texture atlas, so it increase a lot the
number of draw calls.
Walls are generated by faces (6 per wall), but here the number of draw
calls is small compared to those for objects.
There is some difficulties to be able to batch automatically our objects
with a win :
- Some have a lot of vertices (> 10 000), and applying the transformation
matrix on CPU could cost as much as the GPU win
- All textures are compressed (pvrtc, dxtc and etc1), so putting them in a
atlas might be non trivial depending on formats
- Having a good management of pre-allocated geometry buffers (I think that
a pool is necessary)
- There is some check to do before merging geometries in the same buffer
(some types aren't compatible, triangle, line, triangle_strip,..)
I think that I have to progress on our qt3d migration before being able to
compare performances between OpenGL and DirectX 12 backends. If there is a
good win, so it will certainly not interesting to implement an advanced
batching system just for older devices that will stay on OpenGL.
>
> Cheers,
>
> Sean
>
> Else the automatic batching could be applied on meshes that doesn't have
>> a transformation and don't require to be rendered in a particular order
>> (like those with alpha).
>>
>> I'll made some tests on our engine to evaluate the performance win, it
>> may be insignificance due to the sort.
>>
>>
>> 2016-09-25 11:55 GMT+02:00 Sean Harmer <sean.harmer at kdab.com
>> <mailto:sean.harmer at kdab.com>>:
>>
>>
>> Hi Xavier,
>>
>> On 23/09/2016 17:13, Xavier Bigand wrote:
>>
>> Hi,
>>
>> Does qt3d backend capable to batch geometries to reduce the
>> number of
>> draw calls?
>>
>> In our case this optimization should improve performances a lot,
>> because
>> we generate dynamically geometries that doesn't change often and
>> are
>> created in world coordinates (no transformations applied).
>>
>>
>> Qt 3D does not yet do batching automatically. However we do support
>> stuff that may help you.
>>
>> * You can use instancing if you have GL 3.2 or newer
>> * You can do your own batching by putting such geometry into a
>> single buffer, either
>>
>> ** to be rendered as a single entity if you don't need interaction
>> with the individual parts or
>> ** to be rendered as separate entities with GeometryRenderer's all
>> referencing the same Buffer.
>>
>> The latter doesn't reduce the draw call count but does minimise the
>> state changes related to binding different buffers.
>>
>> We hope to add automatic batching in the future but we're still
>> looking into a nice API to expose this without reducing the control
>> the user has over organising their data.
>>
>> Cheers,
>>
>> Sean
>>
>>
>>
>>
>> --
>> Xavier
>>
>>
>> _______________________________________________
>> Interest mailing list
>> Interest at qt-project.org <mailto:Interest at qt-project.org>
>> http://lists.qt-project.org/mailman/listinfo/interest
>> <http://lists.qt-project.org/mailman/listinfo/interest>
>>
>>
>> --
>> Dr Sean Harmer | sean.harmer at kdab.com <mailto:sean.harmer at kdab.com>
>> | Managing Director UK
>> KDAB (UK) Ltd, a KDAB Group company
>> Tel. +44 (0)1625 809908 <tel:%2B44%20%280%291625%20809908>; Sweden
>> (HQ) +46-563-540090 <tel:%2B46-563-540090>
>> Mobile: +44 (0)7545 140604 <tel:%2B44%20%280%297545%20140604>
>> KDAB - Qt Experts
>> _______________________________________________
>> Interest mailing list
>> Interest at qt-project.org <mailto:Interest at qt-project.org>
>> http://lists.qt-project.org/mailman/listinfo/interest
>> <http://lists.qt-project.org/mailman/listinfo/interest>
>>
>>
>>
>>
>> --
>> Xavier
>>
>>
>> _______________________________________________
>> Interest mailing list
>> Interest at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/interest
>>
>>
> --
> Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK
> KDAB (UK) Ltd, a KDAB Group company
> Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
> Mobile: +44 (0)7545 140604
> KDAB - Qt Experts
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
--
Xavier
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20160926/afe5ecf8/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 3894928 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20160926/afe5ecf8/attachment.png>
More information about the Interest
mailing list