You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: