Processor Graphics Local Memory Allocation in Register Files
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Processor graphics with slower local memory performance face inefficiencies due to slower speed lower level caches, leading to varying performance across different architectures, contrary to the aims of OpenCL API which seeks adaptability across platforms.
Innovation Solution
Allocating local memory within register files and simulating barriers by allowing one execution unit thread to execute more SIMD instructions, using permutation group theory to optimize non-aligned writes, and caching frequently occurring patterns to enhance performance.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Quantity of substance
If local memory is implemented using traditional cache memory, then memory capacity can be increased, but memory access speed decreases
Solution Approach 1:
The patent extracts the local memory function from the traditional cache memory hierarchy and relocates it to register files. By taking out the local memory functionality from slower cache memory and placing it in faster register files, the system achieves both high-speed access and sufficient capacity for work-group data sharing.
Solution Approach 2:
The patent introduces an intermediary mechanism where register files serve as the local memory, positioned between the execution units and the L3 cache. This intermediary structure provides fast access for frequently used data while maintaining the ability to handle larger data volumes than traditional register files alone.
2Speed
If register files are used as local memory, then memory access speed improves, but available memory capacity is reduced
Solution Approach 1:
The patent merges the local memory function with the register files, combining two previously separate functions into a single structure. By merging local memory operations with register file operations, the system achieves fast access speeds while effectively increasing the available memory capacity for work-group data.
Solution Approach 2:
The register files are given multiple functions: they serve both as traditional registers for instruction execution and as local memory for work-group data sharing. This multi-functionality allows the same hardware structure to provide both high-speed register access and expanded local memory capacity.
3Reliability
If barriers are simulated using additional SIMD instructions, then synchronization functionality is maintained, but execution time increases
Solution Approach 1:
The patent implements self-service synchronization where the execution unit automatically manages barrier synchronization as part of its native operation. By making the execution unit self-aware of work-group boundaries and automatically inserting barrier operations, the system maintains reliable synchronization without requiring explicit software-managed workarounds that would increase execution time.
4Adaptability or versatility
If non-aligned writes are supported, then memory access flexibility improves, but processing complexity increases
Solution Approach 1:
The patent replaces the traditional mechanical approach to non-aligned writes (which requires complex address calculation and data reorganization hardware) with a software-based permutation approach. By using permutation group theory to generate lookup tables that map non-aligned addresses to aligned register positions, the system achieves flexible memory access without increasing hardware complexity.
Data Source
AI summary
In some cases, processor graphics with a slower local memory can compensate by using another memory in place of the lowest level or L3 cache. For example, in some processors, there is a large register space that can be used for the local memory function by allocating the local memory within those registers. Also, since the registers do not operate with barriers, barriers can be simulated by letting one execution unit thread execute more SIMD instructions. For example, one execution thread may simulate a whole work-group in the OpenCL API.