Currently, WR collects the instance data into Vec<> per batch, which is only copied to GPU-visible memory before the actual draw calls are made. Technically, there is no reason why WR couldn't be writing to the instance memory right when it fills out the batches.
The way I see it - we'd have a pool of allocated buffers (of the type required for instance data). Each batch reserves some pre-determined range in one of the buffers. The current batch can just write out data sequentially without a limited range. Batches that are outside of the lookup distance (i.e. we only look up to 10 batches back when adding an instance) have their ranges cut, so that the pools can re-use that memory. If a batch reaches the end of the allocated instance memory, it's simply closed, and a new one is started.
The benefit it gives us is, similar to #188, that more work is done beforehand (on the render backend side). Actually, this is a dependency of #188, since we can't record commands if the instance data isn't ready yet.
Currently, WR collects the instance data into
Vec<>per batch, which is only copied to GPU-visible memory before the actual draw calls are made. Technically, there is no reason why WR couldn't be writing to the instance memory right when it fills out the batches.The way I see it - we'd have a pool of allocated buffers (of the type required for instance data). Each batch reserves some pre-determined range in one of the buffers. The current batch can just write out data sequentially without a limited range. Batches that are outside of the lookup distance (i.e. we only look up to 10 batches back when adding an instance) have their ranges cut, so that the pools can re-use that memory. If a batch reaches the end of the allocated instance memory, it's simply closed, and a new one is started.
The benefit it gives us is, similar to #188, that more work is done beforehand (on the render backend side). Actually, this is a dependency of #188, since we can't record commands if the instance data isn't ready yet.