One idea I was thinking about earlier today is to create bigger buffers when uploading. That would make the driver to do less allocation and internal buffer renaming, hopefully avoiding the associated slowness.
Here is what we do today:
```
FrameBuilder:
- make vectors of instance data, one per batch
Renderer:
- upload texture data
- for each target
- for each batch
- create a buffer with the instance data for *this batch*
- draw
```
Instead, we could do the following:
FrameBuilder:
- make vectors of instance data, one per *type of a* batch
- an actual batch would then just contain the range of that instance vector
Renderer:
- upload texture data
- upload all batch data
- for each target
- for each batch
- bind the relevant buffer (that is already on GPU)
- draw with specified base instance
```
Aside from having less driver work for managing the buffers (tracking, renaming, allocating), this approach also has a benefit of reducing our heap allocations. It also plays better with the Szeged fork.
Bug 1599502 Comment 2 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
One idea I was thinking about earlier today is to create bigger buffers when uploading. That would make the driver to do less allocation and internal buffer renaming, hopefully avoiding the associated slowness.
Here is what we do today:
```
FrameBuilder:
- make vectors of instance data, one per batch
Renderer:
- upload texture data
- for each target
- for each batch
- create a buffer with the instance data for *this batch*
- draw
```
Instead, we could do the following:
```
FrameBuilder:
- make vectors of instance data, one per *type of a* batch
- an actual batch would then just contain the range of that instance vector
Renderer:
- upload texture data
- upload all batch data
- for each target
- for each batch
- bind the relevant buffer (that is already on GPU)
- draw with specified base instance
```
Aside from having less driver work for managing the buffers (tracking, renaming, allocating), this approach also has a benefit of reducing our heap allocations. It also plays better with the Szeged fork.