Support for incidental data updates checked in

[robertosfield]

Hi All,

The VSG has had support for dynamic data updates for while now, essentially all you need to is in scene graph setup:

// scene graph set up
auto data = vsg::vec3Array::create(100);
data->properites->dataVariance = vsg::DYNAMIC_DATA;

...

// when you compile all the scene graph objects in the scene prior to main loop
// the compile traversal will find all the [vsg::BufferInfo](https://github.com/vsg-dev/VulkanSceneGraph/blob/master/include/vsg/state/BufferInfo.h) connected to Data with (DataVariance](https://github.com/vsg-dev/VulkanSceneGraph/blob/master/include/vsg/core/Data.h#L56) set to  DYNAMIC_DATA] and
// automatically assign them to the [vsg::TransferTask](https://github.com/vsg-dev/VulkanSceneGraph/blob/master/include/vsg/app/TransferTask.h) to be checked on every frame to see if it needs transferring to GPU
viewer.compile();

while(viewer->advanceToNextFrame())
{
    viewer->handleEvents();
    viewer->update();

     // update my data and call dirty() to increment the modification count 
     data->at(0).z += 1.0;
     data->dirty();

     // recordAndSubmit() will check all the data assigned to TransferTask and transfer the ones that have been modified
     viewer->recordAndSubmit();
     viewer->present();
}

This works well and is easy to use, but there are instances where applications may occasionally want to dynamically update data rather than on every frame, and if there are thousands of these types of data elements that "might" need updating the current mechanism is overkill and can lead to checking many data objects that almost never get updated.

In extreme usage cases this can lead to a high CPU overhead just for the privilege of possibly updating some of the data some of the time. While "Vulkan made easy" is the tag line for the vsg-dev account, performance is also critical so this has been an open issue since I originally wrote vsg::TransferTask.

This morning I updated TransferTask so that users can manually assign vsg:BufferInfo and vsg::ImageInfo to the vsg::TransferTask and have it for the next frame transfer the associated data, then remove the BufferInfo/ImageInfo for the list of objects to check if they need transferred. The mechanism allows you to update data and then tell the TransferTask that it needs to do a one off transfer the data.

To test the mechanism I also updated the vsgdynamicvertex example so that if you pass it the --static command line option it'll use dataVariance of STATIC_DATA and manually assign the associated BufferInfo to ensure it's transferred. This example still does this update on every frame so behaves the same the DYNAMIC_DATA approach so a cheaper option for this particular example, but at least it illustrates how it's done.

Form the vsgdynamicvertex example the new section in the main loop to do this assignment is:

               if (dataVariance == vsg::STATIC_DATA)
               {
                     // If the data variance is static then we have to manually
                    // assign the buffer info we want to transfer on each frame.
                    // This approach is most apporopriate for occassional updates
                    // for updates every frame it's best to declare the dataVaraince as DYANMIC_DATA
                    for(auto& tasks : viewer->recordAndSubmitTasks)
                    {
                        auto transferTask = tasks->earlyTransferTask;
                        for(auto& bufferInfo : fdv.bufferInfoSet)
                        {
                            transferTask->assign(vsg::BufferInfoList{bufferInfo});
                        }
                    }
                }

This is all extra code you need if you don't utilize the standard DYANMIC_DATA mechanism, but the key is enables incidental updates where the overhead is only paid when you require the transfer.

The new code that handles this usage case also handles the case where a BufferInfo/ImageInfo has dataVariance of DYNAMIC_DATA which is then changed to STATIC_VARIANCE, so it'll remove these entries for the list it manages automatically as well.

The changes required for this new feature is checked into VSG and vsgExamples master with these respective PRs:

• Changes to VulkanSceneGraph
• Changes to vsgExamples

Longer term I am thinking about having the vsg::CompileManager/CompileTraversal/Context leverage TransferTask to copy data rather than have this done within vsg::Context, and the changes checked into this morning are small part of this jigsaw.