Dynamic data transfering with Switch node

[Anshi701]

Hwllo, i have a question about data sync in vsg.
Situation.

I have set of Switch nodes with 1 mesh draw commands under them. Let's say 1000 of Switches. At the start of programm, they are empty (have no valid data, just zeros) and switches are turned off. I load some amount of meshes, let's say 300. By loading a mean change data in buffers (with DYNAMIC_DATA property set). Then after present() function (before new frame) i make this buffer dirty() and turn on switches what is loaded.

And then things are getting interesting. If i changing data too fast, it feels like some data transferring is delayed, or switches are turned on, but data is not updated yet.
I saw in some discussion that data is "staying" for 2 frames, so after i make data dirty() and changing switches state, i wait for 2 frames before new loading.
I loading is slow enough, it works, but if i load meshes faster, this thing is happening again.

Maybe there is some mechanism to wait for data be transfered, or something else.

[robertosfield]

I can't make any sense of why you'd want to do what you are doing, it's not something I've ever heard of trying, it just doesn't make sense in how people normally use scene graphs.

You really need to take a big step back and tell us what the end result you want to achieve not how you are going about implementing it. We then can have a bash at suggesting the best way of implementing what you need to do.

[Anshi701]

Okay, let me explain. I have Earth divided by tiles. I have maximum tile count for scene, 1000 for example. With this i prepare buffers for 1000 tiles, 1000 switch nodes with draw commands (turned off by start). This buffers are empty at the start of programm. Then camera is flying over some space, i search for appropriate tiles and, for example, loading 300 tiles (less than maximum). Then i want:

1. Load data and change it in buffers.
2. Turn on switches what have loaded data - first 300 nodes in our example.

The reason why i dont use paged database nodes - my tiles have same layout, size and other data, so it is faster to preallocate everything and just change data.
The problem i have encountered was because i started new search of tiles too soon, before old data was drawed at least ones.
Hope this explanation is better, i'm still learning english...

[robertosfield]

Thanks for the explanation.

The VSG's CPU and GPU memory allocation is done in blocks and is reuses previously used memory so can get you some of the way of reusing resources without any explicit user management, this means PagedLOD based scheme should be able to leverage this out of the box.

For users that want to implement their own custom paging and resource scheme like you explain then potentially there may be some benefits but with it more complexity. The VSG is extensible, and to implement such a custom scheme I would use write a subclass from vsg::Node that overrides the accept(RecordTraversal&) method in order to have this custom node decide which if the children to traverse, and which ones to request or expire.

Such a custom node could have all the public interfaces that suit your application, and implement read/write and the accept(Vistor&), accept(ConstVisitor) and accept(RecordTraversal&) to get it to everything required. This approach will be more efficient than using vsg::Switch and provide a better interface for setting up and controlling the paging.

[Anshi701]

Thanks for details about PagedLODs. There is one thing i noted about data sync. If i make too much buffers with dynamic data, FPS is greatly lowers because VSG checks all buffers for changes every frame. So have separate 10000 object getting less FPS than make 1 or 2 buffers with data of these all objects. Yes, there is a problem with amouth of data transferring then changes occure, but overall it feels better.

[robertosfield]

A small number of large vk/vsg::Buffer is generally the recommended way to drive Vulkan.

The VSG's vsg::MemoryBufferPools provided a mechanism for allocated multiple data elements from a shared vsg::Buffer, and in turn assigns multiple vsg::Buffer per vsg::DeviceMemory. The aim of this mechanism to use block allocation of DeviceMemory and Buffer so that less buffers are required. You set the size of blocks that MemoryBufferPools users to help optimize it for your application needs.

However, if you are allocating vsg::Buffer directly then you can end up with inefficient usage if you make them too fine grained. As you've discovered :-)

The vsg::TransferTask organizes the copies per buffer to minimize the number of calls and to keep memory access closer but it won't scaling seamless if you are use ten's of thousands of separate data objects. The current implementation assumes that bufferInfo/data will need to be checked if it's direct on every frame and will keep bufferInfo/data around. One of intentions is to add support in TransferTask for one off bufferInfo/data entries that don't need to be set up as dynamic, instead applications would just add the bufferInfo/data that want transferred on the next frame.

[Anshi701]

Thank you for pointing out to this! I need now to understand how to use this mechanism to make less buffers...
EDIT:
I searched for some code or functions what provide posibility to make one buffer for texture array (texture array from example vsgtexturearray), but i cant find it. Sorry for troubling you, can i have some hint how to make it?