search

fcturan20 / TuranLibraries

Easy to integrate, collection of libraries to add new features to C such as threading, logging, profiling, gfx abstraction etc.
1 stars 0 forks source link

Memory System Implementation #2

Open fcturan20 opened 2 years ago

fcturan20 commented 2 years ago

Memory allocation types are designed around Vulkan's types but these doesn't map well to other GFX APIs and adds an unnecessary indirection. Types should be: GPUOnly, SLOW_CPU_GPU, FAST_CPU_GPU, CPUREADBACK_GPU. Other types of memories should be added too (Integrated GPU and Direct VRAM access).

fcturan20 commented 2 years ago

Currently I'm changing whole TGFX's design and user will be more responsible of memory (suballocations, heaps etc.). So we don't need this allocation type seperation feature specifically but we need the MemorySystem. It's better to turn this issue into MemorySystem issue.

fcturan20 commented 1 year ago

New design: Buffer & texture object creations (a.k.a. Resources in this issue) doesn't allocate any memory on GPU. User/RG is responsible for allocating GPU side memory and binding the resources to correct memory locations.

GPU side memory is created with createHeap() function. In Vulkan, this creates a VkDeviceMemory. Memory heaps can only be allocated from memory regions. Memory regions are returned in tgfxhelper->getGPUInfo_general(). There is no memory region object, each memory region has an index (starting from 0 for each GPU) and this is MemoryRegionID. Memory Regions = VkMemoryType, so some of the regions may have similar features and share single physical memory region. This won't be an issue in future, with contentManager->getRemainingMemory()'s implementation because user'll be able to query remaining size of a memory region.

Resources should be bound to heap with an offset. User should obey resource's alignment rule while binding it to a heap. User can always query size & alignment parameters of a resource by calling contentManager->getHeapRequirementXXX. Also some memory regions may not support some resources. To avoid such cases, user should bind the resource only in the supported memory region (Vulkan style bit manipulation math in memory region indexes).

Long story short: Resource creation is nothing more than a description. If you don't bind the resource to a memory heap, you can't use it. Avoid to create unnecessary memory heaps & obey resource & memory's binding rules.

Why we need such low-level memory system? This design is very user-unfriendly. There is no simple way to use such memory system in a renderer. But this design also allows lots of optimizations & doesn't do any operations so application can do anything it wants in edge cases like frequent allocation/frees & GPU memory over-allocation. TGFX Core isn't designed for direct renderer usage, so this system design is acceptable. There'll be an additional and more user-friendly memory system in TGFX RG.