Multicore 3D Rendering Memory Layout for Order and Overflow Control
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Implementing rendering tasks in parallel on a multicore GPU while maintaining the correct order of primitive rendering and managing memory efficiently to facilitate the rendering of complex scenes.
Innovation Solution
A multicore graphics rendering system with a hierarchical memory management system that uses allocation lists and virtualised memory spaces to manage memory allocation and ordering of rendering tasks, ensuring efficient use of memory and maintaining the correct rendering order.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If rendering tasks are processed in parallel on a multicore GPU, then rendering productivity is improved, but memory management complexity increases and rendering order may be compromised
Solution Approach 1:
The patent segments memory into multiple memory pools (e.g., render target memory, depth buffer memory, stencil buffer memory) and further divides each pool into multiple memory regions or blocks. This segmentation allows independent allocation and management of memory for different rendering tasks on different cores, reducing overall memory management complexity while enabling parallel processing.
Solution Approach 2:
The patent introduces a memory manager as an intermediary component that mediates between the parallel rendering cores and the memory subsystem. The memory manager handles allocation, deallocation, and coordination of memory resources across multiple cores, simplifying the complexity of parallel memory management and ensuring correct rendering order through coordinated memory access.
2Productivity
If rendering tasks are processed in parallel on a multicore GPU, then rendering productivity is improved, but the likelihood of memory overflow increases
Solution Approach 1:
By segmenting memory into separate pools for different rendering operations, the patent prevents memory overflow in any single area. Each memory pool has dedicated capacity for specific rendering tasks, allowing parallel processing without risking overflow in shared memory spaces.
Solution Approach 2:
The patent implements preliminary memory allocation and reservation mechanisms where memory regions are pre-allocated for expected rendering workloads. This preliminary action ensures that sufficient memory is reserved before parallel rendering begins, preventing overflow during execution.
3Productivity
If rendering tasks are processed in parallel on a multicore GPU, then rendering productivity is improved, but maintaining correct rendering order becomes more difficult
Solution Approach 1:
The memory manager acts as an intermediary that coordinates memory access across parallel cores and maintains rendering order through controlled memory operations. It ensures that rendering operations execute in the correct sequence by managing memory allocation and access rights, while still allowing parallel processing for productivity.
Solution Approach 2:
The patent implements dynamic memory allocation and deallocation strategies that adapt to the rendering pipeline's needs. Memory regions are dynamically assigned and released based on the current rendering state, allowing flexible parallel processing while maintaining correct order through dynamic coordination rather than fixed rigid structures.
Data Source
AI summary
A multicore graphics rendering system includes a plurality of cores configured to implement tile-based rendering of a stream of primitives. The graphics rendering system uses at least one virtualised memory space. A hierarchical index is provided, to index the physical memory portions associated with virtual memory portions in the at least one virtualised memory space. The portions of memory allocated for the hierarchical index are recorded in an MMU (memory management unit) list (MLIST). The MLIST comprises a plurality of entries, each entry being associated with a respective portion of the hierarchical index, wherein each entry includes an indication of the portion of virtual memory that is indexed by that portion of the hierarchical index. The MLIST is used to identify, and free, portions of memory associated with indexing virtual memory that has been fully consumed in a partial render.