Maybe it’s a stupid question, but I was wondering where vulkan objects exist. On onboard RAM or the VRAM of the GPU. I’m trying to visualize things in my head and I was wondering where these object exist in hardware terms.
Like where does VkBuffer gets stored, not the Memory that get’s attached to it but the actual VkBuffer structure that gets populated by the vkCreateBuffer. On the RAM or the GPU’s VRAM?
The same for other objects like pipelines, shader modules, etc.
My best guess is that the instance and logical device are stored on the onboard RAM, while things like VkBuffer, pipelines and other objects on VRAM. But that’s a guess, since I assume that when we say vkBindBuffers they are already on the VRAM.
They get stored wherever it is most convenient. Some are stored in CPU allocated memory (which you can override by giving allocator structs to the various APIs). Some are stored in GPU memory, with the CPU value being little more than a GPU address.
Some are a bit of both.
At the end of the day, it’s all up to the implementation. And, outside of being able to replace the internal allocator with your own, it really doesn’t need to matter all that much to you. If you need a Vulkan object, then you need whatever data is stored wherever that data gets stored. If you don’t need a Vulkan object… you should delete it or not have created it to begin with.
I see, so technically unless I have a custom made allocator that will create them explicitly on this or that memory heap, vulkan will just create these anywhere it finds free memory that it can access?
You only get to override allocations of CPU memory. The implementation owns the GPU and can allocate however much it wants (subject to limitations imposed by external systems like driver models and the like). The point of such overriding is to keep the Vulkan implementation from doing expensive (and thread-safe) heap allocations by replacing them with a cheaper (potentially thread-local) user-defined allocation system.
The implementation will perform 3 kinds of allocations: CPU allocations which you can override, CPU allocations which you cannot override (these are for doing things that require direct OS permission, like allocating CPU-executable memory), and GPU allocations. When it does which kinds of allocations is largely out of your hands.
Well I apologize for stupid questions, I’m really a beginner in the whole memory management thing, so I hope you bear with my ignorance on the topic.
But where does the VkBuffer object is stored then, and who can control where it is stored? I mean when we create all Vulkan objects we are given the option for using our custom allocator. Does this mean that this is the CPU memory we are allowed to control for these objects(or structs). Are they stored on CPU memory or they are just pointers to GPU memory?
And what about the VkMemory…is that an object/struct of data on it’s own or it’s just a pointer address of GPU memory we have access to?
Also by “implementation” do you mean the vulkan implementation unique for the GPU I’m running the app?
Most of these questions are, to one degree or another, implementation specific. Objects are, broadly, whatever the implementation wants/needs them to be.
By “the implementation”, I mean everything that happens inside of a Vulkan call. This includes the driver, but it also includes the OS and any Vulkan layers you have active.
If the implementation needs CPU memory for whatever reason, you (usually) get to control how that memory gets allocated. That is, you get to manage the heap. But you do not control whether allocations happen; that’s all decided by the implementation for its own purposes.
My overall point is that the answer to most of these questions is largely irrelevant to you as a user of Vulkan. What matters is that you have the power to replace (almost) any CPU allocations that the implementation makes with your own heap allocator. That’s pretty much all you get to care about.
Whether a VkDeviceMemory object is entirely on the GPU or entirely on the CPU or something in-between is unknown, unknowable, and overall unnecessary for using the API.
Yes, even as I was writing the questions I know it’s highly irrelevant on my side as a user. Still I was wondering about this and your answers were helpful so…Thank you for taking the time to answer them.