What sort of difference is there in the performance cost of creating or destroying one?

vkAllocateMemory is an expensive kernel call, but we already recommend designing your renderer to cache resources. Churning resources would be bad either way.

Given that transfer data isn't usually persistent, would caching the transfer buffers end up basically being a reimplementation of the sort of heap that SDL_GPU does for other types of resources?

I'm just imagining putting this directly into my own code and that's probably how it would end up with a bunch of extra work needed on my side, unless I'm missing something easy. Whereas with my native Vulkan code that uses VMA I don't have to worry about that and can just make throwaway transfer buffers for uploading/downloading texture or buffer data to and from the GPU.

If you're just using vmaCreateBuffer all that's doing under the hood is calling vkAllocateMemory. You would have to use a more complex allocation strategy to avoid that.

EDIT: After skimming some VMA code it looks like they do have a block system for allocations, much like we do. The main difference I guess is that VMA only defragments when you ask it to. Since we're targeting a Metal-esque level of complexity I don't think it's reasonable to force the user to reason about memory compaction.

Since we're targeting a Metal-esque level of complexity I don't think it's reasonable to force the user to reason about memory compaction.

Yeah, I completely agree. I just wonder if this change will create that need for users because they'd have to make their own memory allocation scheme to deal with the cost of transfer buffers.

Let's consider the use cases.

1. You have to do some uploads every frame, like in the case of a sprite batcher. In this case you should just be hanging on to a transfer buffer object that manages the uploads. When you map the transfer buffer you set the cycle parameter to true to avoid having to manually pool transfers.

2. You are loading content at the start of your game. In this case you would create a transfer buffer, perform your uploads, and tear it down. This is heavy anyway so the extra overhead of creating a transfer buffer doesn't really matter.

3. You are reading back data every frame. In this case you would have one persistent transfer buffer per-frame in flight.

4. You are reading back data sporadically, like saving a screenshot. In this case you would hold on to a persistent transfer buffer that's big enough to contain the screenshot buffer. You could also just set up and tear down a transfer buffer on a thread since presumably you would want the screenshot saving process to be asynchronous.

I'm not really seeing where it would be necessary or less troublesome to be churning transfer buffers constantly. It's good practice in general not to touch the driver anyway.

So one of the things I have in my app is multiple (one per font+size combination) texture atlases for font glyphs. Those atlases get populated with rasterized glyphs on demand during the app's runtime when there's a glyph that's needed which is missing from the atlas. The cost of uploading on-demand is expected to be fairly minimal, low enough that stutters aren't going to be a real problem.

So far I have not needed any higher level transfer buffer memory pool for that (especially since I use VMA with my Vulkan backend). If the cost in practice of making transfer buffers in SDL_GPU use dedicated memory with is low enough, then I still won't need to if I use SDL_GPU. This sort of thing is why I'm interested in real measurements rather than theoretical numbers.

I also have recent experience with small dedicated allocations in D3D12 on Windows being very slow, enough that the engine which was doing that had performance issues compared to D3D11 just because of those allocations. It's always good to measure this sort of thing in my opinion.

Yeah, I'll be running the FNA3D traces tomorrow... we cap our cycles but we also have a separate path for abnormally large transfers, so I could see it getting weird with a big enough test. Will try to confirm soon!