Vulkan: Adjust allocation strategy #197
Conversation
| { | ||
| manager->transferBufferPool.fastTransferBufferAvailable = 1; | ||
| manager->transferBufferPool.availableTransferBufferCapacity += 1; |
There was a problem hiding this comment.
i'm guessing we have so few of these that growing by 1 is fine instead of by larger amounts or a ratio?
There was a problem hiding this comment.
yeah, these are allocated infrequently
| FNA3D_LogWarn("No unified memory found, falling back to host memory"); | ||
| renderer->unifiedMemoryWarning = 1; | ||
| } | ||
|
|
||
| while (VULKAN_INTERNAL_FindBufferMemoryRequirements( |
There was a problem hiding this comment.
what happens if we never find any suitable memory? it looks like we fall through to the bottom or we loop forever?
There was a problem hiding this comment.
memoryTypeIndex is incremented on these calls, so if an alloc fails on a particular memory type it can try again with another memory type. eventually this function will fail and cause the memory bind to fail. at that point the system would be completely out of memory so everything is extremely screwed anyway
|
Updated PS5 with the ABI change (it wasn’t using that parameter anyway) so this is good to go on that front. |
|
Our SDL GPU proposal is approved now, and that Vulkan implementation is enormously superior to FNA3D's, so I'm closing this with the expectation that we will be deleting FNA3D_Driver_Vulkan completely in the near future. |
It turns out that copying to the BAR from the CPU is actually slow, so the concept of a "fast transfer buffer" was not correct in the first place. Getting rid of this streamlines the transfer logic, reduces VRAM usage, and may improve performance in texture upload bottleneck scenarios.
There's also no need to specify ignored memory properties - the driver is specific about what kind of memory types the GetMemoryRequirements functions return, so there's no need to constrict that further.
Additionally, setting the CACHED bit on buffer allocation is a massive speedup.