Builder crashes when trying to dynamically add objects to vsg::Group about vsgexamples

[robertosfield]

Thanks for the example. I've created a CMakeLists.txt for it, built it and reproduced the crash.

I have got it to run reliably by change the invocation of the viewer->compile() to:

auto resourceHints = vsg::ResourceHints::create();
resourceHints->maxSlot = 1;

viewer->compile(resourceHints);

This leverages the changes I made to Viewer::compile();/ResourceHints a few weeks back, but didn't get the opportunity to discuss it in detail.

I view this as a partial solution. My plan is to enable the maxSlot to be changed on a per frame basis so when we load/delete a subgraph we can increase/decrease the value if that is appropriate.

[sbrkopac]

What exactly is maxSlot controlling that it allows the example to compile?

[robertosfield]

On Thu, 25 Nov 2021 at 08:18, Sam Brkopac ***@***.***> wrote: What exactly is maxSlot controlling that it allows the example to compile?

The state during the RecordTraversal uses vsg::State for tracking the current state that needs to be applied, each StateCommand has a slot number specifying which state stack to use wtinin vsg::State, and the container used for these stacks has to be preallocated with enough space for the maximum slot number used. If statements and dynamically allocating data are really expensive operations to do when you are potentially doing hundreds of thousands of them per frame, so the VSG design/implementation is geared towards avoiding these as much as possible on often called operations.

[robertosfield]

Adding another aspect to this general issue - I've come across a crash when loading data from the official GLTF data repository, the crash is due to models that have blending so required vsg::DepthSorted nodes and vsg::Bin that they map to hasn't already been allocated in viewer setup.

To reproduce the crash:

find glTF-Sample-Models/2.0 -name "*.gltf" | xargs vsgdynamicload

[sbrkopac]

Should vsg-dev/VulkanSceneGraph#451 have fixed this? I need update my ecosystems.

[robertosfield]

On Fri, 20 May 2022 at 18:53, Sam Brkopac ***@***.***> wrote: Should vsg-dev/VulkanSceneGraph#451 <vsg-dev/VulkanSceneGraph#451> have fixed this? I need update my ecosystems.

The DescriptorSet/DescriptorPool allocation is now easier to configure, and dynamic/on-demand so this part of difficulty in adding/removing Descriptors/DesciriptorSet from the scene graph should now be fixed. You no longer need to explicitly create new vsg::DescriptorPool so if your code does this then it can likely be simplified by just commenting it out.If your code is explicitly compiling the new subgraph then calling Context::reserve(resourceRequirements) as per the changes to vsgdynamicload, the relevant code vsgdynamicload now looks like: vsg::CollectResourceRequirements collectRequirements; request->loaded->accept(collectRequirements); for(auto& context : compileTraversal->contexts) { context->reserve(collectRequirements.requirements); } So calls Context::reserve(..) rather than manually creating the vsg::DesciptorPool. The code will still work if your comment this whole block out as the on-demand support internal to DescriptorSet/DescriptrPool/Context will now do what is required. However, consider it good housekeeping to do the reserve() as this will enable Context to allocate a block of resources rather than then being allocated one by one. Another good housekeeping approach is to pass in vsg::ResourceHints to the initial viewer.compile(..) call, this provides the Context a minimum configuration for DescrtiptorPool. Again the vsgdynamicload example has code in place for doing this: if (!resourceHints) { // To help reduce the number of vsg::DescriptorPool that need to be allocated we'll provide a minimum requirement via ResourceHints. resourceHints = vsg::ResourceHints::create(); resourceHints->numDescriptorSets = 256; resourceHints->descriptorPoolSizes.push_back(VkDescriptorPoolSize{VK_DESCRIPTOR_TYPE_COMBINED_IMAGE_SAMPLER, 256}); } // configure the viewers rendering backend, initialize and compile Vulkan objects, passing in ResourceHints to guide the resources allocated. viewer->compile(resourceHints); Things will still work if you don't do this, but there will be less DescriptorPool allocations if you provide relevant initial values.

…

-- What the changes don't impact is the changes to the number of slots that are required in vsg::State during the RecordTraversal. So you'll still need to provide the max number you expect, in your dynamically added scene graphs, via the ResourceHints. The dynamic DescriptorPool functionality also does not touch upon the allocation of vsg::View::bins, so this is another area that will have to be handled during scene graph/viewer initialization. Both these areas I consider issues to look at before 1.0, and plan to look at them next week. Like the dynamic DescriptorPool functionality it will require a few additions/refinements to the relevant code in the VSG. Exactly what this will look like I don't know yet, I'm hoping that I'll be able to get things working out of the box as simply as the new dynamic DescriptorPool functionality.

-- Overall though the new functionality is a big step forward for applications that have highly dynamic scene graphs, it really tames what was a really awkward part of Vulkan. So definitely update. Cheers, Robert. Message ID: ***@***.***>

[robertosfield]

I have now merged the DynamicSceneGraph branches associated with making multi-threaded dynamic scene graphs far easier and more robust to manage. The vsgdynamicload example is now far simpler so I recommend having a look over it.