[Interest] Qt3D memory leaks
Sean Harmer
sean.harmer at kdab.com
Thu Apr 13 19:36:28 CEST 2017
On 13/04/2017 16:31, Igor Mironchik wrote:
> Hi,
>
>
> 13.04.2017 17:55, Igor Mironchik пишет:
>>
>> Am I right that QEntity doesn't delete its children on destruction and
>> just removes them from scene?
>
> I asked this in context of QEntity::addComponent()...
>
> Seems that entity doesn't delete anything. And documentation is unclear
> in it:
>
> voidQEntity::addComponent(QComponent <qt3dcore-qcomponent.html>*comp)
>
> Adds a new reference to the component comp.
>
> Note: If the Qt3DCore::QComponent <qt3dcore-qcomponent.html> has no
> parent, the Qt3DCore::QEntity <qt3dcore-qentity.html> will set itself as
> its parent thereby taking ownership of the component.
>
>
> As I can guess it doesn't take ownership. Because of it I have few leaks
> at exit but not in restart of tree...
The entity takes ownership of any components that are parentless when
added. This is done using the usual QObject ownership mechanism so the
components will be deleted by the entity when it is being destroyed just
like any other QObject parent. There may be a leaks elsewhere but I
don't think this is it. There were some leaks related to VAOs fixed
around the time of the 5.8.0 release. I can't recall if they made it
into 5.8.0 or not off the top of my head. Please try with a build from
the 5.9 branch in git.
Cheers,
Sean
>
>>
>>>
>>> Are those numbers for Linux or Windows?
>>>
>>>>
>>>>
>>>> 13.04.2017 15:39, william.crocker at analog.com пишет:
>>>>> On 04/13/2017 08:34 AM, Igor Mironchik wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Strange, I launch 3Dtree on Linux under valgrind:
>>>>>>
>>>>>> ==4321== HEAP SUMMARY:
>>>>>> ==4321== in use at exit: 439,965 bytes in 6,185 blocks
>>>>>> ==4321== total heap usage: 2,207,719 allocs, 2,201,534 frees,
>>>>>> 1,241,469,509
>>>>>> bytes allocated
>>>>>> ==4321==
>>>>>> ==4321== LEAK SUMMARY:
>>>>>> ==4321== definitely lost: 1,080 bytes in 10 blocks
>>>>>> ==4321== indirectly lost: 7,609 bytes in 55 blocks
>>>>>> ==4321== possibly lost: 416 bytes in 1 blocks
>>>>>> ==4321== still reachable: 430,860 bytes in 6,119 blocks
>>>>>> ==4321== suppressed: 0 bytes in 0 blocks
>>>>>>
>>>>>
>>>>> Check the virtual image size on Linux,
>>>>> just to make sure it is not growing as well.
>>>>> That is the bottom line.
>>>>>
>>>>>> But on my Windows OS after each restart of tree I receive plus
>>>>>> ~100MB additional
>>>>>> memory.
>>>>>>
>>>>>> As I can see this memory still reachable. But why 3Dtree allocates
>>>>>> more and more
>>>>>> memory and doesn't use freed one?
>>>>>>
>>>>>> 13.04.2017 9:58, Sean Harmer пишет:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On 13/04/2017 07:09, Igor Mironchik wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> 3Dtree has been updated. Now autumn is animated. Removed hand-made
>>>>>>>> classes of leaf geometry and mesh. Now example uses ready mesh
>>>>>>>> prepared
>>>>>>>> in Blender. Modified a little constants of the tree. Example
>>>>>>>> looks nice.
>>>>>>>> This is a benchmark of your video card, because leafs and
>>>>>>>> branches are
>>>>>>>> stand alone objects (QEntity). For example 5 years tree has ~ 900
>>>>>>>> objects. My Intel Pentium with Intel HD graphics normally paint
>>>>>>>> only 5
>>>>>>>> years tree, 6 years tree starts to slow down.
>>>>>>>
>>>>>>> Yes, at present each entity with a material/geometry renderer
>>>>>>> combo gets
>>>>>>> translated to an OpenGL draw call. We are looking to add batching
>>>>>>> (similar to
>>>>>>> how Qt Quick 2 works) but it's not there yet.
>>>>>>>
>>>>>>> If you don't need to address each individual leaf/branch in your
>>>>>>> object model.
>>>>>>> E.g. if you're just rendering them, then you can get *much*
>>>>>>> better performance
>>>>>>> by using instanced rendering.
>>>>>>>
>>>>>>> Essentially you have one entity representing all leaves. This
>>>>>>> entity contains
>>>>>>> the material and geometry renderer as normal. The positions and
>>>>>>> any other
>>>>>>> custom properties that vary between instances (rotation, leaf
>>>>>>> size, leaf
>>>>>>> colour etc) should be placed into an additional attribute/buffer
>>>>>>> and provided
>>>>>>> to the geometry renderer. On this attribute, set the divisor
>>>>>>> property to 1
>>>>>>> meaning that 1 piece of data maps to 1 instance of the leave in
>>>>>>> the scene.
>>>>>>> With this approach you will be able to render 10,000's leaves in
>>>>>>> a single draw
>>>>>>> call. It maps through to a call to glDrawElementsInstanced() in
>>>>>>> case you want
>>>>>>> to read up on it. Essentially you're moving the for loop over
>>>>>>> each leaf on to
>>>>>>> the GPU.
>>>>>>>
>>>>>>> Typically, you'd have your data for the leaves in an array in C++
>>>>>>> and use this
>>>>>>> to populate the leaf instance buffer.
>>>>>>>
>>>>>>> The plan is to have a batcher that uses this instancing facility.
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Sean
>>>>>>>
>>>>>>>>
>>>>>>>> And one more - now you can rotate the tree with the left mouse
>>>>>>>> button.
>>>>>>>>
>>>>>>>>
>>>>>>>> 11.04.2017 12:15, Igor Mironchik пишет:
>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I fixed a little 3Dtree. Now branches positions are correct. And I
>>>>>>>>> know that not all leafs is visible (this is because leaf
>>>>>>>>> geometry is
>>>>>>>>> implemented as plain which renders only on one side).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 10.04.2017 13:20, Igor Mironchik пишет:
>>>>>>>>>>
>>>>>>>>>> Hello,
>>>>>>>>>>
>>>>>>>>>> I guess that Qt3D has huge memory leaks.
>>>>>>>>>>
>>>>>>>>>> You can check it on this example:
>>>>>>>>>> https://github.com/igormironchik/3Dtree
>>>>>>>>>>
>>>>>>>>>> It's 3D tree, that grows year by year.
>>>>>>>>>>
>>>>>>>>>> By default tree will grow 5 years (5 minutes).
>>>>>>>>>>
>>>>>>>>>> When tree grown you can restart tree. And here I delete all
>>>>>>>>>> resources:
>>>>>>>>>>
>>>>>>>>>> void
>>>>>>>>>>
>>>>>>>>>> MainWindowPrivate::createTree()
>>>>>>>>>> {
>>>>>>>>>> if(m_tree)
>>>>>>>>>> {
>>>>>>>>>> for(constauto&e:m_rootEntity->childNodes())
>>>>>>>>>> e->deleteLater();
>>>>>>>>>> }
>>>>>>>>>> m_tree=newBranch(m_startPos,m_endPos,c_startBranchRadius,
>>>>>>>>>> true,m_rootEntity);
>>>>>>>>>> m_tree->setAge(0.0f);
>>>>>>>>>> m_tree->updatePosition();
>>>>>>>>>> m_tree->placeLeafs();
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> But a lot of memory are eaten.
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Interest mailing list
>>>>>>>> Interest at qt-project.org
>>>>>>>> http://lists.qt-project.org/mailman/listinfo/interest
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Interest mailing list
>>>>>> Interest at qt-project.org
>>>>>> http://lists.qt-project.org/mailman/listinfo/interest
>>>>>
>>>>> _______________________________________________
>>>>> Interest mailing list
>>>>> Interest at qt-project.org
>>>>> http://lists.qt-project.org/mailman/listinfo/interest
>>>>
>>>> _______________________________________________
>>>> Interest mailing list
>>>> Interest at qt-project.org
>>>> http://lists.qt-project.org/mailman/listinfo/interest
>>>
>>> _______________________________________________
>>> Interest mailing list
>>> Interest at qt-project.org
>>> http://lists.qt-project.org/mailman/listinfo/interest
>>
>
>
>
> _______________________________________________
> 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
More information about the Interest
mailing list