magnum

Commit Graph

Author	SHA1	Message	Date
Vladimír Vondruš	7799a8d3ff	Vk: Doxygen continues to be a massively underwhelming disappointment. Nope, it's 2020 and there's still no way to link to &-qualified functions. Feature that is in C++ since 2011.	6 years ago
Vladimír Vondruš	b6e41ab1a7	Vk: initial APIs for binding a memory to an image. You won't believe it, but it took me over a month of sitting on the shitter until this design idea materialized out of [..] air. The whole story, in order: - Vulkan doesn't allow one VkDeviceMemory to be mapped more than once. This is rather sad, because since Vulkan best practices suggest to allocate a large block and suballocate from that, the engine needs an extra layer that "emulates" mapping the suballocations for the users but behind the scenes it inevitably has to map the whole VkDeviceMemory anyway and keep it mapped for as long as any of the sub-mappings is active. - Because if it would map just a certain suballocation and then the user would want to map another suballocation, it would have to discard the original mapping and create a new one spanning both suballocations and that has a risk of suddenly being in a different VM block, making all pointers to the previous mapping invalid. - The Vulkan Memory Allocator implements this approach of mapping the whole thing and because of all the bookkeeping it doesn't give a direct access to the underlying VkDeviceMemory, making it rather hard to integrate. Here I realized that: - Most allocations won't need to be mapped ever, so the hiding and obfuscation done by VMA isn't needed for those --- and we want interoperability with 3rd party code, so preventing access to VkDeviceMemory is out of question. - There's KHR_dedicated_allocation, which (probably?) wasn't around when VMA was originally designed. The extension was created because a dedicated allocation actually does make sense in certain cases and on certain architectures. Providing a way to make those thus shouldn't be something "temporary, until a real allocator exists" but rather a well-designed API that's there to stay. - Except for iGPUs, the usual way to populate a GPU buffer would be to first copy the data to some host-accessible scratch buffer and then do a GPU-side copy of that buffer to a device-local memory. The scratch buffer is very likely to have a vastly different suballocation scheme than GPU buffers (grow & discard everything once it's all uploaded, for example) so again trying to put the two under the same allocator umbrella doesn't make sense. Thus: - To avoid implementing a full-blown allocator right from the start, we'll first provide convenience APIs only for dedicated allocations -- making it possible to transfer memory ownership to an Image/Buffer so it can be treated the same way as in GL, and later having the Image/Buffer constructor implicitly allocate a dedicated VkDeviceMemory. - This default allocation will be subsequently equipped with KHR_dedicated_allocation bits. - Thanks to the extensible/layered nature of the design, the user is still capable of being completely in control of allocations, managing VkDeviceMemory sub-allocations by hand. Finally, once allocator APIs are figured out, the default Buffer/Image behavior gets switched from a dedicated allocation to using an allocator, and dedicated allocation will be only used if the KHR_dedicated_allocation bit is requested.	6 years ago
Vladimír Vondruš	a16c7d6e7d	Vk: initial memory allocation.	6 years ago
Vladimír Vondruš	19c9243d3b	Vk: querying image memory requirements.	6 years ago
Vladimír Vondruš	fcd0afb306	Vk: add an Image wrapper. Not exactly sure about the usage, so no docs yet. Will come once memory allocation is complete.	6 years ago
Vladimír Vondruš	a4d906de86	Vk: querying device memory heaps and types. Memory type flags are put into a new, separate Memory.h header as those will be needed more often than the (ever-growing) DeviceProperties -- from Image and Buffer constructors, in particular.	6 years ago
Vladimír Vondruš	b45c9c310f	Vk: command pool and buffer reset.	6 years ago
Vladimír Vondruš	2353ba8c1a	Vk: command buffer allocation.	6 years ago
Vladimír Vondruš	4f538a0719	Vk: command pool creation.	6 years ago
Vladimír Vondruš	f75cc9330c	Vk: a non-error-prone way to retrieve queues after device creation. I wonder why this couldn't be done this way in the Vulkan API directly.	6 years ago
Vladimír Vondruš	374f816762	Vk: device creation.	6 years ago
Vladimír Vondruš	81cafc9ddf	Vk: querying device queue family properties.	6 years ago
Vladimír Vondruš	d28442e9b1	Vk: device extension enumeration.	6 years ago
Vladimír Vondruš	aa384a5d38	Vk: initial device enumeration.	6 years ago
Vladimír Vondruš	0392aeb878	Vk: instance creation.	6 years ago
Vladimír Vondruš	64ba1e6732	Vk: enumerating instance extension properties. Device extension properties will reuse a large part of this API.	6 years ago
Vladimír Vondruš	18e223e4d9	Vk: enumerating layer properties. Instance layers, with the same interface designed to be reused for device-level layers.	6 years ago
Vladimír Vondruš	ffbceef22c	Vk: retrieving instance version.	6 years ago
Vladimír Vondruš	6c9c9d9194	Vk: expose all extensions for version 1.2. Also provide compile-time info with them, a runtime list and everything else similar to what's done for GL.	6 years ago

19 Commits (7799a8d3ff3f59cbd8a1ed28d6e26e9817994574)