RDNA architecture GPU video memory accurate alignment method based on hardware sub-block rearrangement

Abstract

The invention discloses a hardware sub-block rearrangement-based RDNA architecture GPU video memory accurate alignment method, which comprises the following steps of: when a GPU does not support VKMESAIalign control, dividing bandwidth groups after VKD3D is started, constructing an independent memory pool containing different sub-regions for each group, analyzing and converting resource parameters into Vulkan adaptation parameters when a D3D12 resource is created by application, calculating alignment granularity and access frequency of adaptive RDNA hardware, and performing Vulkan adaptation on the Vulkan adaptation parameters. The method comprises the following steps: matching memory blocks for resources, constructing and binding a Vulkan image, constructing a hardware rearrangement instruction by VKD3D when a plurality of resources are allocated to continuous memory blocks of the same MCD group, dynamically selecting a GPU queue, submitting and executing, verifying sub-block address mapping after rearrangement, dynamically adjusting memory pool expansion, a resource migration strategy and alignment granularity by VKD3D according to the bandwidth utilization rate of the MCD, and the balance between accurate alignment and performance adaptation of the video memory is realized.

Description

Technical Field

[0001] This invention belongs to the field of computer software development technology, specifically relating to a method for precise alignment of RDNA architecture GPU memory based on hardware subblock rearrangement. Background Technology

[0002] VKD3D, as the core conversion layer for running D3D12 games on the Linux platform, primarily maps D3D12 resource descriptions and operations to equivalent Vulkan interfaces. The VK_MESA_image_alignment_control extension is crucial for VKD3D to reduce VRAM bloat. Its core function is to allow applications to actively declare the maximum permissible alignment granularity of image resources to the Vulkan driver via the maxImageAlignment parameter in the VkImageAlignmentControlCreateInfoMESA structure. The driver then abandons the default coarse-grained alignment based on this parameter, adopting a more compact memory layout, thereby eliminating memory waste caused by alignment padding. Simultaneously, this extension uses the alignmentPriority parameter to dynamically balance performance and alignment, automatically relaxing alignment requirements under high load scenarios to ensure frame rate. In AMD's RDNA2 and RDNA3 architectures, the hardware itself has the physical capability for fine alignment and the potential for high-performance adaptation. RDNA2 supports minimum image alignment at the 4KB level, while RDNA3 further reduces the minimum alignment granularity to 2KB and achieves parallel memory access through the distributed memory architecture of the memory cache chip MCD. At the same time, the architecture integrates a hardware sub-blocking engine and a graphics computing chip GCD to MCD address mapping unit, which can perform fine-grained block partitioning and memory mapping of image resources.

[0003] However, in scenarios where the VK_MESA_image_alignment_control extension is not supported, existing technologies have the following core problems that are difficult to solve: First, the alignment control interface is missing and the precision is insufficient. The standard Vulkan does not provide a public interface for passing custom alignment requirements to the driver. RADV (AMD open source Vulkan driver) uses a conservative alignment granularity of 64KB by default. Even if the RDNA hardware supports 4KB or 2KB alignment, it cannot be triggered through the software layer. Moreover, the existing software layer optimization can only achieve byte-level alignment, which cannot match the pixel block-level alignment requirements of the RDNA hardware, resulting in 20% to 30% of invalid padding after D3D12 resource mapping.

[0004] Second, there is a disconnect between hardware performance characteristics and software layer adaptation. Features such as the MCD bandwidth differences between RDNA2 and RDNA3, the dynamic block size adaptation of the hardware sub-blocking engine, and the alignment-sensitive access of GCD's L2 cache do not expose the linkage control entry between alignment and performance in the Vulkan standard interface. The software layer cannot dynamically adjust the alignment strategy according to the hardware load, resulting in a tradeoff between saving video memory and ensuring performance.

[0005] Third, the performance and alignment conflict in the chunked mode intensifies. Vulkan's VK_IMAGE_TILING_OPTIMAL mode is the optimal performance choice for the RDNA architecture, but the alignment granularity of this mode is hardcoded to 64KB by the driver and cannot be adjusted according to the resource type. While the VK_IMAGE_TILING_LINEAR mode supports flexible alignment, it causes the texture unit access efficiency of RDNA hardware to drop by more than 30%, and it cannot utilize the block prefetching function of GCD's L2 cache. In 4K resolution games, the frame rate can drop by 15 to 20 fps.

[0006] Fourth, the fragmentation of memory allocation and the waste of bandwidth are superimposed. Without fine alignment control, discrete D3D12 resources will generate a lot of fragmented space in Vulkan memory allocation. The multi-MCD architecture of RDNA will further amplify this fragmentation. Resources allocated across MCDs will cause memory access latency to increase by 20 to 30 ns and bandwidth utilization to decrease by 15%, forming a vicious cycle from fragmentation to bandwidth waste.

[0007] Fifth, the handling of alignment anomalies is coarse-grained. Existing technologies can only detect basic anomalies such as lack of alignment granularity support, and cannot identify deeper anomalies such as sub-block address mapping errors and alignment failures caused by MCD bandwidth exceeding limits. Furthermore, the fallback strategy uses 64KB alignment and does not dynamically adjust according to the anomaly type and game scenario, resulting in unnecessary performance loss.

[0008] Existing technologies often employ software-level memory pooling or linear tiling as optimization methods to address this issue. However, the former can only alleviate fragmentation and cannot solve the core problem of alignment and filling, and it does not take into account the difference in MCD bandwidth. The latter, on the other hand, sacrifices hardware performance and does not truly utilize the alignment and performance linkage characteristics of RDNA hardware. Summary of the Invention

[0009] In view of this, the present invention provides a method for precise alignment of GPU memory based on hardware sub-block rearrangement for RDNA architecture. In scenarios where the GPU does not support the VK_MESA_image_alignment_control extended feature, the method achieves precise control of memory alignment and efficient reduction of memory usage through in-depth hardware feature mining, driver interface extension and precise software layer adaptation, while ensuring the hardware performance advantages of the RDNA architecture.

[0010] This invention provides a method for precise memory alignment of RDNA architecture GPUs based on hardware sub-block rearrangement, specifically including the following steps:

[0011] After system startup, a binary node storing GPU hardware parameters and a first text node storing MCD bandwidth are constructed. After VKD3D starts, hardware parameters are read through the binary node and MCD bandwidth is read through the first text node to set a threshold. The MCD is divided into a high-bandwidth group with bandwidth greater than the larger threshold, a medium-bandwidth group with bandwidth not greater than the larger threshold and not less than the smaller threshold, and a low-bandwidth group with bandwidth less than the smaller threshold. An independent memory pool is allocated for each MCD group, and the memory pool is divided into sub-regions. The corresponding sub-regions of the high-bandwidth group memory pool are allocated to local device memory and written to merged video memory, and the memory pool is bound to the MCD group.

[0012] When an application creates D3D12 resources, VKD3D maps the D3D12 resource type to its Vulkan equivalent type. Based on the application's alignment requirements and the hardware's minimum alignment granularity, it calculates the basic alignment requirements of the resources and then generates an alignment granularity adapted to RDNA hardware. It maps the D3D12 resource usage scenarios to the performance priorities of the Vulkan side; it calculates the resource state transition frequency for each frame of D3D12 resources and determines the resource access frequency based on the resource usage scenario; it matches MCD groups to the resources, determines sub-regions based on the access frequency, allocates memory blocks for the resources based on the block size matched by the alignment granularity, creates a Vulkan image, and binds the memory blocks.

[0013] When multiple D3D12 resources are allocated to contiguous memory blocks in the same MCD group memory pool, VKD3D configures the source address, target address, number of resources, and alignment granularity to construct hardware rearrangement instructions, dynamically selects the GPU queue to submit and execute sub-block rearrangement, and verifies the sub-block address mapping after rearrangement; the kernel monitors the MCD bandwidth utilization in real time and updates it through the first text node, and VKD3D dynamically adjusts the memory pool expansion, resource migration strategy, and alignment granularity.

[0014] Furthermore, the memory pool is divided into multiple sub-regions according to resource type and access frequency. The memory pool of the high-bandwidth group is divided into the first rendering target area and the first texture area, the memory pool of the medium-bandwidth group is divided into the second texture area and the second calculation buffer, and the memory pool of the low-bandwidth group is divided into the third static resource area and the spare area.

[0015] Furthermore, an access counter is added to each memory block in the memory pool to count the number of resource accesses within a set number of frames. Memory blocks with access counts greater than a threshold are marked as hot blocks. When new resources are allocated, hot blocks of the same type of sub-region are reused first. When the fragmentation rate of the memory pool is greater than the threshold and the GPU load is less than the threshold, fragment merging is triggered. Small free blocks in the same sub-region are merged into larger blocks. The size of the merged block is adjusted according to the set multiple of the resource type adaptation granularity. The free block list is sorted by a dual key of size and access frequency. Blocks of the same size are arranged in descending order of access frequency.

[0016] Furthermore, the specific method for generating the alignment granularity adapted to RDNA hardware is as follows: the larger of the alignment requirements of the D3D12 application and the minimum alignment granularity of the hardware is used as the basic alignment requirement. The basic alignment requirement is amplified by a factor according to the actual use of the resources. The alignment granularity of the rendering target is the same as the basic alignment requirement. The alignment granularity of the 3D texture is twice the basic alignment requirement, and the alignment granularity of the cube map is four times the basic alignment requirement.

[0017] Furthermore, the method for allocating memory blocks to resources is as follows: if there is a free block that is not less than the total number of bytes of the resource and has the same alignment granularity, then the memory block is allocated to the resource; otherwise, the smallest block that is not less than the total number of bytes of the resource and whose difference from the total number of bytes of the resource is less than a threshold is found and allocated to the resource; if there is no matching block in the sub-region of the current MCD group, then a block is borrowed from other sub-regions in the same bandwidth group first; if borrowing fails, then the memory pool is expanded and rematching is triggered.

[0018] Furthermore, after creating the Vulkan image and binding the memory block, the memory block is checked. If the offset address of the memory block is not an integer multiple of the overwrite alignment granularity, or the physical address exceeds the MCD partition range, a binding rollback is triggered, the allocated memory block is released, and the matching process is re-executed.

[0019] Furthermore, for 2D rendering targets, the hardware reordering instruction uses row-first and block-compact arrangement, with the block size being the block size of the hardware-supported sub-blocks, and no padding between blocks; for 3D textures, the hardware reordering instruction uses slice and row-first arrangement, with the block size being twice the block size of the supported sub-blocks, and the padding between blocks being half of the overridden alignment granularity; for cube maps, the hardware reordering instruction uses face and row-first arrangement, with the block size being the block size of the supported sub-blocks, and the padding between blocks being the overridden alignment granularity.

[0020] Furthermore, the method for verifying the sub-block address mapping after rearrangement is as follows: obtain the mapping table between the virtual address and physical address of each sub-block, traverse the mapping table to check whether the physical address of each sub-block is within the video memory partition range of the corresponding MCD group, and whether the virtual address is an integer multiple of the overwrite alignment granularity. If not, trigger rearrangement retry. If the retry fails, fall back to the default alignment. According to the size of the reclaimed fill space of each memory block, split the reclaimed fill space into small free blocks according to the overwrite alignment granularity and add them to the free block linked list of the corresponding memory pool sub-region.

[0021] Furthermore, a bandwidth and alignment trade-off factor is set. The trade-off factor is the ratio of the current MCD packet utilization rate to the MCD bandwidth utilization rate threshold. When the trade-off factor is greater than 1, the alignment granularity is adjusted to overwrite the product of the alignment granularity and the trade-off factor. When the trade-off factor is not greater than 1, the alignment granularity is adjusted to overwrite the alignment granularity.

[0022] Furthermore, in the RADV driver, alignment exceptions are divided into recoverable basic exceptions and deep exceptions that require rollback. A multi-register cross-checking mechanism is used to determine the exceptions. Among them, basic exceptions include unsupported alignment granularity and memory block binding failure, while deep exceptions include subblock reordering failure, MCD bandwidth exceeding limit, and GCD L2 cache conflict.

[0023] If the alignment granularity is not supported, the driver adjusts the overwritten alignment granularity to the previously used valid value, returns a warning, and VKD3D updates the block granularity of the memory pool without rollback; if memory block binding fails, the matching process is re-executed to bind another memory block with the correct offset address.

[0024] For deep anomalies, the application scenario is identified. For scenarios with a frame rate greater than the threshold, the fallback strategy is to relax the alignment granularity and disable sub-block reordering. For scenarios with image quality greater than the threshold, the fallback strategy is to keep the alignment granularity unchanged and implement sub-block reordering through software. For other scenarios, the fallback strategy is to relax the alignment granularity to twice the overwritten alignment granularity and retain hardware sub-block reordering.

[0025] Beneficial effects:

[0026] This invention, during system startup, reads the native hardware parameters of the RDNA GPU Level 3 register group through the GPU kernel driver and encapsulates them into a structure, then exposes them layer by layer through different nodes. After VKD3D starts, it divides bandwidth groups based on the peak bandwidth of the MCD and builds independent memory pools with different sub-regions for each group. It prioritizes binding the high-bandwidth group's high-frequency rendering target area to the device's local and write-merge type video memory and associates it with the corresponding MCD partition. When the application creates D3D12 resources, VKD3D parses and converts the resource parameters into Vulkan adaptation parameters, calculates the alignment granularity for adapting to RDNA hardware, marks performance priority and access frequency, and classifies them according to resource type. The VKD3D system logically matches memory blocks based on type, MCD grouping, access frequency, and alignment granularity, constructs and binds them to Vulkan images. When multiple resources are allocated to contiguous memory blocks in the same MCD group, VKD3D constructs hardware rearrangement instructions according to resource type, dynamically selects the GPU queue for execution, verifies the sub-block address mapping after rearrangement, and reclaims fill space by splitting it into small free blocks for reuse. The kernel monitors MCD bandwidth utilization in real time and updates it through nodes. Based on this, VKD3D dynamically adjusts memory pool expansion, resource migration strategies, and alignment granularity to achieve a balance between precise memory alignment and performance adaptation. Attached Figure Description

[0027] Figure 1 This is a flowchart illustrating a method for precise alignment of RDNA architecture GPU memory based on hardware subblock rearrangement, provided by the present invention. Detailed Implementation

[0028] The present invention will be described in detail below with reference to the accompanying drawings and embodiments.

[0029] This invention provides a method for precise alignment of GPU memory based on hardware sub-block rearrangement for RDNA architecture. The core idea is to read RDNA through the GPU kernel driver during the system startup phase. The hardware native parameters of the GPU's three-level register group are encapsulated into a structure and then exposed layer by layer through different nodes. After VKD3D starts, it divides the bandwidth into groups based on the peak bandwidth of the MCD and builds an independent memory pool with different sub-regions for each group. The high-bandwidth group's high-frequency rendering target area is preferentially bound to the device local and the corresponding MCD partition. When the application creates D3D12 resources, VKD3D parses and converts the resource parameters into Vulkan adaptation parameters, calculates the alignment granularity, marks performance priority and access frequency for adapting to RDNA hardware, and matches memory blocks according to the logic of resource type, MCD group, access frequency and alignment granularity, and builds and binds Vulkan images. When multiple resources are allocated to consecutive memory blocks in the same MCD group, VKD3D builds hardware rearrangement instructions according to resource type, dynamically selects the GPU queue for submission and execution, verifies the sub-block address mapping after rearrangement, and reclaims the filling space and splits it into small free blocks for reuse. The kernel monitors the MCD bandwidth utilization in real time and updates it through the nodes. VKD3D dynamically adjusts the memory pool expansion, resource migration strategy and alignment granularity accordingly to achieve a balance between accurate memory alignment and performance adaptation.

[0030] This invention provides a method for precise memory alignment of RDNA architecture GPUs based on hardware sub-block rearrangement, the processing flow of which is as follows: Figure 1 As shown, the specific steps include:

[0031] Step 1: The system boots and loads the GPU kernel driver. It accesses the RDNA GPU's three-level register set via the PCIe configuration space, including the GCD global configuration register, MCD memory control and bandwidth register, and block mode and performance register. This yields the GPU's native hardware parameters, including the number of MCDs, minimum image alignment granularity, maximum overwriteable alignment granularity, supported sub-block size, sub-block adjustment step size, GCD L2 cache alignment threshold, MCD peak bandwidth, MCD bandwidth utilization threshold, current GPU performance level, and whether 3D sub-block rearrangement is supported. These native hardware parameters are encapsulated into a first structure. A binary node storing the first structure is constructed, along with a first text node storing the MCD bandwidth, a second text node storing the current GPU performance level, and a third text node storing the supported sub-block size.

[0032] Furthermore, the kernel module initiates periodic dynamic parameter update detection, continuously monitoring the GPU power status, performance level, and MCD bandwidth. If sleep / wake-up, performance level switching, or MCD bandwidth abnormality is detected, the register parameters are immediately re-parsed. If parameter abnormality is detected, a kernel alarm is triggered and the previously valid parameters are reused as a temporary replacement to prevent parameter abnormality from causing subsequent optimization failures.

[0033] Step 2: After VKD3D starts, it reads the first structure through the binary node and the MCD bandwidth distribution through the first text node. Based on the peak bandwidth of the MCD, it sets a larger threshold and a smaller threshold, and divides the MCD into high-bandwidth groups with bandwidth greater than the larger threshold, medium-bandwidth groups with bandwidth not greater than the larger threshold and not less than the smaller threshold, and low-bandwidth groups with bandwidth less than the smaller threshold. It allocates an independent memory pool to each MCD group and divides the memory pool into multiple sub-regions according to resource type and access frequency. The high-bandwidth group memory pool is divided into the first rendering target area and the first texture area, the medium-bandwidth group memory pool is divided into the second texture area and the second calculation buffer, and the low-bandwidth group memory pool is divided into the third static resource area and the spare area. The high-frequency rendering target area of ​​the high-bandwidth group memory pool is preferentially allocated to the memory type with the memory attribute identified as device local memory and write-merged memory. The memory pool is bound to the device mask of the corresponding MCD group, and the physical address of the memory block corresponds to the MCD partition.

[0034] Furthermore, the initial size of the high-bandwidth group memory pool is set to 60% of the total video memory of its corresponding MCD, with an expansion threshold of 85% of the total video memory of the MCD; the initial size of the medium-bandwidth group memory pool is set to 50% of the total video memory of its corresponding MCD, with an expansion threshold of 80% of the total video memory of the MCD; and the initial size of the low-bandwidth group memory pool is set to 40% of the total video memory of its corresponding MCD, with an expansion threshold of 75% of the total video memory of the MCD. Memory blocks in sub-regions within the memory pool are divided according to resource type adaptation granularity. For example, the block size of the first rendering target area is set to the minimum image alignment granularity, and the block size of the third static resource area is set to 8 times the minimum image alignment granularity, with all block sizes being powers of 2.

[0035] To further improve memory block reuse efficiency, reduce fragmentation rate, and accelerate resource allocation, this invention designs a memory block reuse and performance optimization strategy, specifically as follows:

[0036] An access counter is added to each memory block in the memory pool to count the number of resource accesses within a set number of frames. Memory blocks with access counts exceeding a threshold are marked as hot blocks. When new resources are allocated, hot blocks of the same type of sub-region are reused first. When the fragmentation rate of the memory pool exceeds the threshold and the GPU is under low load, fragment merging is triggered, merging small free blocks of the same sub-region into larger blocks. The size of the merged block is adjusted according to a power of 2 of the resource type adaptation granularity. The free block list is sorted by a dual key of size and access frequency. Blocks of the same size are arranged in descending order of access frequency to ensure that high-frequency blocks are reused first, thereby improving the overall access efficiency of the memory pool.

[0037] Step 3: When creating D3D12 resources after application startup, VKD3D parses the resource creation parameters, including key information such as resource type, alignment requirements, and usage scenarios, and maps the D3D12 resource type to the Vulkan equivalent type. Based on the native alignment requirements of the D3D12 application and the minimum alignment granularity of the hardware, the basic alignment requirements of the resources are calculated, and then differentiated adjustments are made according to the resource type to obtain the alignment granularity adapted to RDNA hardware. The usage scenarios of D3D12 resources are mapped to the performance priorities of the Vulkan end, rendering targets are mapped to the high frame rate requirements of the Vulkan end, shader resources are mapped to the high image quality requirements of the Vulkan end, and general read resources are mapped to the balanced requirements of the Vulkan end. The resource state transition frequency of D3D12 resources in each frame is counted, and the resource access frequency is determined based on the value of the transition frequency and the resource usage scenario.

[0038] MCD groups are matched based on resource type, sub-regions are determined based on access frequency, and block sizes are matched based on alignment granularity. If a free block with the same alignment granularity and not less than the total number of bytes of the resource exists, the memory block is allocated to the resource. Otherwise, the smallest block with the same alignment granularity and not less than the total number of bytes of the resource is found and allocated to the resource. If there is no matching block in the sub-region of the current MCD group, a block is borrowed from other sub-regions in the same bandwidth group. If borrowing fails, the memory pool is expanded and rematching is performed.

[0039] Based on the matched memory block information, a Vulkan image is created using the obtained alignment granularity, Vulkan image type, performance priority, MCD grouping, sub-block block size, and block mode. The created Vulkan image is bound to the memory blocks of the pre-aligned memory pool, and the address offset of the bound memory block is obtained. The memory block is checked, and if the offset address is not an integer multiple of the overwrite alignment granularity or the physical address exceeds the MCD partition range, a binding rollback is triggered to release the allocated memory block and re-execute the matching process.

[0040] Specifically, D3D12 resource types are mapped to Vulkan equivalent types. For example, 2D textures are mapped to Vulkan 2D images, 3D textures are mapped to Vulkan 3D images, and buffers are mapped to Vulkan storage buffers.

[0041] Specifically, the basic alignment requirements of resources are calculated based on the native alignment requirements of the D3D12 application and the minimum alignment granularity of the hardware. Then, the alignment granularity is adjusted according to the resource type to adapt to the RDNA hardware. Specifically, the larger value between the native alignment requirements of the D3D12 application and the minimum alignment granularity of the hardware is used as the basic alignment requirement. The basic alignment requirement is multiplied according to the actual use of the resource to adapt to the access characteristics of different resources. The alignment granularity of the rendering target is the same as the basic alignment requirement. The alignment granularity of 3D textures is twice the basic alignment requirement, and the alignment granularity of cube maps is four times the basic alignment requirement.

[0042] The rendering target is mapped to the high frame rate requirement of the Vulkan client, prioritizing frame rate, and the driver adopts a bandwidth-first caching strategy; the shader resources are mapped to the high image quality requirement of the Vulkan client, prioritizing image quality, and the driver adopts an alignment-sensitive precise prefetch strategy; the general read resources are mapped to the balanced requirement of the Vulkan client, balancing frame rate and image quality, and the driver adopts a dynamically adjusted caching strategy.

[0043] Step 4: When multiple D3D12 resources are allocated to contiguous memory blocks in the same MCD group memory pool, VKD3D constructs differentiated hardware reordering instructions based on the resource type. The core parameters of the hardware reordering instructions include source address, target address, number of resources, and alignment granularity. The GPU's idle queue is obtained. If an idle compute queue exists, it is selected to submit the hardware reordering instructions. If the compute queue is busy, the frame interval of the rendering queue is selected to submit the hardware reordering instructions. A one-time dedicated command buffer is created, a memory barrier is set, the reordering instruction parameters are pushed to the GPU command register, the command buffer is encapsulated and submitted, and the reordering is executed.

[0044] After the reordering is completed, obtain the mapping table between the virtual address and physical address of each sub-block. Traverse the mapping table to check whether the physical address of each sub-block is within the video memory partition range of the corresponding MCD group, and whether the virtual address is an integer multiple of the overwrite alignment granularity. If not, it means there is a mapping error, so trigger the reordering retry. If the retry fails, fall back to the default alignment. According to the size of the reclaimed fill space of each memory block, split the reclaimed fill space into small free blocks according to the overwrite alignment granularity and add them to the free block linked list of the corresponding memory pool sub-region.

[0045] VKD3D constructs differentiated hardware rearrangement instructions based on resource type. Specifically: 2D rendering targets are arranged in row-first and block-compact order, with the block size being the size of the sub-blocks supported by the hardware, and no padding between blocks; 3D textures are arranged in slice and row-first order, i.e., first sliced ​​into layers along the Z-axis, then row-first within each layer, with the block size being twice the size of the supported sub-blocks, and the padding between blocks being half the overridden alignment granularity, avoiding hardware conflicts when accessing slices across the Z-axis, and balancing memory saving and access efficiency; cube maps are arranged in face and row-first order, i.e., first divided into six faces of the cube, then row-first within each face, with the block size being the size of the supported sub-blocks, and the padding between blocks being the overridden alignment granularity, adapting to the characteristic of independent access to multiple faces of cube maps and reducing bandwidth loss when accessing cross faces.

[0046] Furthermore, the reordering time, filling and recycling amount, and address mapping accuracy are recorded and written to the reordering log. After block reordering, an empty copy is performed to trigger the GCD L2 cache to prefetch the reordered sub-blocks. For sub-blocks of 3D textures, inter-slice cache isolation is set to avoid conflicts between sub-blocks of different slices in the cache.

[0047] Step 5: The kernel acquires the real-time bandwidth and utilization of each MCD at set intervals, calculates the average bandwidth utilization of the MCD group, and records the real-time data of the MCD group utilization using the first text node. VKD3D monitors the changes of the first text node. When the MCD group utilization is greater than the MCD bandwidth utilization threshold, the memory pool expansion of the group is prohibited, and the low-frequency resources of the group are preferentially migrated to the low-utilization group. When the MCD group utilization is less than a smaller threshold, the memory pool expansion threshold of the group is allowed to be increased to the set value, and the high-frequency resources of other groups are preferentially migrated to the group. When the MCD group utilization is greater than a larger threshold, the alignment granularity is relaxed, and the resource allocation of the low-bandwidth group is disabled.

[0048] Furthermore, a bandwidth and alignment trade-off factor is set, and the alignment granularity is adjusted according to the trade-off factor. Specifically, the trade-off factor is the ratio of the current MCD packet utilization rate to the MCD bandwidth utilization threshold. When the trade-off factor is greater than 1, the alignment granularity is adjusted to overwrite the product of the alignment granularity and the trade-off factor; when the trade-off factor is not greater than 1, the alignment granularity is adjusted to overwrite the alignment granularity. In addition, the trade-off factor adjustment period can be set to avoid performance fluctuations caused by frequent adjustments.

[0049] Furthermore, when the MCD packet utilization rate exceeds a larger threshold for a consecutive number of times, the kernel module outputs an alarm, and VKD3D triggers the bandwidth emergency mode, which suspends unnecessary resource allocation and temporarily compresses some high-frequency resources until the MCD packet utilization rate is less than the safety threshold, after which the normal strategy is restored.

[0050] Furthermore, this invention strengthens layered processing based on the original exception handling, dynamically selecting a fallback strategy according to the exception type and application scenario to avoid performance loss caused by a single fallback. Specifically:

[0051] In the RADV driver, alignment exceptions are divided into recoverable basic exceptions and deep exceptions that require rollback. A multi-register cross-checking mechanism is used to determine exceptions and avoid misjudgments. Basic exceptions include unsupported alignment granularity and memory block binding failure, while deep exceptions include subblock reordering failure, MCD bandwidth exceeding limit, and GCD L2 cache conflict.

[0052] If the alignment granularity is not supported, the driver automatically adjusts the overwrite alignment granularity to the nearest valid value, returns a warning, and VKD3D updates the block granularity of the memory pool without rollback; if memory block binding fails, VKD3D re-executes the matching process and selects another memory block with a matching offset address for binding.

[0053] For deep anomalies, the application scenario is first identified as a high frame rate scenario, a high image quality scenario, or a balanced scenario. The fallback strategy in the high frame rate scenario is to relax the alignment granularity and disable sub-block reordering. The fallback strategy in the high image quality scenario is to keep the alignment granularity unchanged and implement sub-block reordering through software. The fallback strategy in the balanced scenario is to relax the alignment granularity to twice the alignment granularity and retain the hardware sub-block reordering.

[0054] VKD3D records exception types, rollback strategies, and start times, and sets differentiated automatic recovery rules; it records key exception information in the RADV driver and writes it to a specified log file; VKD3D outputs the exception handling process in real time, making it easier for developers to locate hardware compatibility issues.

[0055] Example:

[0056] This embodiment employs a hardware sub-block rearrangement-based RDNA architecture GPU memory precision alignment method provided by the present invention. Through hard-coded hardware parameter parsing, driver interface extension, and precise software layer adaptation, it achieves three-dimensional optimization of alignment, performance, and bandwidth without relying on the VK_MESA_image_alignment_control extension. Simultaneously, it fully leverages the architectural advantages of RDNA2 and RDNA3, resolving the contradictions of alignment padding waste, performance loss, and bandwidth waste. The specific process includes:

[0057] High-precision parsing of hardware alignment and performance parameters for S1, RDNA2, and RDNA3 breaks through the limitations of the Vulkan standard interface. It parses the three-dimensional core parameters of alignment, pixel blocks, and bandwidth from the physical registers of the RDNA hardware, and ensures the accuracy of the parameters through multiple rounds of verification. This provides a hardware-level basis for subsequent alignment control and performance optimization. A high-precision hardware parameter parsing module was added by modifying the Linux kernel source code.

[0058] S1.1 A new kernel module, rdna_align_perf_parser.ko, has been added to the drivers / gpu / drm / amd directory of the Linux kernel. This module accesses the RDNAGPU's three-level register set through the PCIe configuration space, covering alignment, pixel block, and bandwidth parameters.

[0059] GCD Global Configuration Registers (address range 0x1000-0x1FFF): Read the GPU_ARCH_ID (0x1004) register to identify the GPU architecture (RDNA2=0x200, RDNA3=0x300); read the MCD_COUNT (0x1010) register to get the number of MCDs (e.g., 6 for RDNA3); read the GCD_L2_CACHE_ALIGN (0x1020) register to get the alignment sensitivity threshold of the GCD's L2 cache (64 bytes for RDNA2, 32 bytes for RDNA3). Accessing unaligned addresses will cause a decrease in cache hit rate.

[0060] MCD Memory Control and Bandwidth Registers (each MCD corresponds to the 0x2000-0x2FFF address range): Alignment parameters: Read the MCD_MIN_IMAGE_ALIGN (0x2008) register to obtain the minimum image alignment granularity supported by the hardware (0x1000 for RDNA2, i.e., 4KB; 0x800 for RDNA3, i.e., 2KB); Read the MCD_MAX_ALIGN_OVERRIDE (0x2010) register to obtain the maximum rewritable alignment granularity (64KB for both RDNA2 and RDNA3); Pixel block parameters: Read the SUBTILE_BLOCK_SIZE (0x2018) register to obtain the default block size of the hardware block engine. Small (RDNA2 supports 16x16 and 32x32, RDNA3 supports 16x16, 32x32 and 64x64), read the SUBTILE_BLOCK_ADJUST (0x2020) register to get the block size and dynamically adjust the step size (fixed to 16 pixels); bandwidth parameters: read the MCD_PEAK_BANDWIDTH (0x2028) register to get the peak bandwidth of a single MCD (51.2GB / s for RDNA2, 64GB / s for RDNA3), read the MCD_UTILIZATION_THRESHOLD (0x2030) register to get the bandwidth utilization threshold (default 85%, exceeding the threshold will trigger bandwidth throttling);

[0061] Tiling Mode and Performance Registers (0x3000-0x3FFF address range): Read the OPTIMAL_TILE_ALIGN (0x3008) register to get the default alignment granularity (64KB) of the OPTIMAL tiling mode, read the TILE_REARRANGE_CAP (0x3010) register to confirm the supported type of hardware sub-tiling rearrangement (RDNA2 supports 2D rearrangement, RDNA3 supports 2D or 3D rearrangement); read the GPU_PERF_LEVEL (0x3018) register to get the current performance level of the GPU (0x01 for low load, 0x02 for medium load, and 0x03 for high load).

[0062] S1.2 Parameter structured storage and precision verification:

[0063] The parsed hardware parameters are encapsulated into an RDNAAlignPerfHardwareParams structure, with added bandwidth and cache alignment parameters defined as follows:

[0064] typedef struct {

[0065] uint32_t gpu_arch; / / 0x200=RDNA2, 0x300=RDNA3

[0066] uint32_t mcd_count; / / Number of MCDs

[0067] uint32_t min_image_align; / / Minimum image alignment granularity (bytes)

[0068] uint32_t max_align_override; / / Maximum overwriteable alignment granularity (bytes)

[0069] uint32_t subtile_block_sizes[3]; / / Supported subtile block sizes (pixels), such as [16, 32, 64]

[0070] uint32_t subtile_adjust_step; / / Subtile adjustment step size (pixels)

[0071] uint32_t gcd_l2_cache_align; / / GCD-L2 cache alignment threshold (bytes)

[0072] uint32_t mcd_peak_bandwidth[8]; / / Peak bandwidth (MB / s) for each MCD, supporting 8 MCDs

[0073] uint32_t mcd_bandwidth_threshold; / / MCD bandwidth utilization threshold (%)

[0074] uint32_t gpu_perf_level; / / Current GPU performance level (1 to 3)

[0075] bool subtile_3d_support; / / Whether to support 3D subtiling rearrangement (true for RDNA3)

[0076] } RDNAAlignPerfHardwareParams;

[0077] Precision verification mechanism: Perform three consecutive reads on each register. If the three reads are consistent, the parameter is confirmed to be valid. If there is a difference, take the mode of the three results. If there is no mode, reread until two consecutive reads are consistent, thus avoiding register noise error from a single read.

[0078] S1.3, Layered exposure of Sysfs interfaces:

[0079] Create four types of Sysfs nodes under the path / sys / class / drm / card0 / rdna_align_perf / :

[0080] The binary node hardware_params_full stores the complete RDNAAlignPerfHardwareParams structure, allowing VKD3D to read all parameters.

[0081] Text node mcd_bandwidth_map: Writes the bandwidth of each MCD in the format of MCD ID: peak bandwidth (e.g., 0:64000, 1:64000, 2:62000, edge MCDs have slightly lower bandwidth).

[0082] The text node gpu_perf_level updates the GPU performance level (1 to 3) in real time, with an update cycle of 50ms.

[0083] Text node subtile_block_support: Writes the supported subtile block size (e.g., 16, 64).

[0084] Access control: All nodes are set to permissions 0644 to ensure that the VKD3D process can read the data, and the kernel module verifies the legitimacy of the access process through the drm_permission_check function to prevent malicious programs from tampering with the data.

[0085] S1.4 Parameter Dynamic Update and Anomaly Alarm:

[0086] The kernel module checks the GPU's POWER_STATE (0x1000) and MCD_STATUS (0x2000) registers every 50ms. If it detects that the GPU has woken up from sleep, switched performance levels (such as switching from low load to high load), or the MCD bandwidth is abnormal, it immediately re-parses the register parameters and updates the Sysfs node.

[0087] If a parameter is detected to be outside the normal range (e.g., min_image_align < 2KB), a kernel warning is triggered (output via pr_warn), and the previously valid parameter is used as a temporary replacement to prevent subsequent optimizations from failing due to parameter abnormalities.

[0088] S2. Construct a pre-aligned memory pool that matches both the bandwidth and resource type of RDNA MCD. The goal is to build a pre-aligned memory pool in VKD3D that is hierarchical for MCD bandwidth and adapted to resource types. The granularity of the memory blocks in the pool is strictly consistent with the minimum alignment granularity of the hardware, and the regions are divided according to the resource access frequency and MCD bandwidth level. Simulate the maxImageAlignment parameter declaration and alignmentPriority performance trade-off logic of VK_MESA_image_alignment_control to provide memory blocks with accurate alignment and performance adaptation for subsequent resource allocation. This requires modification of the VKD3D memory management module.

[0089] S2.1 Hardware parameter reading and memory pool initialization:

[0090] When VKD3D starts, it reads the RDNAAlignPerfHardwareParams structure through fopen(" / sys / class / drm / card0 / rdna_align_perf / hardware_params_full", "rb") and reads the MCD bandwidth distribution of the mcd_bandwidth_map node through fscanf.

[0091] If the read fails (e.g., with a non-RDNA architecture GPU), it falls back to the default 64KB aligned memory pool and terminates the subsequent optimization process. If the read succeeds, the MCDs are divided into high-bandwidth groups (bandwidth not less than 95% of the peak bandwidth), medium-bandwidth groups (bandwidth not less than 85% and less than 95% of the peak bandwidth), and low-bandwidth groups (bandwidth less than 85% of the peak bandwidth) based on mcd_count and mcd_peak_bandwidth. For example, in the 6 MCDs of RDNA3, MCDs 0, 1, and 2 are in the high-bandwidth group, MCDs 3 and 4 are in the medium-bandwidth group, and MCD 5 is in the low-bandwidth group.

[0092] S2.2, MCD bandwidth and resource type dual-dimensional memory pool creation:

[0093] A three-tiered memory pool is created based on MCD grouping: each MCD group corresponds to an independent memory pool, and each memory pool is divided into sub-regions according to resource type and access frequency.

[0094] High-bandwidth memory pool: divided into a high-frequency rendering target area (stores rendering targets updated every frame, with an alignment granularity of min_image_align) and a high-frequency texture area (stores textures within the player's view, with an alignment granularity twice that of min_image_align).

[0095] Mid-bandwidth memory pool: divided into mid-frequency texture area (stores distant textures, with an alignment granularity of 4 times min_image_align) and mid-frequency calculation buffer (stores temporary data for calculation shaders, with an alignment granularity of 2 times min_image_align);

[0096] Low-bandwidth memory pool: divided into a low-frequency static resource area (stores static model textures, with an alignment granularity of 8 times that of min_image_align) and a spare area (stores temporarily reclaimed resources, with an alignment granularity of 4 times that of min_image_align).

[0097] Memory pool size configuration:

[0098] The initial size of the high-bandwidth group memory pool is 60% of the total video memory of the corresponding MCD (e.g., if the RDNA3 high-bandwidth MCD is 2GB, the initial pool size is 1.2GB), and the expansion threshold is 85% of the total video memory of the MCD;

[0099] The initial size of the memory pool for the medium bandwidth group is 50% of the total video memory of the corresponding MCD, and the expansion threshold is 80% of the total video memory of the MCD;

[0100] The initial size of the low-bandwidth group memory pool is 40% of the total video memory of the corresponding MCD, and the expansion threshold is 75% of the total video memory of the MCD;

[0101] Memory block granularity control: The memory blocks of each sub-region are divided according to the resource type adaptation granularity. For example, the block size of the high-frequency rendering target area is min_image_align (2KB for RDNA3), and the block size of the low-frequency static resource area is 8 times min_image_align (16KB for RDNA3). All block sizes are powers of 2 to ensure accurate alignment.

[0102] S2.3, The memory pool's memory type is bound to bandwidth:

[0103] Vulkan’s vkGetPhysicalDeviceMemoryProperties2 interface is used to obtain the VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT | VK_MEMORY_PROPERTY_WRITE_COMBINED_BIT type memory of the RDNA GPU (taking into account both local video memory and write performance), and the high-frequency rendering target area of ​​the high-bandwidth memory pool is preferentially allocated to this type of memory.

[0104] The deviceMask parameter of VkMemoryAllocateFlagsInfo2 strictly binds each memory pool to the device mask of the corresponding MCD group (e.g., the mask for high bandwidth groups MCD0, 1, and 2 is 0x07). The VK_MEMORY_ALLOCATE_BINDING_BIT parameter of VkMemoryAllocateFlags ensures that the physical address of the memory block strictly corresponds to the MCD partition, avoiding cross-MCD address mapping.

[0105] S2.4 Memory Block Reuse and Performance Optimization Strategies:

[0106] Hotspot resource priority reuse: Add an access counter to each memory block to record the number of resource accesses in the last 100 frames, and mark the blocks with an access count of not less than 80 as hotspot blocks; when new resources are allocated, hotspot blocks of the same type of sub-region are reused first to reduce the memory initialization overhead of reallocation (RDNA hardware initialization of new memory blocks requires 20 to 30 ns, while reusing blocks only requires 5 to 8 ns).

[0107] Fragmentation merging trigger condition: When the fragmentation rate of the memory pool (the quotient of the total size of free blocks and the total size of allocated blocks) is greater than 40%, and the GPU is under low load (gpu_perf_level=1), fragmentation merging is triggered, that is, small free blocks in the same sub-region are merged into larger blocks. The size of the merged block is adjusted according to 2^n times the resource type adaptation granularity, such as merging 4 2KB blocks into 8KB blocks (adapting to the intermediate frequency calculation buffer).

[0108] Free block sorting optimization: The free block linked list is sorted by both size and access frequency. Blocks of the same size are arranged in descending order of access frequency to ensure that high-frequency blocks are reused first, thereby improving the overall access efficiency of the memory pool.

[0109] S3. Modify the RADV driver to add an RDNA alignment overwrite and performance linkage interface. The goal is to add a private interface for alignment overwrite and performance linkage in the RADV driver, allowing VKD3D to pass three-dimensional parameters of alignment granularity, resource type, and performance priority. The driver will then dynamically adjust the memory layout and GCD L2 cache strategy in the OPTIMAL block mode based on these parameters, implementing alignment declaration and performance trade-off functions similar to VK_MESA_image_alignment_control. This requires modifying the resource (memory, cache, etc.) management module of the RADV driver.

[0110] S3.1 Private Extension Definition and Parameter Passing:

[0111] A new private extension, VK_AMD_rdna_align_perf_link, has been added to the RADV driver's extension definition. This extension defines the core structure VkImageRDNAAlignPerfLinkInfoAMD, which supports 3D parameter passing.

[0112] typedef struct {

[0113] VkStructureType sType; / / VK_STRUCTURE_TYPE_IMAGE_RDNA_ALIGN_PERF_LINK_INFO_AMD

[0114] const void* pNext; / / Pointer to the next structure

[0115] uint32_t override_align; / / Override alignment granularity (from the type adaptation granularity of the pre-aligned memory pool)

[0116] VkImageType image_type; / / Resource type (VK_IMAGE_TYPE_2D / VK_IMAGE_TYPE_3D, etc.)

[0117] uint32_t performance_priority; / / Performance priority (1 for high image quality, 2 for balanced, 3 for high frame rate)

[0118] uint32_t mcd_group_id; / / The bound MCD group ID (0 for high bandwidth, 1 for medium bandwidth, 2 for low bandwidth)

[0119] uint32_t subtile_block_size; / / Subtiling block size (in pixels, from subtile_block_sizes)

[0120] } VkImageRDNAAlignPerfLinkInfoAMD;

[0121] Register this extension in the RADV extension management module. It is only enabled for RDNA2 and RDNA3 architecture GPUs (determined by the radv_physical_device_is_rdna function). This extension is automatically disabled for non-RDNA architecture GPUs.

[0122] S3.2, OPTIMAL tiling alignment logic and resource type adaptation:

[0123] Modify the radv_image_create function in the RADV driver to add 3D parameter-driven logic:

[0124] The first step is parameter parsing and validity verification, which involves reading the override_align and image_type of VkImageRDNAAlignPerfLinkInfoAMD, checking whether override_align is between min_image_align and max_align_override, and whether it is a power of 2; if not, it is automatically adjusted to the nearest valid value, and a VK_WARNING_AMD_ALIGN_ADJUSTED warning is returned through VkResult.

[0125] The second step is resource type and alignment granularity matching, which involves dynamically adjusting the alignment granularity based on the image_type:

[0126] VK_IMAGE_TYPE_2D (render target): Use override_align (e.g., 2KB for RDNA3). Since the rendering target needs to be written frequently, a small alignment granularity can reduce latency.

[0127] VK_IMAGE_TYPE_3D (3D texture): Uses twice the size of override_align (e.g., 4KB for RDNA3). Since 3D textures have a large access range, a slightly larger alignment can improve cache hit rate.

[0128] VK_IMAGE_TYPE_CUBE (cube texture): Uses 4 times the override_align (e.g., 8KB for RDNA3). Since cube textures require storage of multiple faces, adapting the block size can reduce cross-block access.

[0129] The third step is MCD group binding, which restricts resource allocation to the video memory partition of the corresponding MCD group based on mcd_group_id, and obtains the group device mask through the radv_mcd_group_get_device_mask function to avoid bandwidth waste caused by cross-group allocation;

[0130] S3.3 Performance priority is linked to GCD-L2 cache:

[0131] Modify the `radv_cache_configure` function in the RADV driver to adjust the GCD's L2 cache strategy based on the `performance_priority` parameter:

[0132] High quality (Level 1): Enables alignment-sensitive prefetching, which means that L2 cache prefetching is only performed on memory blocks with aligned addresses. The prefetch size is the product of subtile_block_size and the number of bytes per pixel (e.g., for 32x32 pixels, 4 bytes per pixel, the prefetch size is 4096 bytes), improving the access efficiency of quality-sensitive resources.

[0133] Balanced (Level 2): ​​Enables dynamic prefetching, which adjusts the prefetch size according to the GPU load (gpu_perf_level). The prefetch size is reduced under high load (to avoid cache conflicts) and increased under low load.

[0134] High frame rate (Level 3): Enables bandwidth-first prefetching, which prioritizes prefetching resources of high-bandwidth MCD groups. The prefetch size is twice that of override_align, reducing memory latency in frame rate-sensitive scenes.

[0135] In the radv_image_layout_transition function, the image layout transition speed is adjusted according to performance_priority: in high frame rate mode, some unnecessary layout checks are skipped, and the transition latency is reduced from 100ns to 50ns; in high quality mode, layout verification is added to ensure texture sampling accuracy.

[0136] S3.4, Driver Layer Alignment - Performance Cache Optimization:

[0137] Add a new radv_align_perf_cache cache table to the RADV driver. The cache key is the triplet override_align, image_type, and mcd_group_id. The cache value is the GCD L2 cache configuration, subblock size, and MCD device mask.

[0138] The cache eviction policy adopts LRU (Least Recently Used) and performance weights: the cache item weight is 3 in high frame rate mode, 2 in balanced mode, and 1 in high quality mode. Cache items with higher weights are retained first to avoid frequent cache rebuilds.

[0139] Cache update mechanism: When the GPU performance level (gpu_perf_level) is switched, the cache entry with the corresponding performance priority in the cache table is automatically updated to ensure that the cache configuration matches the current performance requirements.

[0140] The goal of precise mapping and address verification of S4 and D3D12 resources to the pre-aligned memory pool is to parse the resource description of D3D12 into Vulkan resource creation parameters, achieve pre-alignment allocation through precise matching of resource type and memory pool sub-regions, and add a memory block address verification mechanism to ensure alignment accuracy. This simulates the application-demand-based memory allocation logic of VK_MESA_image_alignment_control, which requires modification of the VKD3D resource management module.

[0141] In-depth analysis of S4.1 and D3D12 resource alignment and performance requirements:

[0142] Parse the D3D12_RESOURCE_DESC structure of D3D12, extract the core parameters, and convert them into Vulkan adaptation parameters:

[0143] Resource type mapping: Map D3D12_RESOURCE_DIMENSION_TEXTURE2D to VK_IMAGE_TYPE_2D, D3D12_RESOURCE_DIMENSION_TEXTURE3D to VK_IMAGE_TYPE_3D, and D3D12_RESOURCE_DIMENSION_BUFFER to VK_BUFFER_USAGE_STORAGE_BIT;

[0144] Alignment requirement calculation: Based on the D3D12_RESOURCE_DESC::Alignment parameter (default is 4KB if not specified) and the RDNA hardware's min_image_align, the larger of the two values ​​is taken as the basic alignment requirement; then adjusted according to resource type: the basic alignment requirement of the rendering target (D3D12_RESOURCE_FLAG_ALLOW_RENDER_TARGET) is 2 times that of 3D textures and 4 times that of cube maps;

[0145] Performance requirement assessment: Performance priority is determined based on the D3D12_RESOURCE_DESC::Usage parameter: D3D12_RESOURCE_USAGE_RENDER_TARGET (rendering target) is for high frame rate requirements, D3D12_RESOURCE_USAGE_SHADER_RESOURCE (shader resources) is for high image quality requirements, and D3D12_RESOURCE_USAGE_GENERIC_READ (general read) is for balanced requirements;

[0146] New resource access frequency prediction: Based on the D3D12_RESOURCE_STATES state transition frequency of D3D12 resources (e.g., no less than 3 transitions per frame for high-frequency resources), combined with the game scene (identifying game type through the VKD3D_game_detect function, e.g., rendering targets for FPS games are high-frequency resources), the access frequency level of resources is marked as high-frequency, medium-frequency, and low-frequency.

[0147] S4.2, Precise matching of sub-regions in the pre-aligned memory pool:

[0148] The matching logic employs a three-level filtering approach: resource type, access frequency, and MCD bandwidth group.

[0149] The first level matches memory pool sub-regions according to resource type. For example, 2D rendering targets match the high-frequency rendering target area of ​​the high-bandwidth group memory pool, and 3D textures match the medium-frequency texture area of ​​the medium-bandwidth group memory pool.

[0150] The second level filters memory blocks by access frequency. High-frequency resources are matched only from hot blocks in high-frequency sub-regions, mid-frequency resources are matched from mid-frequency sub-regions, and low-frequency resources are matched from low-frequency sub-regions.

[0151] The third level matches the block size according to the alignment requirements. It searches for free blocks whose block size is not less than the total number of resource bytes and whose block alignment meets the resource alignment requirements. If a completely matching block exists, it is allocated directly. If not, it searches for the smallest block whose block size is not less than the total number of resource bytes, and the difference between the block size and the total number of resource bytes is not greater than override_align (to avoid excessive memory waste).

[0152] Matching failure handling: If there is no matching block in the sub-region of the current MCD group, prioritize borrowing blocks from other sub-regions in the same bandwidth group (e.g., if there is no block in the high-frequency rendering target area, borrow blocks with the same alignment granularity from the high-frequency texture area), and the number of borrowing attempts shall not exceed 3; if borrowing fails, trigger memory pool expansion, and rematch after expansion.

[0153] S4.3, Precise Construction of Vulkan Image Creation Parameters:

[0154] Based on the matched memory block information, a Vulkan VkImageCreateInfo structure is constructed, and an AMD-specific extended VkImageRDNAAlignPerfLinkInfo structure is attached, with parameters strictly matching hardware and performance requirements.

[0155] `override_align` is set to the alignment requirements of the resource (e.g., RDNA3 2D rendering target is 2KB).

[0156] Set image_type to the mapped Vulkan image type;

[0157] Set performance_priority to the parsed performance priority (1 to 3);

[0158] Set mcd_group_id to the MCD group ID (0 to 2) corresponding to the memory pool;

[0159] The subtile_block_size is set to the block size that S1 resolves and that matches the resource type (e.g., 32*32 pixels for 2D rendering targets).

[0160] The tiling parameter is fixed at VK_IMAGE_TILING_OPTIMAL to ensure the hardware performance advantages of RDNA.

[0161] S4.4 Resource binding and address dual verification:

[0162] The first step is memory block binding, which involves binding the created Vulkan image to the memory block of the pre-aligned memory pool through Vulkan's vkBindImageMemory2 interface (which supports multiple memory bindings). After binding, the memoryOffset parameter of VkBindImageMemoryInfo is read to confirm whether the offset address of the memory block is an integer multiple of override_align (e.g., the offset address of a 2KB aligned block must be an integer multiple of 0x800).

[0163] The second step is physical address verification, which involves obtaining the physical memory requirements of the image through the vkGetImageMemoryRequirements2 interface, calling the GCD_MCD_ADDR_MAP register of RDNA to read the physical address of the memory block, and checking whether the physical address matches the memory partition address range of the MCD group (e.g., the address range of the high bandwidth group MCD0 is 0x00000000 to 0x07FFFFFF).

[0164] The third step is alignment anomaly interception. If the address verification fails (such as the offset address not being an integer multiple of the alignment address or the physical address exceeding the MCD partition range), the binding rollback is immediately triggered, the allocated memory block is released, and the S2 matching process is re-executed to avoid GPU access errors caused by alignment failure.

[0165] S4.5 Performance adaptation after binding:

[0166] For high-frequency resources (such as rendering targets), a high-frequency resource marker is added to the memory block through the vkSetDebugUtilsObjectNameEXT interface. After the RADV driver recognizes the marker, it adds the physical address of the memory block to the GCD's L2 cache warm-up list, and completes the cache warm-up before the resource is accessed for the first time, reducing the latency of the first access.

[0167] For low-frequency resources (such as static textures), the resource initialization task is scheduled to the GPU's idle time period (such as the interval between two frames) through the vkQueueSubmit2 interface to avoid occupying rendering time.

[0168] S5 utilizes the precise rearrangement and address mapping verification of the RDNA hardware sub-blocking engine. The goal is to use the hardware sub-blocking engines of RDNA2 and RDNA3 to perform resource type-adaptive sub-block rearrangement of allocated memory blocks, eliminating padding space. At the same time, a new sub-block address mapping verification mechanism is added to ensure the correctness of GPU access. This is a hardware-level enhancement of the VK_MESA_image_alignment_control function to reduce padding waste, and requires modification of the VKD3D command management module.

[0169] S5.1 Resource type adaptation construction for sub-tiling reordering instructions:

[0170] When multiple D3D12 resources are allocated to contiguous memory blocks within the same MCD grouped memory pool, VKD3D constructs differentiated SUBTILE_REARRANGE hardware instructions based on the resource type:

[0171] 2D rendering target: row priority and compact block arrangement, subtiling block size is subtile_block_size (e.g., 32x32 pixels), no padding between blocks (padding space is 0), rearrange_mode in the instruction parameter is set to 0x01;

[0172] 3D textures: Slice to row priority arrangement (slice by Z-axis first, then arrange by row), subtiling block size is twice the subtile_block_size (e.g., 64*32 pixels), inter-block padding is half of override_align (e.g., 1KB for RDNA3), to avoid cross-slice access conflicts, rearrange_mode is set to 0x02 in the instruction parameters;

[0173] Cube texture: Use face-to-row priority arrangement (arrange by cube faces first, then by rows), subtile block size is subtile_block_size (e.g., 32*32 pixels), inter-block padding is override_align (e.g., 2KB for RDNA3), and rearrange_mode is set to 0x03 in the instruction parameters;

[0174] The core parameters of the instruction also include:

[0175] Source address: The starting physical address of a contiguous block of memory in the pre-aligned memory pool;

[0176] Target address: Same as source address (only adjusts the block layout, does not change the physical address range);

[0177] Resource quantity: The number of D3D12 resources that need to be rearranged (not more than 16, to avoid excessive instruction complexity);

[0178] Alignment granularity: override_align (ensures that the rearranged blocks are aligned as required).

[0179] S5.2 Dynamic selection of rearrangement timing and instruction submission:

[0180] Reordering timing determination: Obtain the GPU's idle queue through the vkGetDeviceQueueFamilyProperties2 interface. If an idle compute queue (VK_QUEUE_COMPUTE_BIT) exists, submit the reordering instruction to the compute queue (without occupying the rendering queue); if the compute queue is busy, submit the reordering instruction to the frame gap period of the rendering queue (set the event through vkCmdSetEvent, and execute it between two frames).

[0181] Instruction submission process:

[0182] The first step is to create a dedicated command buffer for reordering using vkBeginCommandBuffer, and set the flags to VK_COMMAND_BUFFER_USAGE_ONE_TIME_SUBMIT_BIT (one-time commit, reducing overhead);

[0183] The second step is to set a memory barrier using vkCmdPipelineBarrier2 to ensure that the memory block is writable before reordering (VK_ACCESS_2_MEMORY_WRITE_BIT).

[0184] The third step is to push the SUBTILE_REARRANGE instruction parameters to the GPU's command register using vkCmdPushConstants;

[0185] The fourth step is to submit the command buffer through vkEndCommandBuffer and vkQueueSubmit2 and wait for the reordering to complete (set the waiting time to no more than 1ms through vkWaitForFences to avoid blocking).

[0186] S5.3, Subtiling Block Address Mapping Verification and Filling Reclamation:

[0187] Address mapping verification:

[0188] After the rearrangement is completed, the layout information of each subtiling block is obtained through the vkGetImageSubresourceLayout interface, the SUBTILE_ADDR_TABLE (address range 0x4000 to 0x4FFF) register of RDNA is read, and the virtual address to physical address mapping table of the subtiling block is obtained.

[0189] Traverse the mapping table and check whether the physical address of each sub-tiling block is within the memory partition range of the corresponding MCD group and whether the virtual address is an integer multiple of override_align; if there is a mapping error, trigger a reordering retry (the number of retries is no more than 2); if the retry fails, fall back to the default alignment.

[0190] Precise recycling of filling space:

[0191] After the hardware sub-tiling engine completes the rearrangement, it returns the size of the reclaimed padding space for each memory block (accurate to bytes) through the / sys / class / drm / card0 / rdna_align_perf / freed_paddingSysfs node.

[0192] VKD3D splits the reclaimed fill space into small free blocks at the override_align granularity (e.g., reclaiming 32KB of fill space is split into 16 2KB blocks), and adds them to the free block linked list of the corresponding memory pool sub-region for subsequent allocation of small resources (such as UI textures). The fill space reclamation rate is no less than 90%.

[0193] S5.4 Performance optimization and debugging after rearrangement:

[0194] Cache preheating: Perform an empty copy (the source image and the target image are the same image) through the vkCmdCopyImage interface, triggering the GCD L2 cache to prefetch the rearranged subtiling blocks, improving the cache hit rate to over 95%;

[0195] Performance monitoring: Add sub-tiling reordering performance statistics to the VKD3D_command_debug module to record reordering time, fill recycling amount, and address mapping accuracy. Write the data to the log using the VKD3D_log function (log path is / var / log / VKD3D_align.log) to help developers optimize reordering strategies.

[0196] Special optimizations for 3D resources: For subtiling blocks of 3D textures, cache isolation between slices is set through vkCmdBindImageMemoryBarrier to avoid conflicts between subtiling blocks of different slices in the cache, reducing 3D texture sampling latency by 10 to 15ns.

[0197] S6, Real-time monitoring and dynamic adjustment of video memory bandwidth, aims to dynamically adjust the memory pool allocation strategy by monitoring the bandwidth utilization of RDNA MCD in real time, avoiding bandwidth waste caused by alignment optimization, and achieving coordinated optimization of alignment and bandwidth.

[0198] S6.1 Real-time monitoring of kernel layer bandwidth:

[0199] A new mcd_bandwidth_monitor thread was added to the AMD GPU driver module in the kernel (AMD GPU driver is open source). Every 20ms, the MCD_CURRENT_BANDWIDTH (0x2038) register and MCD_UTILIZATION (0x2040) register of each MCD were read to obtain the real-time bandwidth and utilization.

[0200] Calculate the average bandwidth utilization of MCD groups: High bandwidth group utilization = (MCD0 utilization + MCD1 utilization + MCD2 utilization) / 3, and the same applies to medium bandwidth groups and low bandwidth groups;

[0201] Create a text node named mcd_bandwidth_util under the path / sys / class / drm / card0 / rdna_align_perf / , and write real-time data in the format of group ID:utilization (e.g., 0:75, 1:60, 2:50, in %).

[0202] S6.2, VKD3D layer bandwidth adaptation strategy:

[0203] VKD3D monitors the changes of the mcd_bandwidth_util node through the poll function, reading bandwidth utilization data every 50ms.

[0204] Dynamically adjust memory pool allocation strategy based on bandwidth utilization:

[0205] When the utilization rate of a certain MCD group is greater than mcd_bandwidth_threshold (85% of parsed data): the memory pool expansion of the group is prohibited to avoid the addition of resources consuming more bandwidth; the low-frequency resources of the group are preferentially migrated to the low-utilization group (e.g., when the high bandwidth group utilization rate is 90%, the low-frequency static resources are migrated to the low bandwidth group). The migration is performed through the vkCmdCopyImage interface and is only triggered when the GPU is under low load.

[0206] When the utilization rate of a certain MCD group is less than 50%, the memory pool expansion threshold of the group is allowed to be increased by 10% (e.g., the expansion threshold of the high bandwidth group is increased from 85% to 95%), increasing the resource allocation; high-frequency resources of other groups are preferentially migrated to this group to improve the access bandwidth of high-frequency resources;

[0207] When all packet utilization is greater than 90% (bandwidth strain): temporarily relax the alignment granularity (e.g., relax RDNA3 from 2KB to 4KB) to reduce the bandwidth consumption of sub-tiling rearrangement; disable resource allocation for low-bandwidth groups and only retain allocation for high and medium-bandwidth groups to avoid bandwidth bottlenecks.

[0208] S6.3 Dynamic trade-offs between bandwidth and alignment:

[0209] Added bandwidth and alignment trade-off factor: Trade-off factor = (current bandwidth utilization / mcd_bandwidth_threshold). When the trade-off factor is greater than 1, the alignment granularity is the product of override_align and the trade-off factor (rounded up to the power of 2); when the trade-off factor is not greater than 1, the alignment granularity is override_align. For example: RDNA3 has override_align = 2KB, mcd_bandwidth_threshold = 85%, and the current bandwidth utilization is 93.5% (trade-off factor is 1.1), then the alignment granularity is 2KB * 1.1 ≈ 2.2KB, which is 4KB when rounded up to the power of 2. The trade-off factor adjustment period is 100ms to avoid performance fluctuations caused by frequent adjustments.

[0210] S6.4 Bandwidth Anomaly Alarms and Handling:

[0211] When the bandwidth utilization of a certain MCD exceeds 95% for three consecutive times (severe over-limit), the kernel module outputs an alarm through pr_warn, and VKD3D triggers the bandwidth emergency mode: suspending unnecessary resource allocation (such as preloading of static textures); temporarily compressing some high-frequency resources (such as rendering targets from non-player perspectives) (using the BC7 compression format supported by RDNA hardware), with a compression ratio of 2:1, to reduce bandwidth usage; the emergency mode continues until the bandwidth utilization is less than 80%, and then automatically resumes the normal strategy.

[0212] S7. Alignment anomaly layering and rollback based on RDNA architecture: This enhances layering processing on the basis of the original anomaly handling. The goal is to dynamically select the rollback strategy based on the anomaly type and game scene to avoid performance loss caused by a single rollback. It is an extension of the compatibility guarantee function of VK_MESA_image_alignment_control and requires modification of the VKD3D device management module and the RADV driver error handling module.

[0213] S7.1 Fine-grained classification and detection of alignment anomalies:

[0214] In the radv_align_error_detect function of the RADV driver, exceptions are divided into basic exceptions and deep exceptions:

[0215] Basic exceptions (recoverable): Alignment granularity not supported (ALIGN_ERROR), override_align < min_image_align or > max_align_override; Memory block binding failed (BIND_ERROR), memory block offset address is not an integer multiple of the alignment;

[0216] Deep anomalies (requiring rollback): Subtiling reordering failure (SUBTILE_ERROR), reordering fails after 2 retries, or subtiling block address mapping error rate is greater than 5%; MCD bandwidth overrun anomaly (BANDWIDTH_ERROR), resource allocation causes MCD bandwidth utilization to be greater than 95% for 5 consecutive times; GCD L2 cache conflict (CACHE_ERROR), unaligned address access causes cache hit rate to be less than 50%;

[0217] Enhanced detection mechanism: Multi-register cross-checking is adopted. For example, when detecting SUBTILE_ERROR, the SUBTILE_STATUS (0x4004) and GPU_ERROR_STATUS (0x1030) registers are read simultaneously. Only when both are set is it determined to be a deep anomaly, thus avoiding false positives.

[0218] S7.2, Exception handling strategy:

[0219] Basic exception handling (recoverable, no alignment rollback): Alignment granularity not supported: The driver automatically adjusts override_align to the nearest valid value (e.g., when RDNA3 override_align=1KB, adjust to 2KB), returns a warning via VK_WARNING_AMD_ALIGN_ADJUSTED, and VKD3D updates the block granularity of the memory pool without rollback; Memory block binding failure: VKD3D re-executes the S4 matching process, selects another memory block with a matching offset address, and retries binding no more than 3 times. After a successful retry, it can be used normally.

[0220] Deep anomaly handling (requires rollback, scene-specific strategy selection): Scene judgment: The game scene is identified by the VKD3D_game_detect function and divided into high frame rate scenes (such as FPS games with a frame rate of not less than 100fps), high image quality scenes (such as RPG games with a resolution of not less than 4K), and balanced scenes.

[0221] High frame rate scenario fallback: Prioritize frame rate protection. The fallback strategy is to relax the alignment granularity and disable sub-tiling. The alignment granularity is relaxed to 4 times that of override_align (e.g., from 2KB to 8KB in RDNA3) to reduce bandwidth consumption. The hardware sub-tiling engine is disabled, and the default layout of OPTIMAL tiling is adopted to avoid frame rate fluctuations caused by reordering failure.

[0222] High-quality scene rollback: Prioritize image quality, the rollback strategy is to keep the alignment granularity unchanged and use software sub-tiling. The alignment granularity remains override_align, and the sub-tiling is rearranged through the software layer of VKD3D (the software rearrangement latency is 50ns higher than the hardware, but there is no loss of image quality); enable GCD's L2 cache to force prefetching to ensure the resource access efficiency after software rearrangement;

[0223] Balanced scene fallback: adopts an intermediate strategy, relaxes the alignment granularity to twice that of override_align, retains hardware sub-tiling (but reduces the reordering frequency, executing once every 3 frames).

[0224] S7.3, Status Management and Recovery During Abnormal Rollback:

[0225] Add a new VKD3D_align_error_state structure to VKD3D to record the exception type, rollback strategy, and rollback start time;

[0226] Rollback and recovery mechanism: For basic anomalies, the recovery time is 500ms. If no further anomalies occur within 500ms, the original alignment strategy will be automatically restored. For deep anomalies, the recovery time is 3000ms, and the original strategy will only be automatically restored if two conditions are met: GPU load is less than medium load (gpu_perf_level=1) and MCD bandwidth utilization is less than 70%. Manual recovery interface: The manual recovery interface is exposed through the VKD3D_set_align_policy function, allowing the game to trigger recovery through D3D12 extended functions to meet special scenario requirements.

[0227] S7.4, Exception Logs and Debugging Optimization:

[0228] Add a new function radv_align_error_log to the RADV driver to record the time of exception occurrence, exception type, register status, and rollback strategy, and write the log to / var / log / radv_align_error.log;

[0229] A new exception debugging mode has been added to VKD3D, which can be enabled by setting the environment variable VKD3D_ALIGN_DEBUG=1. Once enabled, the exception handling process is output in real time, making it easier for developers to locate hardware compatibility issues.

[0230] Experiments have verified that this invention has the following beneficial effects compared with the prior art:

[0231] It achieves a dual improvement in alignment accuracy and memory saving efficiency. Through high-precision hardware parameter analysis, two-dimensional matching of the pre-aligned memory pool, and dual address verification, it realizes micron-level alignment control. Without relying on VK_MESA_image_alignment_control, it accurately reduces the image alignment granularity of RDNA2 and RDNA3 GPUs from 64KB to 4KB and 2KB, respectively, with alignment fill space elimination rates of 93.75% and 96.875%. In texture-intensive games at 4K resolution, VRAM usage is reduced by 40% to 50%, and memory utilization is increased to over 85%.

[0232] With controllable performance loss and optimized bandwidth adaptation, the system achieves hardware performance while saving video memory through resource type and performance priority linkage, dynamic prefetching of GCD's L2 cache, and real-time bandwidth adjustment. The performance loss of OPTIMAL tiling mode is no more than 3% (far lower than LINEAR tiling's 30%), and the frame rate fluctuation in 4K games is no more than 2fps. The MCD bandwidth utilization is stable at 70% to 85%, avoiding bandwidth waste, and the cross-MCD access latency is reduced by 20 to 30ns.

[0233] The hardware features are fully utilized and compatibility is enhanced. The MCD bandwidth stratification of RDNA2 and RDNA3, dynamic splitting of hardware sub-tiling, and L2 cache alignment sensitivity of GCD are deeply explored. The software layer and hardware features are adapted to more than 90% of the features. Through layered anomaly handling and multi-scenario rollback strategies, the anomaly rollback rate is no more than 0.05%, and the performance loss after rollback is no more than 5%. It is compatible with more than 95% of D3D12 game scenarios.

[0234] In summary, the above are merely preferred embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for precise alignment of RDNA architecture GPU memory based on hardware sub-block rearrangement, characterized in that, Specifically, the following steps are included: After system startup, a binary node storing GPU hardware parameters and a first text node storing MCD bandwidth are constructed. After VKD3D starts, hardware parameters are read through the binary node and MCD bandwidth is read through the first text node to set a threshold. The MCD is divided into a high-bandwidth group with bandwidth greater than the larger threshold, a medium-bandwidth group with bandwidth not greater than the larger threshold and not less than the smaller threshold, and a low-bandwidth group with bandwidth less than the smaller threshold. An independent memory pool is allocated for each MCD group, and the memory pool is divided into sub-regions. The corresponding sub-regions of the high-bandwidth group memory pool are allocated to local device memory and written to merged video memory, and the memory pool is bound to the MCD group. When an application creates a D3D12 resource, VKD3D maps the D3D12 resource type to a Vulkan equivalent type, calculates the basic alignment requirements of the resource based on the application's alignment requirements and the minimum alignment granularity of the hardware, and then generates an alignment granularity adapted to the RDNA hardware. Map the usage scenarios of D3D12 resources to the performance priorities of the Vulkan client; The frequency of resource state transitions for each frame of D3D12 resources is statistically analyzed, and the access frequency of resources is determined in combination with the resource usage scenario. MCD groups are matched for resources, sub-regions are determined by access frequency, memory blocks are allocated for resources by matching block size with alignment granularity, Vulkan images are created and memory blocks are bound. When multiple D3D12 resources are allocated to contiguous memory blocks in the same MCD group memory pool, VKD3D configures the source address, target address, number of resources, and alignment granularity to construct hardware rearrangement instructions, dynamically selects the GPU queue to submit and execute sub-block rearrangement, and verifies the sub-block address mapping after rearrangement; the kernel monitors the MCD bandwidth utilization in real time and updates it through the first text node, and VKD3D dynamically adjusts the memory pool expansion, resource migration strategy, and alignment granularity.

2. The method for precise alignment of RDNA architecture GPU memory according to claim 1, characterized in that, The memory pool is divided into multiple sub-regions according to resource type and access frequency. The memory pool of the high bandwidth group is divided into the first rendering target area and the first texture area, the memory pool of the medium bandwidth group is divided into the second texture area and the second calculation buffer, and the memory pool of the low bandwidth group is divided into the third static resource area and the spare area.

3. The method for precise alignment of RDNA architecture GPU memory according to claim 1, characterized in that, Add an access counter to each memory block in the memory pool to count the number of resource accesses within a set number of frames. Memory blocks with access counts greater than a threshold are marked as hot blocks. When new resources are allocated, hot blocks of the same type of sub-region are reused first. When the fragmentation rate of the memory pool is greater than the threshold and the GPU load is less than the threshold, fragment merging is triggered. Small free blocks in the same sub-region are merged into larger blocks. The size of the merged block is adjusted according to the set multiple of the resource type adaptation granularity. The free block list is sorted by a dual key of size and access frequency. Blocks of the same size are arranged in descending order of access frequency.

4. The method for precise alignment of RDNA architecture GPU memory according to claim 1, characterized in that, The specific alignment granularity for generating RDNA-compatible hardware is as follows: the larger of the alignment requirements of the D3D12 application and the minimum alignment granularity of the hardware is used as the basic alignment requirement. The basic alignment requirement is multiplied according to the actual use of the resources. The alignment granularity of the rendering target is the same as the basic alignment requirement. The alignment granularity of 3D textures is twice the basic alignment requirement, and the alignment granularity of cube maps is four times the basic alignment requirement.

5. The method for precise alignment of RDNA architecture GPU memory according to claim 1, characterized in that, The method for allocating memory blocks to resources is as follows: if there is a free block that is not less than the total number of bytes of the resource and has the same alignment granularity, then the memory block is allocated to the resource; otherwise, the smallest block that is not less than the total number of bytes of the resource and whose difference from the total number of bytes of the resource is less than a threshold is found and allocated to the resource; if there is no matching block in the sub-region of the current MCD group, then a block is borrowed from other sub-regions in the same bandwidth group first; if the borrowing fails, then the memory pool is expanded and rematching is triggered.

6. The method for precise alignment of RDNA architecture GPU memory according to claim 1, characterized in that, After creating the Vulkan image and binding the memory block, the memory block is checked. If the offset address of the memory block is not an integer multiple of the overwrite alignment granularity, or the physical address exceeds the MCD partition range, a binding rollback is triggered, the allocated memory block is released, and the matching process is re-executed.

7. The method for precise alignment of RDNA architecture GPU memory according to claim 1, characterized in that, For 2D rendering targets, the hardware reordering instruction uses row-first and block-compact arrangement, with the block size being the block size of the sub-blocks supported by the hardware, and no padding between blocks; for 3D textures, the hardware reordering instruction uses slice and row-first arrangement, with the block size being twice the block size of the supported sub-blocks, and the padding between blocks being half of the overridden alignment granularity; for cube maps, the hardware reordering instruction uses face and row-first arrangement, with the block size being the block size of the supported sub-blocks, and the padding between blocks being the overridden alignment granularity.

8. The method for precise alignment of RDNA architecture GPU memory according to claim 1, characterized in that, The method for verifying the sub-block address mapping after rearrangement is as follows: obtain the mapping table between the virtual address and physical address of each sub-block, traverse the mapping table to check whether the physical address of each sub-block is within the video memory partition range of the corresponding MCD group, and whether the virtual address is an integer multiple of the overwrite alignment granularity. If not, trigger rearrangement retry. If the retry fails, fall back to the default alignment. According to the size of the reclaimed fill space of each memory block, split the reclaimed fill space into small free blocks according to the overwrite alignment granularity and add them to the free block linked list of the corresponding memory pool sub-region.

9. The method for precise alignment of RDNA architecture GPU memory according to claim 1, characterized in that, Set a bandwidth and alignment trade-off factor. The trade-off factor is the ratio of the current MCD packet utilization rate to the MCD bandwidth utilization rate threshold. When the trade-off factor is greater than 1, the alignment granularity is adjusted to overwrite the product of the alignment granularity and the trade-off factor. When the trade-off factor is not greater than 1, the alignment granularity is adjusted to overwrite the alignment granularity.

10. The method for precise alignment of RDNA architecture GPU memory according to claim 1, characterized in that, In the RADV driver, alignment exceptions are divided into recoverable basic exceptions and deep exceptions that need to be rolled back. A multi-register cross-checking mechanism is used to determine the exceptions. Among them, basic exceptions include unsupported alignment granularity and memory block binding failure, while deep exceptions include subblock reordering failure, MCD bandwidth exceeding limit, and GCD L2 cache conflict. If the alignment granularity is not supported, the driver adjusts the overwritten alignment granularity to the previously used valid value, returns a warning, and VKD3D updates the block granularity of the memory pool without rollback; if memory block binding fails, the matching process is re-executed to bind another memory block with the correct offset address. For deep anomalies, the application scenario is identified. For scenarios with a frame rate greater than the threshold, the fallback strategy is to relax the alignment granularity and disable sub-block reordering. For scenarios with image quality greater than the threshold, the fallback strategy is to keep the alignment granularity unchanged and implement sub-block reordering through software. For other scenarios, the fallback strategy is to relax the alignment granularity to twice the overwritten alignment granularity and retain hardware sub-block reordering.

Images