update_buffer_offset and static ref

[remifontan]

Hi,

I'm having difficulties in finding a way to use RenderGraph::update_buffer_offset without having to leak memory for passing parameters data.

pub fn update_buffer_offset(
        &mut self,
        buffer_node: impl Into<AnyBufferNode>,
        offset: vk::DeviceSize,
        data: impl AsRef<[u8]> + 'static + Send, // <-- that `'static is giving me trouble
    ) -> &mut Self

Perhaps I'm trying to use update_buffer_offset for the wrong purpose. I have on object with lots of instances, each instance is controlled by a per-instance vertex buffer. I'd like to update that per-instance vertex buffer so that I can "move" those instances. And I was hoping I could update one insance without having to update the whole vertex buffer.

Would it be possible to make update_buffer_offset take ownership of data and eventually return it once the update has completed?

Cheers.

[attackgoat]

This function takes an owned instance of some data (maybe a Vec<u8>) and it will be dropped once complete, so there isn't a leak so much as failure to return it once complete, as you point out. It's certainly possible change this to do what you ask, maybe by also passing a callback which receives the data or function which returns it using a handle or ID. In practice this usually isn't a bottleneck and short-lived allocations are fine, but you also might pass a wrapper type which internally implements AsRef<u8> using a borrow of Arc<..> or something.

However, this is a very special function in Vulkan because:

dataSize must be less than or equal to 65536 bytes. For larger updates, applications can use buffer to buffer copies.

See vkCmdUpdateBuffer

And especially the note:

... Applications can work around this restriction by issuing multiple vkCmdUpdateBuffer commands to different
ranges of the same buffer, but doing so is not recommended.

If you're certain your data is less than 64K, I would recommend just allocating and passing it. This is the easy method.

For realistic use-cases, like the updating instance data or something:

• Lease or keep an instance of a temporary buffer
• Copy changes into that buffer
• Use the buffer copy API to copy multiple regions from the temporary buffer to the instance buffer

The temporary buffer will usually be a better option because you reduce the number of Vulkan API calls and you likely have more than one instance to update, or range of instances.

[remifontan]

Thanks a lot for the detailed explanation. I'll have a got at testing your suggestions.