An efficient Direct3D GPU memory management method based on hot-reused cache pool

Abstract

The application discloses a kind of Direct3D GPU memory efficient management methods based on hot reuse cache pool, when GPU does not support VK_EXT_memory_budget extension, DXVK is collected GPU hardware and kernel heap attribute when creating device and write in shared cache pool, generate memory baseline by statistical process memory data, build D3D, vulkan memory type and kernel heap mapping relationship, adjust heap budget;When creating resource, according to resource priority, kernel heap load and memory state allocation GPU memory;In rendering stage, through multistage priority monitoring thread, identify memory exception and cross-process interference and differentially control, distinguish high and low reuse compression resource adaptation release strategy;Statistical access track updates resource priority, update track and parameter when resource reuse, maintain high reuse resource to hot reuse cache pool, update budget model synchronously, according to memory pressure level control rendering and pre-allocation strategy.

Description

Technical Field

[0001] This invention belongs to the field of computer software development technology, specifically relating to an efficient Direct3D GPU memory management method based on a hot-reused cache pool. Background Technology

[0002] The Vulkan-based Direct3D translation layer DXVK's core function is to map D3D 9-11's memory management logic, such as automatic memory allocation, resource priority scheduling, and dynamic budget adaptation, to Vulkan's explicit memory model. In the native D3D environment, the graphics card driver provides real-time memory budget, usage, and multi-process occupancy status. DXVK relies on the VK_EXT_memory_budget extension to obtain this crucial data. This extension directly returns the available heap budget, current heap usage, and dynamic change information for each memory heap through a hardware interface, serving as the core support for DXVK's implementation of D3D memory logic mapping.

[0003] When the GPU does not support this extension, DXVK faces many technical challenges that existing technologies cannot solve, including: First, D3D memory model mapping fragmentation. D3D's automatic budgeting and adaptation logic is difficult to implement, and DXVK can only make static estimates based on the total memory heap capacity, leading to over-allocation crashes (e.g., ignoring other processes' usage) or overly conservative stuttering (e.g., reserving too much memory, causing frequent resource unloading); Second, the failure to detect multi-process memory contention, especially in Linux systems where graphics compositors such as KWin and GNOME... Shell and background video rendering processes such as FFmpeg dynamically occupy video memory, but DXVK cannot distinguish between the game's own increasing video memory demand and external processes competing for it, easily misjudging the source of memory pressure and leading to the incorrect reclamation of critical rendering resources, such as textures in the player's view. Third, video memory performance overhead is out of control. The existing post-allocation reclamation strategy can cause rendering pipeline interruptions, and static priority reclamation, such as fixing the priority of textures as higher than that of buffers, cannot adapt to dynamic game scenes, such as the surge in buffer demand in battle scenes, further aggravating performance fluctuations. Fourth, there is a mismatch in the lifecycle of D3D resources. D3D manages the lifecycle of resources through reference counting and driver-level caching, but without VK_EXT_memory_budget, DXVK cannot accurately determine whether resources are about to be reused, leading to the contradiction of premature reclamation requiring reloading or delayed release of occupied video memory. Summary of the Invention

[0004] In view of this, the present invention provides a method for efficient Direct3D GPU memory management based on a hot-reused cache pool. By constructing a DXVK user-space hot-reused cache pool to host frequently reused GPU memory resource blocks, and cooperating with a dedicated shared cache pool for storing kernel-side storage hardware and heap statistics, the DXVK translation layer achieves efficient management of GPU memory related to D3D applications in cross-process scenarios where the GPU does not support the VK_EXT_memory_budget extension.

[0005] This invention provides an efficient Direct3D GPU memory management method based on a hot-reused cache pool, which specifically includes the following steps:

[0006] When the GPU does not support the VK_EXT_memory_budget extension, during the device creation phase of the D3D application, DXVK initializes a Vulkan instance and establishes an independent hot-reused cache pool in user space. It collects GPU hardware and kernel heap attributes, writes them to a dedicated kernel cache pool, and completes the mapping. It traverses the processes that occupy GPU memory, generates a GPU memory baseline, and constructs a mapping table of D3D memory type, Vulkan memory type, and kernel heap ID. It calculates and adjusts the kernel heap base budget, estimates the heap simulation usage and available budget margin, and triggers a light reclamation when the margin is insufficient.

[0007] When creating D3D resources, DXVK extracts resource attributes to obtain priority scores, queries the mapping table to determine the preferred kernel heap, reads real-time heap data to calculate load scores, and evaluates GPU memory status in conjunction with free blocks and available budget margins; it then searches the hot reuse cache pool, and if a matching memory block is found, it reuses it directly; otherwise, it allocates GPU memory and returns the resource handle.

[0008] During the rendering phase, a tiered monitoring thread is used to collect GPU memory data, identify memory anomalies, and issue warnings. Interference indices are calculated based on the degree of process interference, and differentiated management is implemented for high-interference scenarios based on the source of contention. High- and low-reusability compressed resources are distinguished based on the number of decompressions and intervals, and release strategies are configured accordingly. A circular buffer is used to maintain resource access trajectories, and resource priorities are updated based on the weighted trajectories. When resources are reused, the trajectories are updated, and decompression and parameter reset are performed on highly reused compressed resources. High-reusability memory blocks are retained in the hot reuse cache pool, while cold resources are removed and marked as recyclable, and the budget model is updated synchronously. A stress score is calculated based on multiple weighted indicators to determine the stress level, and the corresponding thread is notified when the level changes, adjusting the rendering process and the pre-allocation pool. User-mode and kernel-mode cleanup is performed when the DXVK process exits.

[0009] Furthermore, the method for traversing the processes occupying GPU memory and generating the GPU memory baseline is as follows: traverse the processes occupying GPU memory, identify their process identities including desktop compositor processes and background video rendering processes, and obtain their allocated capacity, locked capacity, and freeable capacity; calculate the GPU memory baseline, including global used GPU memory, global idle GPU memory, and the ratio of critical process occupancy, wherein global used GPU memory is the difference between the sum of the allocated capacity of all processes and the sum of the freeable capacity of all processes, global idle GPU memory is the difference between the total capacity of all kernel heaps and global used GPU memory, and the ratio of critical process occupancy is the ratio of the sum of the allocated capacity of desktop compositor processes and background video rendering processes to global used GPU memory.

[0010] Furthermore, the method for calculating and adjusting the kernel heap base budget is as follows: For the DEVICE_LOCAL heap, the base budget is equal to the total heap capacity multiplied by a first ratio; if the memory type is LPDDR5, the base budget is equal to the total heap capacity multiplied by a second ratio; for the HOST_VISIBLE heap, the base budget is equal to the total heap capacity multiplied by a third ratio; if the total heap capacity is less than or equal to a threshold, the base budget is equal to the total heap capacity multiplied by a fourth ratio; if the GPU supports memory compression, the base budget obtained above is uniformly increased by the set ratio.

[0011] Furthermore, the method by which DXVK extracts resource attributes to obtain priority scores is as follows: based on the actual situation of the extracted access frequency, lifespan, and visual impact, access frequency score, lifespan score, and visual impact score are determined according to preset rules, and then the access frequency score, lifespan score, and visual impact score are weighted and summed to obtain the priority score.

[0012] Furthermore, the method for calculating the load score by reading real-time heap data is as follows: the ratio of the difference between the used heap capacity and the heap release capacity to the total heap capacity is used as the utilization rate, and the utilization rate score is determined according to the range of the utilization rate; the ratio of the difference between the total heap capacity and the maximum free block size to the total heap capacity is used as the fragmentation rate, and the fragmentation rate score is determined according to the range of the fragmentation rate; the access latency score is determined according to the range of the access latency; finally, the load score is obtained by weighted summation of the utilization rate score, the fragmentation rate score, and the access latency score.

[0013] Furthermore, if the load score of the preferred kernel heap is less than the threshold, the underlying GPU memory is directly allocated in it for the D3D resource to be created; otherwise, a compatible kernel heap with the same heap type as the preferred kernel heap, supporting the type of resource to be created, and with a load score less than the threshold is queried. If it exists, the underlying GPU memory is allocated in the compatible kernel heap for the resource to be created and the cross-heap allocation information is recorded. If it does not exist, the memory is allocated in the preferred kernel heap and the defragmentation forecast of the preferred kernel heap is triggered.

[0014] Furthermore, DXVK extracts scene features including frame type, resource demand trend, timestamp, and resource type proportion. It calculates the Euclidean distance between scene features in the historical scene library and the extracted scene features, selects the scene feature with the smallest distance as the matching result, and determines the current scene type for matching. The historical scene library is a database built based on scene data from multiple applications to store the mapping relationship between scene features and resource demand models.

[0015] DXVK sets the pre-allocation ratio based on the matched scene type, calculates the pre-allocation capacity, and sets allocation constraints; it selects the memory type and kernel heap corresponding to the pre-allocation based on the resource type ratio of the current scene, allocates the pre-allocation capacity in the pre-allocation memory pool, and sets the pre-allocation identifier and expiration time; when a resource allocation request is received in the next frame, it prioritizes obtaining GPU memory blocks from the pre-allocation memory pool and marks the GPU memory block as used; after each frame is executed, it cleans up the expired and unused GPU memory blocks in the pre-allocation pool.

[0016] Furthermore, the hierarchical monitoring threads include a first-level monitoring thread for monitoring high-priority resource usage, kernel heap utilization, GPU memory controller real-time bandwidth usage, and bound resource conflict status; a second-level monitoring thread for monitoring medium-priority resource usage, GPU shared memory heap utilization, cross-process GPU memory usage, and pre-allocation pool utilization; and a third-level monitoring thread for monitoring low-priority resource usage, GPU memory fragmentation rate, kernel metadata integrity, and compressed resource status. The first-level monitoring thread has real-time priority, the second-level monitoring thread has normal priority, and the third-level monitoring thread has low priority. The first-level monitoring thread is bound to the rendering thread of the D3D application, and the second and third-level monitoring threads are scheduled and executed only when the CPU is idle.

[0017] Furthermore, the high-interference scenario implements differentiated control based on the source of contention as follows: if the largest source of contention is a video rendering process, DXVK sends a memory limit request to trigger the kernel to limit the process's use of GPU memory; if the largest source of contention is a 3D application process, DXVK temporarily lowers the priority of non-critical resources and performs light recycling; if the largest source of contention is a system process, DXVK triggers dynamic degradation of texture resolution.

[0018] Furthermore, when recording rendering instructions in a D3D application and binding resources to the rendering pipeline using resource handles, DXVK checks the GPU memory allocation status of the resource during the resource binding operation. If it is not allocated, it triggers an emergency GPU memory allocation. It also checks the GPU lock status; if the resource is being accessed by the GPU, it sets a timeout to wait for the access to end. Finally, it checks the data synchronization status; when the resource is a shared resource between the CPU and GPU, it checks whether the CPU has modified the data. If it has, it synchronizes the modified data from the CPU to the GPU. If it is a compressed resource, it decompresses the resource to GPU memory.

[0019] Iterate through the resources bound in the current command buffer. If there are two different resources being written to and read from the memory address at the same time, if the two resources have different priorities, the lower priority resource will be unbound from the memory address first. If the two resources have the same priority, the binding operation of either resource will be delayed to the next command buffer and the binding information and access type will be recorded.

[0020] When the GPU load exceeds the threshold, resources with a priority lower than the threshold will be delayed until a set time before the Vulkan drawing command is executed to complete the batch binding.

[0021] Beneficial effects:

[0022] This invention completes hardware parameter acquisition, kernel heap data synchronization, memory mapping relationship construction, and budget model initialization during the device creation stage of D3D applications. During the resource creation stage, it intelligently allocates memory based on resource priority, kernel heap load, and memory status, prioritizing the reuse of resident memory blocks in the hot reuse cache pool. During the continuous rendering stage, it identifies memory anomalies and cross-process memory contention through three-level hierarchical monitoring, distinguishes between high and low reuse compressed resources, dynamically updates resource popularity based on resource access trajectories, and relocates high-popularity resources to the hot reuse cache pool while removing and reclaiming low-popularity resources, achieving hierarchical management of hot and cold memory resources. It calculates memory pressure scores using multi-dimensional weighted indicators and hierarchically adjusts the rendering process and pre-allocation strategies. Upon process exit, it cleans up user-mode hot cache resources and synchronizes global memory data in kernel mode, achieving D3D application-related GPU memory management in cross-process scenarios without relying on the VK_EXT_memory_budget extension, significantly improving the GPU memory reuse rate and overall scheduling efficiency of the D3D simulation layer. Attached Figure Description

[0023] Figure 1 This is a flowchart illustrating an efficient Direct3D GPU memory management method based on a hot-reused cache pool, as provided by the present invention. Detailed Implementation

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

[0025] This invention provides a high-efficiency Direct3D GPU memory management method based on a hot-reused cache pool. Its core idea is as follows: During the device creation phase of the D3D application, hardware parameter acquisition, kernel heap data synchronization, memory mapping relationship construction, and budget model initialization are completed. During the resource creation phase, memory is intelligently allocated based on resource priority, kernel heap load, and video memory status, with priority given to reusing resident memory blocks within the hot-reused cache pool. During the continuous rendering phase, three-level hierarchical monitoring identifies video memory anomalies and cross-process memory contention, distinguishing between high- and low-reusability compressed resources. Resource popularity is dynamically updated based on resource access trajectories, keeping high-popularity resources permanently in the hot-reused cache pool and removing and reclaiming low-popularity resources, achieving hierarchical management of video memory resources. A multi-dimensional weighted index is used to calculate video memory pressure scores and hierarchically adjust the rendering process and pre-allocation strategy. Upon process exit, user-mode hot cache resources are cleaned up, and kernel-mode global video memory data is synchronized, significantly improving the GPU memory reuse rate and overall scheduling efficiency of the D3D simulation layer.

[0026] In this invention, GPU memory includes video memory (VRAM) and GPU shared memory. VRAM is the local storage memory of the GPU device, specifically corresponding to the Vulkan DEVICE_LOCAL memory heap. GPU shared memory is host-side memory accessible to the GPU, specifically corresponding to the Vulkan HOST_VISIBLE memory heap. Unless otherwise specified, the following VRAM-related metrics, such as globally used GPU memory, kernel heap attributes, and heap utilization, refer to kernel heap statistics. The kernel-dedicated cache pool is a data interaction cache between the kernel and DXVK, storing only hardware parameters, heap attributes, and baseline statistics. The hot-reuse cache pool is an independent user-space memory management pool for DXVK, specifically managing GPU physical memory blocks with high resource reuse, enabling hot resource residency, rapid reuse, and cold resource eviction.

[0027] This invention provides an efficient Direct3D GPU memory management method based on a hot-reused cache pool, the processing flow of which is as follows: Figure 1 As shown, the specific steps include:

[0028] Step 1: When the D3D application creates a D3D rendering device, DXVK initializes the Vulkan instance, obtains GPU hardware-related parameters including memory type identifier, total memory capacity, memory page size, memory bandwidth, number of memory chips, bank grouping of each chip, maximum simultaneous allocation supported by the hardware, and GPU memory error recovery capability. It also obtains all current kernel heap attributes, including heap type, physical address range, whether it is compressible, and maximum contiguous free block size. The hardware-related parameters and kernel heap attributes are written to a dedicated cache pool in the shared memory created by the kernel. The dedicated cache pool is mapped to user space and set to read-only for the DXVK process and write-only for the kernel. At the same time, DXVK initializes an independent hot-reuse cache pool in user space to store frequently reused GPU memory blocks, supporting hot resource resident, cold resource eviction, and fast inter-frame reuse.

[0029] The process iterates through the processes occupying GPU memory, identifying their identities, including desktop compositor processes and background video rendering processes, and obtaining their allocated capacity, locked capacity, and freeable capacity. It calculates the GPU memory baseline, including global used GPU memory, global free GPU memory, and the ratio of critical process usage. Global used GPU memory is the difference between the sum of the allocated capacity of all processes and the sum of the freeable capacity of all processes. Global free GPU memory is the difference between the total capacity of all kernel heaps and global used GPU memory. The critical process usage ratio is the ratio of the sum of the allocated capacity of desktop compositor processes and background video rendering processes to global used GPU memory. A high-precision timestamp is set for the GPU memory baseline, and the GPU memory baseline is written to the baseline data area of ​​a dedicated cache pool.

[0030] DXVK loads the D3D memory types supported by the system, mapping the access attributes of various memory types to the expected Vulkan flags. It iterates through each Vulkan memory type; when the Vulkan flags of a Vulkan memory type satisfy the expected Vulkan flags, a matching pair is formed between the D3D memory type and the Vulkan memory type, and the performance weight of the matching pair is calculated. The corresponding Vulkan memory heap is located based on the heap index of the Vulkan memory type, and the heap type label is obtained based on the attribute flags of the Vulkan memory heap. Kernel heap attributes in the dedicated cache pool are read, and kernel heaps with matching heap type labels are found to obtain all kernel heap IDs under that heap type. If multiple kernel heap IDs exist, the kernel heap ID with the highest performance weight is selected as the kernel heap identifier bound to that Vulkan memory type, and a mapping table is established containing D3D memory type, Vulkan memory type, kernel heap ID, performance weight, maximum allocation granularity, supported resource types, synchronization method, and whether compression is supported.

[0031] The base budget for each kernel heap is calculated based on the heap type and memory type, and then the base budget is adjusted according to the usage ratio of critical processes. The Vulkan resources created by the DXVK process are traversed to obtain the GPU memory size and corresponding Vulkan memory type required by each resource. The kernel heap corresponding to the Vulkan memory type is determined according to the mapping table. The simulated used capacity of the DXVK process in that kernel heap is summed with the GPU memory size required by the Vulkan resources to be allocated. The simulated usage of the kernel heap after the update is estimated. The difference between the base budget and the simulated usage is the available budget margin. When the available budget margin is less than the threshold, a light reclamation is triggered. The base budget, simulated usage, available budget margin, and update timestamp are stored in the simulated D3D GPU memory budget model.

[0032] Furthermore, the method for determining whether the Vulkan flags of a Vulkan memory type can satisfy the expected Vulkan flags is as follows: A bitwise AND operation is performed between the Vulkan flags of the Vulkan memory type and the expected Vulkan flags. Satisfaction is indicated only if the result matches the expected Vulkan flags. If no matching memory type is found after iterating through all Vulkan memory types, a downgraded matching strategy is executed. This downgraded matching strategy involves: relinquishing the device's local hardware access capabilities, selecting a Vulkan memory type with host-visible attributes, and performing manual memory synchronization to construct a matching pair consisting of the D3D memory type and the downgraded Vulkan memory type.

[0033] The performance weight of the matching pair is calculated as the weighted sum of the ratio of memory bandwidth to maximum bandwidth and the ratio of access latency to minimum latency.

[0034] The specific method for calculating the base budget for each kernel heap based on heap type and video memory type is as follows: For the DEVICE_LOCAL heap, which is the game core resource heap, the base budget is equal to the total heap capacity multiplied by a first ratio. If the video memory type is LPDDR5, the base budget is equal to the total heap capacity multiplied by a second ratio. For the HOST_VISIBLE heap, which is the GPU shared memory heap for CPU and GPU interaction, the base budget is equal to the total heap capacity multiplied by a third ratio. If the total heap capacity is less than or equal to a threshold, the base budget is equal to the total heap capacity multiplied by a fourth ratio. If the GPU supports video memory compression, i.e., it has the flag FLAG_COMPRESS_SUPPORT, the base budget obtained above is uniformly increased by the set percentage.

[0035] The adjustment of the base budget based on the critical process occupancy ratio is as follows: when the critical process occupancy ratio is greater than the first threshold, the base budget is adjusted to the product of the original value and the first ratio; when the critical process occupancy ratio is less than the second threshold, the base budget is adjusted to the product of the original value and the fourth ratio; when the critical process occupancy ratio is neither greater than the first threshold nor less than the second threshold, the base budget remains unchanged. The first ratio, second ratio, and third ratio decrease sequentially. The fourth ratio is greater than the first ratio.

[0036] Specifically, light memory reclamation can involve reclamating only low-priority resources with a reference count of zero that have not been accessed within the last set number of frames, until the available budget margin is not less than a threshold. The simulated D3D GPU memory budget model employs read-write lock protection.

[0037] This process is a GPU memory budget management initialization process executed synchronously during the D3D rendering device creation phase. The creation of the D3D rendering device itself still relies on the DXVK native Vulkan device creation process. This process is used to complete hardware GPU memory acquisition, mapping table construction and GPU memory budget model initialization during device creation, and to complete the dual-pool initialization of the hot reuse cache pool and the dedicated cache pool, providing data and memory pool support for subsequent resource hot reuse, allocation control and resource reclamation.

[0038] Step 2: When a D3D application creates D3D resources, DXVK extracts the core attributes of the resources, including resource type, access frequency, lifecycle, and visual impact, to determine the resource's priority score. Using the D3D memory type of the D3D resource to be created as the key, it queries the mapping table to obtain the kernel heap ID associated with that D3D memory type, and uses this kernel heap ID as the preferred kernel heap for the resource to be created. It reads real-time data from the dedicated cache pool for each associated heap corresponding to this kernel heap ID, including heap used capacity, heap freeable capacity, total heap capacity, maximum free block size, and heap access latency, and calculates the heap load score accordingly. It reads the maximum free block size from the dedicated cache pool and, combined with the available budget margin obtained from the simulated D3D GPU memory budget model, assesses the current GPU memory state as relaxed, strained, or normal. Finally, it determines the GPU memory resource allocation strategy based on the priority score and GPU memory state.

[0039] Prioritize searching for free hot memory blocks in the hot reuse cache pool that match the memory type and heap attributes and have the required capacity. If a match is found, the memory block in the cache pool is reused directly without having to call the driver memory allocation interface again. If no match is found, the underlying GPU memory is allocated in the preferred kernel heap for the D3D resource to be created, and the newly created resource memory block with reuse potential is included in the hot reuse cache pool for management, and the resource handle is returned.

[0040] The specific method for determining the priority score of resources is as follows: based on the actual situation of the extracted access frequency, lifespan, and visual impact, access frequency score, lifespan score, and visual impact score are determined according to preset rules. Then, the access frequency score, lifespan score, and visual impact score are weighted and summed to obtain the priority score. For example, when the access frequency is 10 points per frame, the access frequency score is 7 points when accessing every 3 frames, the access score is 3 points when accessing every 10 frames, and the access score is 1 point when accessing only during initialization.

[0041] Specifically, the maximum free block size of the dedicated cache pool is read, and combined with the available budget margin obtained from the simulated D3D GPU memory budget model, the current GPU memory status is assessed as either relaxed, strained, or normal. The specific method is as follows: if the available budget margin is greater than a first proportion of the total heap capacity, and the maximum free block size is not less than a set multiple of the size of the D3D resource to be created, then it is a relaxed state; if the available budget margin is not greater than a second proportion of the total heap capacity, or the maximum free block size is less than the size of the D3D resource to be created, then it is a strained state; the non-relaxed and strained states are considered normal states.

[0042] The load score is calculated as follows: the ratio of the difference between the used heap capacity and the free heap capacity to the total heap capacity is used as the utilization rate, and a utilization score is determined based on the range of the utilization rate. The ratio of the difference between the total heap capacity and the maximum free block size to the total heap capacity is used as the fragmentation rate, and a fragmentation score is determined based on the range of the fragmentation rate. An access latency score is determined based on the range of the access latency. Finally, the load score is obtained by weighted summing of the utilization rate score, fragmentation rate score, and access latency score. For example, if the calculated utilization rate is no greater than 30%, the utilization rate score is 1 point.

[0043] The GPU memory resource allocation strategy is determined based on priority scores and GPU memory status. This strategy is tailored to specific usage needs. For example, when the priority score is high, the allocation strategy prioritizes large page allocation and locks GPU memory; when the priority score is medium and the GPU memory status is ample, the allocation strategy allocates ordinary pages and sets them to be reclaimable with delay.

[0044] Furthermore, if the load score of the preferred kernel heap is less than the threshold, then underlying GPU memory is directly allocated in it for the D3D resource to be created; otherwise, a compatible kernel heap with the same heap type as the preferred kernel heap, supporting the type of resource to be created, and with a load score less than the threshold is queried. If such a compatible kernel heap exists, underlying GPU memory is allocated in that compatible kernel heap for the resource to be created, and the cross-heap allocation resource information is recorded. If such a cross-heap allocation does not exist, it is allocated in the preferred kernel heap, and a defragmentation warning for the preferred kernel heap is triggered. The cross-heap allocation resource information includes the resource ID, the original preferred heap ID, the actual allocated heap ID, and the cross-heap performance penalty.

[0045] Furthermore, to avoid CPU overhead and driver latency caused by frequent GPU memory allocation per frame, this invention establishes a predictive allocation mechanism that pre-allocates GPU memory to meet the resource requirements of the next frame, specifically as follows:

[0046] DXVK extracts scene features including frame type, resource demand trend, timestamp, and resource type proportion. It calculates the Euclidean distance between scene features in the historical scene library and the extracted scene features, selects the scene feature with the smallest distance as the matching result, and determines the current scene type for matching. The historical scene library is a database built based on scene data from multiple applications to store the mapping relationship between scene features and resource demand models.

[0047] DXVK sets the pre-allocation ratio based on the matched scene type, calculates the pre-allocation capacity, and sets allocation constraints; it selects the memory type and kernel heap corresponding to the pre-allocation based on the resource type ratio of the current scene, allocates the pre-allocation capacity in the pre-allocation memory pool, and sets the pre-allocation identifier and expiration time; when a resource allocation request is received in the next frame, it prioritizes obtaining GPU memory blocks from the pre-allocation memory pool and marks the GPU memory block as used; after each frame is executed, it cleans up the expired and unused GPU memory blocks in the pre-allocation pool.

[0048] Step 3: During the continuous rendering process of the D3D application, a hierarchical monitoring thread is created. This includes a first-level monitoring thread for monitoring high-priority resource usage, kernel heap utilization, real-time bandwidth usage of the GPU memory controller, and resource conflict status; a second-level monitoring thread for monitoring medium-priority resource usage, GPU shared memory heap utilization, total cross-process GPU memory usage, and pre-allocated pool utilization; and a third-level monitoring thread for monitoring low-priority resource usage, GPU memory fragmentation rate, kernel metadata integrity, and compressed resource status. The first-level monitoring thread has real-time priority, the second-level monitoring thread has normal priority, and the third-level monitoring thread has low priority. The first-level monitoring thread is bound to the rendering thread of the D3D application, and the second and third-level monitoring threads are scheduled and executed only when the CPU is idle. The monitoring data is used to detect whether there are any abnormalities in GPU memory. Based on the type and number of abnormalities and the current available budget, the abnormality level is determined as mild, moderate, or severe, and corresponding warning events are triggered according to the abnormality level.

[0049] The processes currently consuming GPU memory are categorized into critical system processes, high-interference processes, and low-interference processes based on their impact on D3D applications. An interference weight is assigned to each category, and an interference index is calculated. When the interference index exceeds a threshold, it is determined that there is high interference contention for GPU memory. If the largest source of contention is a video rendering process, DXVK sends a memory limit request to trigger the kernel to limit the process's GPU memory usage. If the largest source of contention is a 3D application process, DXVK temporarily lowers the priority of non-critical resources and performs light resource reclamation. If the largest source of contention is a system process, DXVK triggers dynamic texture resolution degradation.

[0050] The decompression interval and the number of decompressions within a set time period are statistically analyzed for compressed resources. Resources with a decompression count greater than the first threshold or a decompression interval less than the first interval threshold are marked as high-reusability compressed resources, while resources with a decompression count less than the second threshold or a decompression interval greater than the second interval threshold are marked as low-reusability compressed resources. The memory blocks corresponding to high-reusability compressed resources are permanently retained in the hot-reuse cache pool, and the release cycle is extended. Low-reusability compressed resources are removed from the hot-reuse cache pool, compressed, and marked as reclaimable memory, thus realizing the hot-cold tiered scheduling of video memory.

[0051] The interference index is calculated as the ratio of the weighted sum of GPU memory usage of each process to the total GPU memory usage.

[0052] Furthermore, when recording rendering instructions in a D3D application and binding resources to the rendering pipeline using resource handles, DXVK checks the GPU memory allocation status of the resource during the resource binding operation. If it is not allocated, it triggers an emergency GPU memory allocation. It also checks the GPU lock status; if the resource is being accessed by the GPU, it sets a timeout to wait for the access to end. Finally, it checks the data synchronization status; when the resource is a shared resource between the CPU and GPU, it checks whether the CPU has modified the data. If it has, it synchronizes the modified data from the CPU to the GPU. If it is a compressed resource, it decompresses the resource to GPU memory.

[0053] Iterate through the resources bound in the current command buffer. If there are two different resources being written to and read from the memory address at the same time, if the two resources have different priorities, the lower priority resource will be unbound from the memory address first. If the two resources have the same priority, the binding operation of either resource will be delayed to the next command buffer and the binding information and access type will be recorded.

[0054] When the GPU load exceeds the threshold, resources with a priority lower than the threshold will be delayed until a set time before the Vulkan drawing command is executed to complete the batch binding.

[0055] Step 4: DXVK creates an access trajectory table for D3D resources. The recorded entries include the access frame identifier, access type, pipeline stage in which the access occurred, intra-frame time of the access, global reference count of the resource, and whether the resource has been synchronized to the GPU. The access trajectory table is stored in a circular buffer. The access type includes read, write, and no access.

[0056] The number of records in the access trajectory table with access type "read" or "write" in the most recent set frame number is taken as the number of times the resource is accessed. The ratio of the number of times the resource is accessed to the set frame number is normalized and recorded as the access frequency. The difference between the frame identifier currently being processed by DXVK and the most recent access frame identifier with access type "read" or "write" in the access trajectory table is normalized and recorded as the most recent access frame difference. The standard deviation of the global reference count of multiple sets of resources sampled within the most recent set frame number is calculated, normalized, and recorded as the reference count stability. The smaller the standard deviation, the more stable the reference count. The access pipeline stage weight is set according to the pipeline stage in which the access occurs, such as the fragment coloring stage having a weight of 1. The priority score is obtained by weighted summing of access frequency, most recent access frame difference, reference count stability, and access pipeline stage weight. The resource's popularity and priority are updated according to the priority score.

[0057] When a resource is reused, the reuse trigger type is recorded, including reference count recovery, re-access, and LOD adjustment. Records in the access track table with the access type set to "no access" for the most recent frame are deleted. The intra-frame time of the resource access is updated to the current frame time, and the access type is updated to the currently reused access type. When the resource is a highly reused compressed resource and is currently unloaded, the resource is decompressed to GPU memory and marked as loaded into GPU memory, and the decompression count is reset to 1. When a resource is marked as waiting to be rebound, the mark is cleared and it is bound to the current rendering pipeline, and the binding conflict count is reset to 0. The current simulation usage is updated to the value accumulated with the GPU memory usage of the resource. When the resource is allocated across heaps, the used capacity of the corresponding heap is updated.

[0058] High-priority, frequently accessed, and reusable hot resources remain continuously in the cache pool and are not released during regular light reclamation; cold resources that have not been accessed for a long time, have low priority, and are rarely reused are automatically removed from the cache pool and included in the reclaimable queue, realizing dynamic updates and adaptive hot and cold resource elimination of the hot cache pool.

[0059] Step 5: Read the simulated D3D GPU memory budget model. The ratio of simulated usage to the base budget is the budget utilization rate. The ratio of the difference between the globally occupied GPU memory capacity and the globally freeable GPU memory capacity to the total kernel heap capacity is the global GPU memory utilization rate. The sum of the total low-priority resource usage and the medium-priority reclaimable resource usage in each frame is the resource reclamation margin. Obtain the number of GPU memory errors within a set time. The stress score is obtained by weighted summation of budget utilization rate, global GPU memory utilization rate, anomaly level, resource reclamation margin, number of GPU memory errors, cross-process interference index, and memory bandwidth utilization. The stress level is determined based on the stress score, including mild stress, moderate stress, and severe stress. When the stress level changes from mild to moderate, a non-blocking notification is sent to the memory management thread. When it changes from moderate to severe, a blocking notification is sent to the rendering thread to force a pause in rendering until reclamation is completed. When it changes from severe to moderate, the pre-allocation pool expansion limit is removed and the normal pre-allocation ratio is restored.

[0060] Specifically, when the stress level is mild, only low-priority resources with no access type in the most recent set number of frames that can be immediately reclaimed are reclaimed during frame intervals, and the reclamation amount is no greater than the resource reclamation reserve. All high-hot resources in the hot reuse cache pool are retained. When the stress level is moderate, low-priority and medium-priority resources with no access type in the most recent set number of frames that can be reclaimed are prioritized during frame intervals, and the reclamation amount is equal to the resource reclamation reserve. When the reclamation amount is less than the second reclamation reserve, reclamation is supplemented during the non-critical rendering stage of the current frame, and core hot cache resources are still retained. When the stress level is high, the rendering thread is blocked to reclaim all low-priority resources, all reclaimable medium-priority resources, and non-core high-priority resources that have not been accessed in the most recent set number of frames. The reclamation amount is the sum of the resource reclamation reserve and the third reclamation ratio of the high-priority release amount. Only extremely low-hot resources in the hot cache pool are eliminated.

[0061] Step 6: When the D3D application triggers the DXVK process to exit, forcibly set the reference count to 0 for each resource, change the markers for pending reclamation and reusable to forced release, clear all resident hot resource memory blocks in the hot reuse cache pool, and release the backup data in system memory for compressed resources; release resources in batches according to resource type priority, clear user-mode data structures, and complete DXVK user-mode cleanup; trigger kernel-mode cleanup, mark all GPU memory management objects associated with the DXVK process as released and update the releaseable capacity, recalculate the global used capacity and global free capacity of GPU memory, update the dedicated cache pool, update the kernel dedicated cache pool data, stop listening to GPU memory contention events for the DXVK process, release the dedicated resources allocated by the kernel for DXVK, and achieve complete synchronous cleanup of user-mode hot cache and kernel-mode data pool.

[0062] Example:

[0063] This embodiment employs a Direct3D GPU memory efficiency management method based on a hot-reused cache pool provided by the present invention. Specifically, for the Vulkan-based Direct3D translation layer DXVK, when the GPU does not support the VK_EXT_memory_budget extension, it simulates the native D3D memory management logic through fine-grained memory management in both kernel and user modes, achieving efficient and stable DXVK operation. This method is suitable for older GPUs, niche graphics cards, and other hardware environments without this extension support, and is particularly well-suited for game rendering scenarios under Linux systems. The specific implementation process includes:

[0064] After S1 and DXVK start, they collect GPU hardware characteristics and system GPU memory baseline data through the kernel panoramic system, and build a memory mapping model between D3D, Vulkan and hardware in DXVK.

[0065] S1.1 In kernel mode, when the DXVK process initializes a Vulkan instance through vkCreateInstance, the kernel panoramic system is triggered to start and performs the following operations after startup:

[0066] S1.1.1, GPU hardware feature scan.

[0067] A new field, gpu_mem_attr, has been added to the drm_device structure in the kernel DRM (Direct Rendering Manager) subsystem to store hardware-level video memory parameters. The specific method for obtaining these parameters is as follows:

[0068] The memory type identifier, such as MEM_TYPE_GDDR6, is obtained by matching the Device ID in the PCIe configuration space with the driver's preset type table; the total memory capacity is obtained by reading the memory capacity-related registers of the GPU memory controller; the memory page size is obtained through the custom kernel interface drm_gem_get_pagesize, distinguishing between ordinary pages and big pages, and supporting hardware dynamic page size switching; the memory bandwidth is calculated using the formula: memory controller clock frequency * bit width / 8; the number of memory chips and the bank grouping of each chip are obtained by reading the GPU's VBIOS data, used for bank conflict avoidance during multi-heap load balancing; the maximum number of simultaneous allocations supported by the hardware is obtained by reading the max_gem_objects extended field newly added to the drm_device structure in the kernel DRM subsystem; the memory error recovery capability, i.e., whether ECC is supported, is obtained by reading the ECC enable bit in the GPU configuration register, and if supported, it is marked FLAG_ECC_SUPPORT.

[0069] By using the GPU-driven DRM / GEM module, the modified drm_gem_object memory objects are traversed and combined with the kernel memory heap management structure to scan the attributes of all kernel heaps in the current system. The attribute definitions and acquisition methods include: heap type, including DEVICE_LOCAL, HOST_VISIBLE, and HOST_COHERENT, matching the type information recorded in the kernel extended field drm_gem_object->memory_type with the Vulkan memory type flag, corresponding to D3D's D3D11_HEAP_TYPE_DEFAULT type, etc.; the physical address range of the heap, by reading the kernel memory heap management structure to obtain the overall physical address start value and total capacity of the heap; whether compression is supported, by reading the GPU texture compression capability register, and adding a custom flag FLAG_COMPRESS_SUPPORT if supported; and the maximum size of the heap's maximum contiguous free block, by traversing the heap free block linked list drm_mem_heap->free_list added to the kernel in this embodiment and recording the size field of the maximum free block.

[0070] The aforementioned hardware characteristic data is written to the kernel-mode shared memory region. This region is used to create a dedicated cache pool through kmem_cache_create, which is mapped to user space using mmap. The permissions are set to read-only for DXVK processes and write-only for the kernel. Access permissions are controlled through inode_permission to prevent data tampering.

[0071] S1.1.2 System GPU memory baseline acquisition.

[0072] The kernel panoramic system traverses the task_struct structure of all processes and the drm_gem_object video memory object; it filters the processes using GPU memory by using the owner field of drm_gem_object, and only keeps the processes with non-null owner and drm_gem_object->size>0.

[0073] For each GPU process, its capacity in each kernel heap is counted in three categories. The counting method includes: allocated capacity, which is calculated by traversing all drm_gem_objects associated with the process, grouping them by heap type and accumulating drm_gem_object->size, excluding objects marked as pending release in this embodiment, such as drm_gem_object whose extended field status is GEM_STATUS_PENDING_FREE; locked capacity, which is calculated by counting the total size of objects whose extended flags contain the GEM_FLAG_LOCKED mark. These objects are being accessed by the GPU and cannot be reclaimed if they are in the rendering pipeline; and reclaimable capacity, which is calculated by counting the total size of objects whose status is GEM_STATUS_PENDING_FREE and whose extended field lock_count is equal to 0, i.e., objects that are not locked by the GPU. These objects can be reclaimed immediately.

[0074] The system-level GPU memory baseline data is calculated using the following formula:

[0075] Globally used GPU memory = Σ(allocated capacity for each process) - Σ(releaseable capacity for each process);

[0076] Global free GPU memory = Σ(total capacity of all heaps) - Global used GPU memory;

[0077] The critical process usage ratio = (allocated capacity of desktop compositor process + allocated capacity of background video process) / global used GPU memory. Among them, the desktop compositor is matched by process name, and the background video process can be determined by whether the command line parameters include -vcodec, -stream_loop, etc.

[0078] Baseline data is written to the baseline data area in shared memory. This data structure contains a timestamp field. The time value is obtained in nanoseconds by the kernel function kmet_get_ns() and then converted into a microsecond timestamp. This facilitates DXVK verification of data timeliness, ensures the reading of real-time baseline data, and avoids the use of expired baselines.

[0079] S1.2, D3D-Vulkan memory model mapping table construction: During initialization, the DXVK forging engine maps kernel shared memory through mmap, reads hardware characteristics and baseline data, and constructs a mapping table between D3D memory parameters, Vulkan memory type, and kernel monitoring heap.

[0080] S1.2.1, D3D memory type analysis.

[0081] The `dxvk.d3dVersion` parameter in the DXVK configuration file (e.g., `dxvk.conf`) is read, and the corresponding version of the D3D memory model definition is loaded. The parsing rules are as follows:

[0082] D3D9: Parses the combination rules of D3DPOOL and D3DUSAGE. For example, D3DPOOL_DEFAULT|D3DUSAGE_RENDERTARGET represents the device local rendering target resource, which needs to support fast writing; D3DPOOL_MANAGED represents CPU-GPU shared resources. This invention introduces a dirty rectangle marking mechanism for memory synchronization, only updating the area modified by the CPU to avoid full synchronization.

[0083] D3D11: Resolves the mapping relationship between D3D11_HEAP_TYPE and D3D11_USAGE. For example, D3D11_HEAP_TYPE_UPLOAD|D3D11_USAGE_DYNAMIC indicates that the CPU can dynamically update and upload the buffer to the GPU. It needs to support HOST_VISIBLE and HOST_COHERENT.

[0084] For each D3D memory type, extract the core attributes and map them to Vulkan flags to establish an intermediate mapping table.

[0085] Table 1. Intermediate Mapping Table from D3D Memory Types to Vulkan Flags

[0086] In Table 1, among the Vulkan flags, VK_MEMORY_PROPERTY_DEVICE_COHERENT_BIT_AMD is an AMD vendor extension, while the rest are standard Vulkan 1.0 memory attribute flags.

[0087] S1.2.2, Vulkan memory type matching.

[0088] Call vkGetPhysicalDeviceMemoryProperties to get a list of Vulkan memory types, and extract the propertyFlags and heapIndex for each type. The heapIndex is used to associate with the Vulkan memory heap.

[0089] Establish matching rules between D3D memory types and Vulkan memory types. The matching priority is sorted according to the satisfaction of core attributes and performance weight. For example, in D3D11, HEAP_TYPE_DEFAULT indicates that it is device local and not accessible to the CPU. It will prioritize matching the Vulkan type DEVICE_LOCAL_BIT and not HOST_VISIBLE_BIT. If multiple corresponding types exist, the heap with the highest video memory bandwidth corresponding to heapIndex will be selected. As another example, in D3D9, D3DPOOL_MANAGED indicates that it is shared by the CPU and GPU. It will match the Vulkan type DEVICE_LOCAL_BIT | HOST_VISIBLE_BIT | HOST_COHERENT_BIT. If it does not exist, it will be downgraded to the HOST_VISIBLE type and manually synchronized. This can be achieved through vkFlushMappedMemoryRanges.

[0090] Calculate the performance weight for each matching pair. Performance weight = (memory bandwidth / maximum bandwidth) * 0.7 + (access latency / minimum latency) * 0.3. For example, GDDR6 with DEVICE_LOCAL type has a bandwidth of 480GB / s and a latency of 10ns, so its performance weight is 1.0; LPDDR5 has a bandwidth of 336GB / s and a latency of 15ns, so its performance weight = (336 / 480) * 0.7 + (10 / 15) * 0.3 ≈ 0.7 * 0.7 + 0.67 * 0.3 ≈ 0.49 + 0.2 = 0.69. We take 0.7 for priority selection during subsequent allocation.

[0091] S1.2.3, Associated with the kernel monitoring heap.

[0092] This mapping table is stored in the `m_memMapTable` member, which is newly added in this embodiment of the DXVK global memory manager `DxvkMemoryManager`, using `std::unordered_map` for storage. Subsequent resource allocation is directly queried using the D3D memory type key-value pair. The kernel heap attributes in the kernel shared memory are read, and the `heap_id`, heap type marker `HEAP_TYPE_DEVICE`, and `HEAP_TYPE_HOST` of each kernel heap are extracted. The Vulkan memory type is associated with the kernel heap through the heap type marker: the Vulkan `DEVICE_LOCAL` memory type is mapped to the associated kernel `HEAP_TYPE_DEVICE` heap, and the `HOST_VISIBLE` type is mapped to the associated `HEAP_TYPE_HOST` heap. If multiple heaps exist, they are associated in descending order of performance weight. The final mapping table `D3DMemMapTable` is then constructed.

[0093] Table 2. Examples of mappings for D3D memory types, Vulkan memory types, and kernel heaps.

[0094] S1.3 Initialization of the graphics memory budget simulation model. The DXVK replication engine initializes the simulated D3D GPU memory budget model DxvkMemBudgetModel established in this invention based on kernel baseline data and mapping tables, replacing heapBudget and heapUsage of VK_EXT_memory_budget.

[0095] S1.3.1 Basic budget calculation.

[0096] For each kernel heap, the base budget is calculated based on the heap type and memory type, using the following formula and adjustment rules:

[0097] DEVICE_LOCAL heap: Base budget = total heap capacity * 90%. If the memory type is LPDDR5, it indicates that the bandwidth is low. In this embodiment, the base budget will be reduced by an additional 5% to avoid performance loss caused by bandwidth bottleneck.

[0098] HOST_VISIBLE heap: Base budget = total heap capacity * 80%. If the total heap capacity is not greater than 1GB, it indicates a low-end device. Reduce the budget by 10% to reserve more space for system interaction.

[0099] General adjustments: If the GPU supports memory compression, the base budget can be increased by 5%; after compression, the actual memory usage is reduced, effectively increasing the available space.

[0100] Based on the critical process occupancy ratio in the system baseline data, the basic budget is flexibly adjusted using the following formula:

[0101] If the critical process usage ratio is greater than 30%: base budget = base budget * 0.9, with an additional 10% reserved to cope with sudden background process usage; if the critical process usage ratio is less than 10%: base budget = base budget * 1.05, releasing more available video memory; if the critical process usage ratio is 10%-30%: base budget remains unchanged.

[0102] S1.3.2, Simulate usage initialization.

[0103] Iterate through the Vulkan resources created by the DXVK process, such as DxvkImage and DxvkBuffer, and obtain the memory usage size and memory type mask memoryTypeBits through the resource's getMemoryRequirements() method;

[0104] Based on D3DMemMapTable, the corresponding kernel heap is matched by memoryTypeBits, and the size of each resource is assigned to the corresponding heap. The used capacity of DXVK in each heap is accumulated, which is the simulated heapUsage. If there are shared resources, such as multiple D3D objects referencing the same Vulkan resource, the size is only counted once to avoid duplicate counting.

[0105] Available budget margin = base budget - used capacity. If the margin is less than 0, it means that the budget was exceeded during initialization, and a light reclamation is triggered, that is, only low-priority resources with a reference count of 0 and no access in the last 5 frames, such as temporary rendering buffers, are reclaimed until the margin is not less than 0.

[0106] S1.3.3, Budget model parameters are fixed.

[0107] The base budget, simulated usage, available budget balance, and update timestamp are stored in the DxvkMemBudgetModel structure, which is protected by read-write locks: read operations such as rendering thread queries use the shared_lock to support concurrent reads by multiple threads, while write operations such as memory management thread updates use the unique_lock to ensure data consistency and avoid conflicts in multi-threaded access.

[0108] S2 and DXVK simulate D3D's on-demand allocation and performance-priority logic. Through a three-level process of dynamic allocation strategy selection, multi-heap load balancing, and pre-allocation optimization, they achieve high precision and low latency in video memory allocation.

[0109] S2.1 Dynamic selection of allocation strategy.

[0110] When DXVK receives a resource creation request from a D3D application, such as IDirect3DTexture9::Create or ID3D11Buffer::Create, it first parses the resource attributes, reads the current video memory status, and executes the logic of this invention to select the optimal allocation strategy.

[0111] S2.1.1 Resource attribute parsing.

[0112] Extract the core attributes of the resource. The attribute definitions and retrieval methods are as follows:

[0113] Resource types include: textures, determined by the resolution (Width / Height), format (e.g., DXGI_FORMAT_R8G8B8A8_UNORM), and mipmap levels (MipLevels) of D3D11_TEXTURE2D_DESC; buffers, determined by the size (ByteWidth) of D3D11_BUFFER_DESC and whether the usage is dynamically updated (e.g., D3D11_USAGE_DYNAMIC); rendering targets, determined by the format and sampleDesc of D3D11_RENDER_TARGET_VIEW_DESC, where sampleDesc indicates whether MSAA is supported (e.g., DXGI_SAMPLE_DESC{4,0}); and access frequency, determined by D3D's D3DUSAGE or D3D11_USAGE. The correspondence between D3D usage flags and access frequencies is shown in the table below.

[0114] Table 3. Correspondence between D3D usage tags and access frequency

[0115] Lifecycle: Determined by the initial reference count after the D3D application calls AddRef(). If the initial reference count is 5, it indicates long-term reuse, such as player character textures. If it is 1, it indicates temporary resources, such as particle buffers for single-drawn applications.

[0116] Visual impact: This is determined by the camera frustum culling results in the game scene. Specifically, the DxvkRenderState::isInViewFrustum() method is called. Returning true indicates that the resource is within the player's camera view and has a high visual impact; returning false indicates that it is outside the view and has a low visual impact. The visual impact of the background calculation buffer is the lowest by default.

[0117] Resources are prioritized and scored using the following formulas and weights: Access frequency score (weight 0.4): 10 points per frame, 7 points per 3 frames, 3 points per 10 frames, and 1 point for initialization only; Lifetime score (weight 0.3): 5 points for more than 60 frames, 3 points for 10 to 60 frames, and 1 point for less than 10 frames; Visual impact score (weight 0.3): 5 points for in-view textures, 2 points for out-of-view textures, and 1 point for background calculation buffers; Total score of 12 or higher indicates high priority (e.g., dynamic character textures within the viewpoint), 8 to 11 indicates medium priority (e.g., static scene textures outside the viewpoint), and less than 8 indicates low priority (e.g., temporary particle buffers).

[0118] S2.1.2, Evaluation of video memory status.

[0119] The available budget margin in DxvkMemBudgetModel and the kernel heap free block information in kernel shared memory are read. The evaluation metrics and judgment rules are as follows: Available budget margin, directly read the m_availableBudget field, in bytes; Maximum free block size, read the heap_free_info[heap_id].max_block_size field in kernel shared memory, which is updated by the kernel every 1ms.

[0120] The current memory status is assessed based on the above indicators, including: Spare state, where the available budget margin is greater than 20% of the total heap capacity and the maximum free block size is not less than 1.2 times the resource size, in which case 20% space is reserved to deal with fragmentation; Tight state, where the available budget margin is not greater than 10% of the total heap capacity, or the maximum free block size is less than the resource size, requiring defragmentation or compaction allocation; Normal state, which is a situation between the two.

[0121] S2.1.3, Allocation Strategy Matching.

[0122] The allocation strategy is matched based on resource priority and memory status. The strategy details and performance optimization examples are shown in the table below.

[0123] Table 4. Strategy Details and Performance Optimization Examples

[0124] S2.2 Multi-heap load balancing: To avoid fragmentation or bandwidth bottlenecks caused by over-allocation of a certain kernel heap, the DXVK replica engine implements a multi-heap load balancing mechanism, which optimizes the distribution of video memory resources through heap load scoring and cross-heap allocation decisions.

[0125] S2.2.1, Heap load status acquisition.

[0126] Real-time data from each associated heap is read from the kernel shared memory. The data sources and update frequencies are as follows:

[0127] Heap used capacity: Read the heap_usage[heap_id].used field;

[0128] Heap freeable capacity: Read the heap_usage[heap_id].freeable field;

[0129] Total heap capacity: Read the heap_attr[heap_id].total_size field;

[0130] Maximum free block size: Read the heap_free_info[heap_id].max_block_size field;

[0131] Heap access latency: Read the heap_perf[heap_id].avg_access_latency field;

[0132] Based on the above data, the load score of the heap is calculated, and the scoring formula and weights are as follows:

[0133] Utilization rate is weighted at 0.5. Utilization rate = (used heap capacity - available heap capacity) / total heap capacity. 1 point is awarded for a utilization rate not exceeding 30%, 3 points for a utilization rate between 30% and 60%, 6 points for a utilization rate between 60% and 80%, and 10 points for a utilization rate exceeding 80%. Fragmentation rate is weighted at 0.3. Fragmentation rate = (Total heap capacity - maximum free block size) / total heap capacity. Fragmentation rate not greater than 10% is 1 point, between 10% and 30% is 3 points, between 30% and 50% is 6 points, and greater than 50% is 10 points. Access latency score has a weight of 0.2. Access latency less than 1μs is 1 point, between 1 and 5μs is 3 points, between 5 and 10μs is 6 points, and greater than 10μs is 10 points. Total load score = utilization score * 0.5 + fragmentation rate score * 0.3 + access latency score * 0.2. A score less than 3 indicates a low-load heap with sufficient resources and good performance, 3 to 6 indicates a medium-load heap with moderate resources and stable performance, and greater than 6 indicates a high-load heap with scarce resources that should be avoided.

[0134] S2.2.2 Resource allocation decision across stacks.

[0135] Determine the preferred kernel heap for the resource: Query the kernel heap corresponding to the resource using D3DMemMapTable, denoted as preferred_heap_id; if the heap corresponding to preferred_heap_id is a low-load heap, allocate directly to that heap; if the heap corresponding to preferred_heap_id is a medium or high-load heap, query for a compatible heap, i.e., a heap with the same heap type as the preferred kernel heap (e.g., both are HEAP_TYPE_DEVICE), supports this resource type (e.g., supports texture compression), and has a low load rating. The query logic is as follows:

[0136] Traverse all kernel heaps of the same type, filter out kernel heaps with a load score of less than 3, and denot them as compatible_heaps; for each kernel heap in compatible_heaps, calculate the cross-heap access performance loss, the formula is (preferred heap bandwidth - compatible heap bandwidth) / preferred kernel heap bandwidth * 100%;

[0137] If a compatible heap exists and the performance loss is no greater than 5%, the compatible heap with the smallest performance loss is selected for allocation. If no compatible heap exists, or the performance loss of all compatible heaps is greater than 5%, the allocation is performed on the preferred kernel heap, but a defragmentation warning is triggered, i.e., the needDefrag flag of the heap is marked as true, and defragmentation is performed when the heap load drops below medium load. The resource information of cross-heap allocation, including resource ID, original preferred heap ID, actual allocated heap ID, and cross-heap performance loss, is recorded and stored in CrossHeapAllocTable to facilitate the location of memory heaps during subsequent reclamation and avoid reclamation errors.

[0138] S2.3 Predictive pre-allocation: To avoid CPU overhead and driver latency caused by frequent calls to vkAllocateMemory every frame, the DXVK replica engine implements predictive pre-allocation based on historical game scene data, and allocates resources in advance to meet the needs of the next frame.

[0139] S2.3.1 Scene Feature Extraction.

[0140] Scene features are extracted from the DXVK frame statistics module DxvkFrameStatistics. The feature dimensions and acquisition methods are as follows:

[0141] Frame type is determined by the `m_frameType` field. A value of `FRAME_TYPE_RENDER` indicates 3D rendering, `FRAME_TYPE_UI` indicates only 2D UI, and `FRAME_TYPE_LOADING` indicates scene switching. The determination is based on whether `vkCmdDraw` is called or whether a large texture is allocated. Resource demand trend is calculated by tracking the allocation of high, medium, and low priority resources over the last 5 frames. The growth rate is calculated as (allocation in frame n - allocation in frame n-5) / allocation in frame n-5. Timestamps are calculated as the difference between the frame start time `m_frameStartTime` and the frame end time `m_frameEndTime`, representing the rendering duration. CPU and GPU synchronization time is calculated using `m_gpuSyncTime`. Resource type percentage is calculated by tracking the allocation percentage of textures, buffers, and rendering targets over the last 5 frames. For example, an increase in the buffer percentage from 20% to 40% in a combat frame indicates an increase in dynamic particle data.

[0142] The scene features are matched with a historical scene database, which is generated by training scene data from multiple games. The database stores the mapping relationship between scene features and resource requirement models. The matching method adopts Euclidean distance minimization, that is, calculating the Euclidean distance between the current scene features and all scene features in the database, and selecting the scene with the smallest distance as the matching result to determine the current scene type.

[0143] S2.3.2 Pre-allocated capacity calculation.

[0144] The pre-allocation ratio is determined based on the matched scene type, and the ratio setting is based on the fluctuation characteristics of scene resource demand: Loading frames, where high-priority resource demand fluctuates greatly, indicating sudden loading, the pre-allocation ratio is 120%, that is, pre-allocating 120% of the high-priority resource demand for the next frame; BOSS battle frames, where medium-priority buffer demand is frequent, the pre-allocation ratio is 110%, that is, pre-allocating 110% of the medium-priority buffer demand for the next frame; UI frames, where low-priority resource demand is stable, the pre-allocation ratio is 80%, that is, pre-allocating 80% of the low-priority resource demand for the next frame to avoid over-pre-allocation; Normal rendering frames, where high, medium, and low priority resource demand are balanced, the pre-allocation ratio is 100%.

[0145] The formula and constraints for calculating the pre-allocated capacity are as follows:

[0146] Single-type pre-allocated capacity = Current frame's allocation of resources of the same type * Pre-allocation ratio;

[0147] Total pre-allocated capacity = Σ(single-type pre-allocated capacity) - current available budget margin * 0.3;

[0148] If the total pre-allocated capacity is less than 0, it means that there is sufficient available capacity and no pre-allocation is needed. If the total pre-allocated capacity is greater than 10% of the total heap capacity, it means that the pre-allocation amount is too large and may cause video memory pressure. In this case, no pre-allocation is performed. Determine the memory type and heap for pre-allocation. Select according to the resource type ratio of the current scenario. Loading frames prioritize pre-allocating high-priority resources of the DEVICE_LOCAL heap, and UI frames prioritize pre-allocating low-priority resources of the HOST_VISIBLE heap.

[0149] S2.3.3, Pre-allocation execution and management.

[0150] Allocate pre-allocated capacity in the pre-allocated memory pool. The design parameters of the pre-allocated memory pool are as follows:

[0151] The pool structure adopts a ring buffer structure, which supports FIFO allocation and release. The buffer size is 1.5 times the total pre-allocated capacity of the current scene to reserve elastic space.

[0152] Pool creation involves calling vkAllocateMemory to allocate the required memory for the pool in one go, avoiding multiple allocations.

[0153] Pool management: Each heap corresponds to a pre-allocation pool to avoid performance loss caused by cross-heap pre-allocation;

[0154] The pre-allocated memory block is marked with a pre-allocation identifier FLAG_PREALLOCATED and an expiration time (expireFrameId=currentFrameId+3). The expiration time means that if it is not used within 3 frames, it will be automatically reclaimed to avoid memory waste.

[0155] When a resource allocation request is received in the next frame, memory blocks are preferentially obtained from the pre-allocation pool:

[0156] Call DxvkPreallocPool::allocate(resourceSize) to search for a memory block in the circular buffer whose size is not less than the resourceSize. If a matching block is found, mark the block's used=true, update lastUsedFrameId=currentFrameId, and return the block's memory address. If no matching block is found, perform regular allocation. After each frame ends, clean up expired and unused memory blocks in the pre-allocation pool, traverse the circular buffer, release blocks whose expireFrameId is less than currentFrameId and used=false, and update the free space in the buffer.

[0157] In the native S3 and D3D environments, once resources are bound to the rendering pipeline, it automatically ensures that the resources are ready when the GPU accesses them. Existing solutions do not cover this step, so this new step is added to synchronize resource binding with GPU access, avoiding access conflicts and data errors.

[0158] S3.1 Resource Status Check Before Binding. When DXVK performs a resource binding operation, it first checks the current status of the resource. The status types and checking methods are as follows: GPU memory allocation status: check the memoryAllocated field of the resource. If it is false, it means that no memory has been allocated, triggering emergency allocation to avoid binding empty resources; GPU lock status: check the gpuLocked field of the resource, synchronizing from drm_gem_object->flags of the kernel shared memory. If it is true, it means that the resource is being accessed by the GPU. Poll the gpuLocked flag, or wait for the kernel-associated Vulkan fence, setting a 1ms timeout until gpuLocked becomes false; Data synchronization status: if the resource is CPU-GPU... For shared resources such as D3D9_POOL_MANAGED, check if the dirty rectangle (dirtyRect) is not empty. If it is not empty, call vkFlushMappedMemoryRanges to synchronize the data modified by the CPU to the GPU. The synchronization range is equal to the memory area corresponding to the dirty rectangle to avoid full synchronization. For compressed resources such as ASTC textures, check the compressedState field of the resource. If it is COMPRESSED_STATE_UNLOADED, it means that the compressed data has not been loaded into the GPU. Call DxvkImage::decompressToGpu() to decompress the compressed data into GPU memory. The decompression process is accelerated using GPU compute shaders to avoid CPU overhead.

[0159] S3.2 Binding Conflict Detection and Avoidance. Detect access conflicts between current and bound resources: Traverse the bound resources in the current command buffer (VkCommandBuffer) and check for conflicts where the same memory address is simultaneously written to and read from. For example, resource A is written when bound as a rendering target and read when bound as a texture sample. This conflict detection is performed during the command buffer recording phase, not by modifying the already recorded command buffer. If an access conflict exists, a conflict avoidance strategy is adopted: Priority avoidance: If the conflicting resources have different priorities, unbind the lower-priority resource and bind the higher-priority resource, recording pendingBind=true for the unbound resource to indicate rebinding in subsequent frames; Time avoidance: If the priorities are the same, delay the binding of one of the resources to the next command buffer (VkCommandBuffer), and ensure the command execution order through pWaitDstStageMask of vkQueueSubmit. Record binding information, including resource ID, binding pipeline stage such as VK_PIPELINE_STAGE_VERTEX_SHADER_BIT, and access type such as read, and store it in BindingInfoTable for subsequent dynamic monitoring and conflict backtracking.

[0160] S3.3 Delayed Binding Optimization. When the GPU load is high, such as when the GPU queue utilization is collected by the kernel from the GPU hardware performance counters and written to the kernel shared memory, and DXVK reads this real-time load indicator, if the queue utilization is >90%, delayed binding is enabled: Binding of non-critical resources, such as out-of-view textures, is delayed to non-critical rendering stages, such as before UI rendering, to avoid occupying time in critical rendering stages such as vertex shading and fragment shading; delayed-binding resources are marked as FLAG_DELAYED_BIND, and binding is performed 1ms before vkCmdDraw; delayed-binding resources are batch-bound: all delayed-binding resources are collected, and vkCmdBindDescriptorSets is called all at once to reduce the number of driver calls; after binding is complete, vkCmdPipelineBarrier is called to set a memory barrier to ensure that the resource state matches the pipeline stage, such as VK_ACCESS_SHADER_READ_BIT corresponding to VK_PIPELINE_STAGE_FRAGMENT_SHADER_BIT, to avoid GPU access errors.

[0161] S4 replicates the core of VK_EXT_memory_budge's real-time monitoring function, achieving high-precision real-time control of the video memory status through multi-level granular monitoring, abnormal fluctuation detection, cross-process competition awareness, and compressed resource monitoring.

[0162] S4.1, Multi-level granular memory monitoring.

[0163] To avoid the CPU burden caused by full monitoring, the DXVK replication engine adopts a multi-level granularity strategy of high-frequency monitoring of critical resources and low-frequency monitoring of non-critical resources. The thread scheduling and data acquisition logic for each level of monitoring is as follows:

[0164] S4.1.1 Monitoring Granularity Division and Thread Configuration.

[0165] The video memory monitoring objects are divided into three levels, and the monitoring period, thread priority, and monitoring content of each level are shown in the table below.

[0166] Table 5 Monitoring Information Table for Memory Monitoring Targets

[0167] Thread scheduling optimization. The first-level monitoring thread is bound to the rendering thread to avoid thread switching overhead; the second or third-level monitoring threads use time-sharing scheduling, performing monitoring only when the CPU is idle, without affecting rendering performance.

[0168] Data collection and updating for monitoring. The data collection and updating method for the first-level monitoring thread is as follows: For high-priority resource usage, iterate through the `m_highPriorityResources` list, increment the `size` field of the resources, exclude resources marked as pending releasePending=true, and update the `DxvkMemBudgetModel::m_highPriorityUsed` field every 1ms; for `DEVICE_LOCAL` heap usage, read the kernel shared memory `heap_usage[deviceHeapId].used` and `heap_attr[deviceHeapId].total_size`, calculate the usage rate = used / total_size*100%, and update the `m_deviceHeapUsage` field; for GPU memory controller bandwidth usage: [details omitted]. The kernel adds bandwidth statistics logic to the DRM subsystem, collecting the current bandwidth (current_bandwidth) and peak bandwidth (peak_bandwidth), and calculating bandwidth usage as current_bandwidth / peak_bandwidth*100%. If the usage is greater than 90%, m_bandwidthTight is set to true. Resource conflict status is bound: the BindingInfoTable is traversed to check for unresolved access conflicts (conflictPending=true). If a conflict exists, a conflict resolution callback is triggered. Data synchronization is achieved by updating the first-level monitoring data area of ​​DxvkMemBudgetModel and then calling std::condition_variable::notify_one() to trigger data synchronization on the rendering thread.

[0169] The data collection and update methods for the secondary monitoring thread are as follows: Medium-priority resource usage: Iterate through the m_midPriorityResources list, increment the size field, and update the m_midPriorityUsed field; HOST_VISIBLE heap usage: Read the kernel shared memory heap_usage[hostHeapId].used and total_size, calculate the usage rate, and update the m_hostHeapUsage field; Cross-process GPU memory usage: Call the newly added kernel sys_gpu_mem_query interface of this invention, with the parameter QUERY_TYPE_GLOBAL, to obtain the global_used field, and update it only when the change is greater than 1% to reduce data transfer overhead; Pre-allocation pool usage: Iterate through all pre-allocation pools, calculate the usage rate = (pool used capacity / pool total capacity) * 100%, and if the usage rate is greater than 90%, trigger pre-allocation pool expansion;

[0170] The data collection and update method for the three-level monitoring thread is as follows: For low-priority resource usage, iterate through the `m_lowPriorityResources` list, increment the `size` field, and update the `m_lowPriorityUsed` field; for GPU memory fragmentation rate, read the kernel shared memory `heap_free_info[heap_id].fragmentation_rate` field. If the fragmentation rate of a heap is greater than 50% and `needDefrag=true`, trigger defragmentation; for kernel metadata integrity verification, verify the following items. If any verification fails, trigger GPU memory data repair: Total heap capacity = used heap capacity + free heap capacity (`heap_attr.total_size == heap_usage.used + heap_usage.free`); the sum of the sizes of all `drm_gem_object`s = ... The system monitors the total allocated capacity of shared memory data, performing CRC checks on both kernel and user space data (if they match, the data is complete), monitoring the status of compressed resources by iterating through the `m_compressedResources` list and monitoring the number of decompressions. If a resource's decompression count exceeds 5 times / second, it is marked as a high-reuse compressed resource, and its release cycle is delayed (e.g., from 3 frames to 10 frames). It also monitors changes in compression ratio by comparing the current compression ratio (`currentCompressRatio`) with the initial compression ratio (`initialCompressRatio`). If the change exceeds 10%, such as due to corrupted compressed data causing a decrease in compression ratio, recompression is triggered. Finally, it records the three levels of monitoring data in `dxvk_mem_mon.log`, with the log format including timestamp, heap ID, and monitoring metric values ​​for easy troubleshooting.

[0171] To prevent allocation failures and game crashes caused by sudden GPU memory usage fluctuations, the DXVK extended engine uses a normal fluctuation range and scene adaptation adjustments to achieve real-time detection of abnormal GPU memory fluctuations. The fluctuation baseline is established based on the first-level monitoring data of the past 30 frames, such as high-priority resource usage and DEVICE_LOCAL heap usage, to calculate the normal fluctuation range. The statistical formula is as follows: mean μ=(x1+x2+…+x30) / 30, where xi is the monitoring value of the i-th frame; normal fluctuation range=[μ-2σ,μ+2σ], where σ is the standard deviation. The fluctuation range is adjusted for different scene types based on the fluctuation characteristics of scene resource requirements. For loading frames, when resource requirements fluctuate greatly, such as when the standard deviation σ is twice that of normal frames, the fluctuation range is doubled, i.e., [μ-4σ, μ+4σ]. For competitive frames, when resource requirements are stable, such as when the standard deviation σ is 0.7 times that of normal frames, the fluctuation range is reduced by 30%, i.e., [μ-1.4σ, μ+1.4σ]. For UI frames, when resource requirements are very stable, such as when the standard deviation σ < 1%, the fluctuation range is fixed at [μ-5%μ, μ+5%μ]. The fluctuation baseline data, including the mean μ, standard deviation σ, and adjusted range, is stored in the FluctuationBaseline structure and updated every 30 frames.

[0172] Real-time fluctuation detection. The first-level monitoring thread compares the current monitored value with the normal fluctuation range every frame. The detection method is as follows: if the current high-priority resource usage exceeds the upper limit of the fluctuation range, and this state is maintained for two consecutive frames to exclude accidental fluctuations in a single frame, it is determined to be a high-priority fluctuation anomaly, and abnormalFlags.highPriority=true is set; if the DEVICE_LOCAL heap usage exceeds the upper limit of the fluctuation range, and the GPU bandwidth usage exceeds 80%, it is determined to be a heap load fluctuation anomaly, and abnormalFlags.heapLoad=true is set; if the cross-process GPU memory usage increases by more than 5% of the total GPU memory in a single instance, and the source of the increase is a highly interfering process, it is determined to be an external process fluctuation anomaly, and abnormalFlags.externalProcess=true is set.

[0173] Anomalies are classified into three levels based on the number of anomaly types and the current available budget balance: a minor anomaly is defined as the presence of only one type of anomaly and a current available budget balance greater than 10%; a moderate anomaly is defined as the presence of two types of anomalies or a current available budget balance less than 10%; and a severe anomaly is defined as the presence of three types of anomalies or a current available budget balance less than 5%.

[0174] The exception level is written to the exception state area m_abnormalLevel of DxvkMemBudgetModel, and the corresponding warning event is triggered: For minor exceptions, the recycling preparation event EVENT_RECYCLE_PREPARE is triggered, which only notifies the memory management thread to prepare the recycling list; for moderate exceptions, the recycling start event EVENT_RECYCLE_START is triggered, which notifies the rendering thread to perform recycling during the frame interval; for severe exceptions, the emergency recycling event EVENT_RECYCLE_EMERGENCY is triggered, which blocks the rendering thread until recycling is complete to avoid GPU memory overflow.

[0175] To address the inability to distinguish the source of memory pressure, the DXVK extension engine utilizes process-level GPU memory data from the kernel panoramic system to achieve accurate cross-process memory contention detection and response. The steps are as follows: Process type classification and weight allocation: Information on all GPU processes, including process name, PID, GPU memory usage, and process status, is read from the process_mem_usage table in the kernel shared memory. Processes are then classified according to their impact on the game. The classification rules and judgment criteria are shown in the table below.

[0176] Table 6. Process Classification Rules and Judgment Criteria

[0177] An interference weight is assigned to each type of process, based on the process's ability to preempt the game's GPU memory. Critical system processes have a weight of 1.0, meaning they cannot be restricted and their GPU memory needs must be prioritized. High-interference processes have a weight of 0.7, which limits their GPU memory growth rate and reduces interference with the game. Low-interference processes have a weight of 0.3, which allows for priority reclamation of their GPU memory, freeing up space for the game. The interference index is calculated using the formula: Σ(Process GPU memory usage * Process weight) / Total GPU memory * 100%. An interference index greater than 20% indicates high interference contention, and m_highInterference is set to true.

[0178] Competition Source Identification and Response. If abnormal fluctuations in external processes are detected, further pinpoint the primary source of competition, i.e., the highly disruptive process causing a sudden increase in GPU memory usage. The identification method is as follows: traverse the list of highly disruptive processes, calculate the process growth rate: (current usage - usage 10ms ago) / usage 10ms ago * 100% / s; processes with a growth rate greater than 100% / s are marked as the primary source of competition, and their PID, process name, and current usage are recorded.

[0179] Differentiated measures are taken based on the type of primary source of memory contention. If the primary source of contention is a video rendering process, a GPU memory limit request is sent to the Linux kernel, invoking the newly added sys_gpu_mem_limit system call of this invention. The parameters are PID = PID of the contention source, limitRate = 5% / s, to limit its GPU memory growth rate to no more than 5% / s. After receiving the request, the kernel limits the GPU memory usage of the process through the memory.gpu.limit_in_bytes extension item added to the kernel cgroup module, checking the growth rate every 100ms. If the limit is exceeded, the process is paused until the usage drops below the limit. DXVK queries the usage of the contention source every 50ms. If the growth rate is no more than 5% for three consecutive queries, the GPU memory limit is lifted.

[0180] If the main source of contention is a 3D application, such as Blender: DXVK temporarily lowers the priority of non-critical resources, such as reducing the priority of out-of-view textures and background computation buffers by 1 level; performs light recycling, such as recycling 30% of low-priority resources and releasing 10% of GPU memory to avoid contention with 3D applications; monitors changes in the usage of contention sources, and restores resource priority if their usage begins to decrease.

[0181] If the main source of contention is the system process: DXVK triggers dynamic texture resolution degradation, such as calling DxvkImage::downscaleResolution(), reducing the resolution of non-core textures in the current scene, such as distant trees and wall textures, by 50%, and regenerating mipmaps; after degradation, the amount of GPU memory saved is calculated, and if the amount saved is less than 5%, the rendering resolution is further reduced; when the system process usage drops below 10% of the total GPU memory, texture resolution restoration is triggered to avoid long-term image quality loss;

[0182] Record competition events to the log file dxvk_mem_compete.log. The log content includes the PID of the competition source, the usage change curve, the countermeasures, and the effect of the countermeasures. For example, after limiting ffmpeg, the GPU memory balance increased from 8% to 15%, which facilitates subsequent optimization of countermeasures.

[0183] To address the specific management needs of compressed resources such as ASTC textures and BC compression buffers, this step monitors the decompression frequency, data integrity, and GPU memory usage of compressed resources, preventing performance loss and data errors caused by compression. The monitoring process involves tracking the decompression frequency of compressed resources by iterating through the `m_compressedResources` list and calculating the difference between the decompression count (`decompressCount`) and the decompression interval (`lastDecompressTime` and `prevDecompressTime`). Based on this statistical data, compressed resources are categorized: high-reusability compressed resources are marked with `FLAG_HIGH_REUSE` if they decompress more than 5 times per second or have a decompression interval of less than 200ms; low-reusability compressed resources are marked with `FLAG_LOW_REUSE` if they decompress less than 1 time per minute or have a decompression interval of more than 10s; and ordinary compressed resources fall between these two categories. Management strategies are adjusted for different types of compressed resources. For high-reusability compressed resources, the delayed release period is increased from 3 frames to 10 frames to avoid frequent decompression; for low-reusability compressed resources, they are immediately marked as reclaimable (`releasePending=true`) after compression to prioritize the reclamation and release of GPU memory.

[0184] Data integrity verification for compressed resources. For each compressed resource, calculate the CRC checksum of the compressed data (compressedCrc) and the CRC checksum of the decompressed data (decompressedCrc). The checksum is calculated using the CRC32 algorithm. Compare compressedCrc with the pre-stored initial compression CRC. If they do not match, the compressed data is considered corrupted, and recompression is triggered. Compare decompressedCrc with the original data CRC. If they do not match, a decompression error is detected, and the system switches to uncompressed mode, and an error log is recorded.

[0185] GPU memory usage optimization for compressed resources: The actual compression rate of compressed resources is calculated as compressedSize / originalSize. If the actual compression rate is greater than 80%, it is marked as a low compression efficiency resource. For low compression efficiency resources, a compression strategy switch is triggered, such as switching from ASTC6x6 to ASTC8x8, or from BC5 to BC4, to reduce GPU memory usage. The total GPU memory saving of compressed resources is calculated per frame as Σ(original size - compressed size). If the saving amount is less than 5% of the total GPU memory, the proportion of compressed resources is reduced.

[0186] S5. By recording resource access trajectories, dynamically adjusting priorities, resetting resource reuse status, and optimizing delayed release, it simulates D3D reference counting and driver caching logic to achieve precise control over the resource lifecycle.

[0187] S5.1 Resource Access Trajectory Recording: The DXVK extended engine records the access status of resources for each frame through a circular buffer, providing data support for subsequent priority adjustment and release decisions. An access trajectory data structure is established, creating an access trajectory table (ResourceAccessTrace) for each resource. The structure of the access trajectory table is shown in the table below.

[0188] Table 7 Data Structure Table of Access Trajectory Table

[0189] The access trajectory table is stored in a circular buffer with a maximum capacity of 60 frames. When the capacity is exceeded, a FIFO strategy is used to overwrite the oldest record to avoid memory overflow.

[0190] Real-time access tracking: When the rendering thread performs resource access operations each frame, the `onResourceAccessed` callback is triggered. The recording logic is as follows: If the resource is bound to the rendering pipeline via `vkCmdBindDescriptorSets` and the access type is texture sampling, record `accessType=ACCESS_READ` and `accessPipelineStage=VK_PIPELINE_STAGE_FRAGMENT_SHADER_BIT`; if the resource is used as the rendering target via `vkCmdBeginRenderPass`, record `accessType=ACCESS_WRITE` and `accessPipelineStage=VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT`; if the resource is updated by the CPU via `vkCmdUpdateBuffer`, record `accessType=ACCESS_WRITE`, and `syncState=false` indicates that it has not been synchronized to the GPU. PU updates syncState=true after vkFlushMappedMemoryRanges; if the resource is not used by any Vk command, record accessType=ACCESS_NONE and referenceCount=current reference count; after the frame ends, i.e. after vkQueuePresentKHR is called, lock the access trajectory table through pthread_mutex_lock and write the access record of the frame to the circular buffer to avoid multi-threaded write conflicts; for resources with accessType=ACCESS_NONE and referenceCount=0, mark them as candidates for recycling with candidateForRelease=true to avoid immediate recycling to prevent reloading overhead caused by subsequent frame reuse, and record the last candidate time of the resource lastCandidateTime=currentFrameTime. If the resource remains in the candidate state for recycling for 3 consecutive frames and there are no access records, mark it as readyForRelease=true for immediate recycling.

[0191] S5.2 Dynamic adjustment of resource priority.

[0192] Based on historical data from the access trajectory table, resource priorities are dynamically adjusted to adapt to scene changes. The DXVK extended engine performs a resource priority update every 3 frames, replacing the static priority strategy, to ensure that priorities match the actual resource usage requirements. Specifically:

[0193] Priority evaluation metrics are calculated by extracting key metrics from the access trajectory table for the last 10 frames. The metrics are defined and calculated as follows: Access Frequency: This involves counting the number of times a resource was accessed with accessType ≠ ACCESS_NONE in the last 10 frames. Access frequency = number of accesses / 10. For example, if access occurs every frame, the frequency = 1.0; if access occurs every 5 frames, the frequency = 0.2. Recent Access Frame Difference: This is calculated by subtracting the frameId of the most recent accessType ≠ ACCESS_NONE from the current frame ID (currentFrameId) in the access trajectory table. For example, if access occurred in the last 1 frame, the frame difference is 1; if no access occurred in the last 10 frames, the frame difference is 10. Reference Count Stability: This involves calculating the reference count for the last 10 frames. The standard deviation of the reference count is calculated as `std::sqrt(Σ(referenceCount_i-avgRefCount)² / 10)`, where `avgRefCount` is the average reference count over the last 10 frames. A smaller standard deviation indicates a more stable reference count. Access pipeline stage weights are assigned based on the `accessPipelineStage`, such as a weight of 1.0 for fragment shading (VK_PIPELINE_STAGE_FRAGMENT_SHADER_BIT) and 0.5 for data transfer (VK_PIPELINE_STAGE_TRANSFER_BIT). The average pipeline weight over the last 10 frames is calculated as Σ(pipeline weights). ᵢ ) / Number of visits; Each indicator is standardized, that is, mapped to 0-1 points. The standardization formula and interval division are shown in the table below.

[0194] Table 8 Standardized Formulas and Interval Division Tables for Indicators

[0195] Dynamic Priority Calculation and Update: A dynamic priority score is calculated, introducing pipeline stage weights to improve the priority of core rendering resources. The formula is as follows: Priority Score = Access Frequency Normalized * 0.4 + Last Access Frame Difference Normalized * 0.3 + Reference Count Stability Normalized * 0.2 + Access Pipeline Stage Weight Normalized * 0.1. The resource's `dynamicPriority` field is updated based on the score. Priority levels correspond to resource handling strategies: High priority (score not less than 0.8): Marked `RESOURCE_PRIORITY_HIGH`, added to the `m_highPriorityResources` list, prohibited from active reclamation, and can only be released after backup under heavy pressure; Medium priority (score not less than 0.4 and less than 0.8): Marked `RESOURCE_PRIORITY_MID`, added to the `m_midPriorityResources` list, can be reclaimed but requires no access in the last 3 frames; Low priority (score less than 0.4): Marked `RESOURCE_PRIORITY_LOW`, added to the `m_lowPriorityResources` list, and prioritized for reclamation.

[0196] Priority adjustments are made to special resources to ensure consistency with native D3D logic: Render target resources, such as D3D11RenderTargetView, are adjusted to have a score plus 0.2 to avoid rendering pipeline interruption caused by recycling, and must still meet the corresponding priority range after adjustment; depth stencil resources, such as D3D11DepthStencilView, are adjusted to have a score plus 0.15; temporary transfer buffers, such as D3D11_USAGE_STAGING, are adjusted to have a score minus 0.3; after priority update, the resource priority table m_resourcePriorityTable of DxvkMemBudgetModel is updated synchronously, and multi-threaded visibility is ensured by std::atomic_thread_fence to avoid monitoring threads reading old data.

[0197] S5.3, Resource reuse status reset.

[0198] When a resource is reused from a pending recycling state, such as when a D3D application calls AddRef() to restore a reference, its management state needs to be reset to avoid errors caused by reusing the old state. Specifically: Reuse trigger condition detection monitors resource reference operations in the D3D application, such as IUnknown::AddRef() and IDirect3DTexture9::SetLOD(). A resource is considered reused when the following conditions are met: the resource's current state is a pending recycling candidate (candidateForRelease=true) or readyForRelease=true; the reference count changes from 0 to at least 1, or the accessType changes from ACCESS_NONE to ACCESS_READ / WRITE; the reuse operation occurs within 30 frames after the resource's last candidate time; if it is not reused within 30 frames, it is considered permanently discarded and no reset is triggered. For reused resources, the reuse trigger type is recorded, such as reference count recovery (REUSE_TYPE_REFCOUNT), re-access (REUSE_TYPE_ACCESS), and LOD adjustment (REUSE_TYPE_LOD), for subsequent state reset strategy selection.

[0199] Access Track Status Reset: Clear the access track table of the last 5 frames of no access records accessType=ACCESS_NONE, retain the pipeline stage, frequency and other data of historical access for subsequent priority calculation; update the last access time of the resource lastAccessTime to the current frame time, and mark accessType=the access type currently reused.

[0200] Compression State Reset: If the resource is a high-reuse compressed resource FLAG_HIGH_REUSE and the current state is compressedState=COMPRESSED_STATE_UNLOADED, call DxvkImage::decompressToGpu() to re-decompress the data to GPU memory, and mark compressedState=COMPRESSED_STATE_LOADED after decompression; reset the decompression count decompressCount to 1 to avoid excessive delay in release caused by historical high-frequency reuse.

[0201] Binding state reset: If a resource was previously marked as pending rebinding with pendingBind=true due to binding conflicts, clear the mark and trigger vkCmdBindDescriptorSets to rebind it to the current rendering pipeline; reset the binding conflict count bindingConflictCount to 0 to avoid misjudging the conflict state after reuse.

[0202] Budget model synchronization: The memory usage of the resource is recalculated from the simulated usage m_simulatedHeapUsage of DxvkMemBudgetModel, which has been deducted from the usage before reuse; if the resource is allocated across heaps, i.e. there is a record in CrossHeapAllocTable, the used capacity of the corresponding heap is updated synchronously to avoid budget statistics deviation.

[0203] Reuse performance optimization: For frequently reused resources, such as those reused at least twice in the last 10 frames, they are marked as hot reused resources (FLAG_HOT_REUSE) and added to the hot reused cache pool (m_hotReusePool). This pool adopts the least recently used (LRU) eviction policy to retain the first 20 hot reused resources and avoid frequent resets. The state reset of hot reused resources only requires updating key fields, such as reference count and access type, without the need for re-decompression or rebinding. After each frame, resources that have not been reused in the last 5 frames are cleaned up in the hot reused cache pool to avoid cache bloat and CPU memory consumption.

[0204] S5.4 Delayed Release Optimization. Based on resource reusability and scenario requirements, the release timing is dynamically adjusted to avoid the conflict between premature reclamation requiring reloading or delayed release occupying GPU memory.

[0205] Delayed release period calculation: Combining the most recent access frame difference of the resource and the scene type, the delayed release period is calculated, which is the number of frames from when the resource is a candidate for reclamation to when it can be immediately reclaimed. The formula is as follows:

[0206] Delayed release period = base period * scene coefficient * reuse probability coefficient; Base period: set according to resource type, 5 frames for texture resources, 3 frames for buffers, and 1 frame for temporary resources; Scene coefficient: 1.5 for open world scenes, 1.0 for competitive scenes, and 0.8 for menu scenes; Reuse probability coefficient: calculated based on the reuse count of the last 30 frames, adjusted to 1.2 when the reuse count is not less than 3, adjusted to 1.0 when the reuse count is greater than or equal to 1 and less than 3, and adjusted to 0.7 when the reuse count is equal to 0; For hot reuse resources FLAG_HOT_REUSE, the delayed release period is additionally multiplied by 1.3; For low reuse compressed resources FLAG_LOW_REUSE, the period is multiplied by 0.5.

[0207] Create a reused cache pool for resources that are released late, grouped by resource type such as textures, buffers, render targets and memory heaps. The pool size is equal to twice the average usage of the same type of resource in the current scene to reserve elastic space.

[0208] Resources in the cache pool employ a marking and clearing strategy. During the marking phase, the cache pool is traversed every frame, and resources with a release countdown of 0 (releaseCountdown=0) are marked as pending clearing. During the clearing phase, resources pending clearing are cleared in batches during the frame interval (vkQueuePresentKHR), vkFreeMemory is called to release GPU memory, and records are deleted from the access trajectory table and priority list. The cache pool hit rate, i.e., the ratio of reuse counts to the total number of cached resources, is monitored. If the hit rate is less than 30%, the pool size is reduced to 70% of the original capacity; if the hit rate is greater than 70%, the pool size is expanded to 1.5 times the original capacity.

[0209] For resources that can be immediately reclaimed, a differentiated release process is executed based on their type. For texture resources, the associated VkImageView / VkSampler is destroyed first to avoid resource dependencies causing release failure, then vkDestroyImage is called, and finally the memory vkFreeMemory is released. For buffer resources: if it is a dynamic buffer D3D11_USAGE_DYNAMIC, its mapped memory vkUnmapMemory is cleared first, then vkDestroyBuffer and vkFreeMemory are called. For compressed resources: if compressed data has been cached in system memory, the compressed data in system memory is released to avoid double occupation, and then the above release process is executed. After release, DxvkMem is updated. The simulated usage of BudgetModel, m_simulatedHeapUsage, is subtracted from the memory usage of the resource. If the resource is allocated across heaps, CrossHeapAllocTable is updated synchronously, and the corresponding record is deleted. After each frame is released, the release success rate is checked, which is the ratio of the number of successfully released resources to the number of resources to be released. If the success rate is less than 90%, there is a resource lock causing the release failure, triggering a lock resource check. Specifically, the lock_count field of drm_gem_object is traversed. For resources with lock_count greater than 0, the release is retried after waiting 1ms. If the release fails after 3 retries, it is marked as a candidate for forced release.

[0210] S6 performs tiered memory reclamation and optimization based on dynamic monitoring of stress levels, ensuring that GPU memory usage is within a safe range while minimizing performance loss.

[0211] S6.1 Memory stress level determination.

[0212] By combining budget models, abnormal states, and system-level data, the stress level can be determined from multiple dimensions to avoid misjudgment based on a single indicator.

[0213] Stress assessment metrics collection: Core metrics are collected from DxvkMemBudgetModel. Metric definitions and acquisition methods: Budget utilization: m_simulatedHeapUsage / m_baseBudget to reflect DXVK's own GPU memory pressure, updated in real time; Global GPU memory utilization: (globalUsed-globalFreeable) / globalTotal, where globalUsed and other data are obtained from kernel shared memory process_mem_usage; Abnormality level: m_abnormalLevel, updated in real time; Resource reclamation margin: the sum of low-priority resource usage and medium-priority reclaimable resource usage, calculated per frame; GPU memory error count: kernel shared memory gpu_mem_attr.error_count, updated every 100ms, a count greater than 0 indicates that GPU memory is nearing its limit.

[0214] Auxiliary indicators were collected from the kernel panoramic system: the cross-process interference index is interferenceIndex, which is updated every 10ms; the GPU memory bandwidth utilization rate is currentBandwidth / peakBandwidth, where currentBandwidth comes from the new bandwidth statistics process of the kernel DRM, which is updated every 1ms. A utilization rate greater than 95% indicates that the bandwidth bottleneck may exacerbate the GPU memory pressure.

[0215] Stress level calculation: Each indicator is quantitatively scored, with a value of 0-10. The scoring rules are based on the GPU memory sensitivity settings of the game scene, as shown in the table below.

[0216] Table 9. Pressure Rating Calculation and Scoring Rules Budget utilization rate ≤60% 60%-80% 80%-90% ＞90% Global GPU memory usage ≤70% 70%-85% 85%-95% ＞95% Abnormal level Mild moderate Medium (with bandwidth bottleneck) Severe Resource recovery surplus ≥(20% * base budget) 10%-20% of the base budget 5%-10% of the base budget <5%*basic budget GPU memory error count 0 1-3 times 4-10 times >10 times Cross-process interference index ≤10% 10%-20% 20%-30% ＞30% Video memory bandwidth utilization ≤70% 70%-85% 85%-95% ＞95%

[0217] The total stress score is calculated with higher weighting for core metrics. The formula is: Total Score = Budget Utilization * 0.25 + Global GPU Memory Utilization * 0.2 + Anomaly Level * 0.15 + Resource Reclamation Margin * 0.15 + GPU Memory Error Count * 0.1 + Cross-Process Interference Index * 0.1 + GPU Memory Bandwidth Utilization * 0.05.

[0218] The stress level is determined by the total score, and the level classification is strongly correlated with the coping strategy: Mild stress, total score less than 3 points, indicates that the GPU memory is sufficient and only routine management is needed; Moderate stress, total score greater than or equal to 3 points and less than 6 points, indicates that the GPU memory is tight and recovery needs to be initiated; Severe stress, total score not less than 6 points, indicates that the GPU memory is critical and emergency intervention is needed.

[0219] Stress Level Synchronization and Notification: The stress level is written to the stress state area m_pressureLevel of the DxvkMemBudgetModel, using std::atomic type to ensure atomic updates and avoid data races; notifications are triggered when the stress level changes: from light to moderate, a non-blocking notification pthread_cond_signal is sent to the memory management thread to prepare the reclamation list; from moderate to heavy, a blocking notification pthread_cond_wait is sent to the rendering thread to forcibly pause rendering until reclamation is complete; from heavy to moderate, the pre-allocation pool expansion limit is removed, and the normal pre-allocation ratio is restored.

[0220] S6.2 Implement differentiated recovery based on pressure level to ensure that the recovery intensity matches the pressure and avoid over-recovery or under-recovery.

[0221] When the total score is less than 3, a mild pressure recycling strategy is implemented: the recycling targets are low-priority resources that can be recycled immediately, i.e., readyForRelease=true and priority=LOW, and the recycling amount is no more than 30% of the remaining resource capacity; the recycling is performed during the frame interval, i.e., after vkQueuePresentKHR, in parallel with the rendering thread, without blocking the main thread; the recycling process is to traverse the m_lowPriorityResources list, filter out resources that can be recycled immediately and have no reuse records in the last 5 frames; sort them in descending order by the last access frame difference to reduce the probability of subsequent reuse; release resources in batches, with every 10 resources as a group, calling vkFreeMemory once to reduce the number of driver calls, and a single batch release saves 40% of CPU time compared to releasing them one by one; after recycling, the simulated usage and available budget balance of DxvkMemBudgetModel are updated. Further optimizations include pausing the pre-allocation of low-priority resources, such as temporary UI buffers, and allocating only as needed to reduce GPU memory usage.

[0222] When the total score is between 3 and 6 points (inclusive), a moderate pressure recycling strategy is implemented. The recycling targets are all low-priority recyclable resources and medium-priority resources that have not been accessed in the last 5 frames. The recycling amount is 60% of the remaining resource recycling amount. The recycling timing is mainly based on frame intervals. If the recycling amount is insufficient, it is supplemented during non-critical rendering stages of the current frame, such as before UI rendering. The recycling process is as follows: low-priority resources are recycled first, and the amount recycled is recorded. If the amount recycled is less than the target amount, the m_midPriorityResources list is traversed to filter out resources that have not been accessed in the last 5 frames and whose reference count is equal to 1, i.e., only DXVK holds references. For medium-priority resources, the reuse probability is checked first, such as the ratio of reuse times to creation times in the last 30 frames. Resources with a reuse probability of less than 10% are recycled first. Before releasing medium-priority resources, critical data such as texture mipmap level 0 data is backed up to system memory to avoid reloading required for subsequent reuse. Furthermore, additional measures include reducing the pre-allocation ratio from 100% to 70% to reduce pre-allocation usage; for compressed resources, priority is given to reclaiming low-reuse compressed resources (FLAG_LOW_REUSE) while retaining decompressed data from high-reuse compressed resources.

[0223] When the total score is not less than 6 points, a heavy-pressure resource reclamation strategy is executed. The reclamation targets are all low-priority resources, all medium-priority reclaimable resources, and high-priority non-core resources that have not been accessed in the last 3 frames. The reclamation amount is equal to 100% of the remaining resource reclamation amount plus 20% of the high-priority releasable amount. The reclamation is executed immediately, blocking the rendering thread until the reclamation amount reaches the target or there are no more reclaimable resources. The reclamation process is to reclam all low-priority and medium-priority reclaimable resources. If the target is still not met, high-priority resources are selected, and only non-core resources such as out-of-view textures and background calculation buffers that have not been accessed in the last 3 frames are reclaimed. Core resources such as in-view character textures and rendering targets are prohibited from being reclaimed. Before high-priority resources are reclaimed, all data is forcibly backed up to system memory. After the backup, backupState is marked as BACKUP_COMPLETED. After the release, a memory release notification sys_gpu_mem_release is sent to the kernel panoramic system to update the global GPU memory free amount. Furthermore, additional emergency measures are implemented, including dynamic degradation of texture resolution: calling DxvkImage::downscaleResolution() to reduce the resolution of non-core textures by 50% and regenerating mipmaps; adjusting rendering resolution, and if GPU memory is still tight, sending a resolution adjustment request to the D3D application, such as simulating ID3D11Device::CheckFeatureSupport returning insufficient GPU memory, suggesting a 10% to 20% reduction in rendering resolution; and sending a high-interference process limit request sys_gpu_mem_limit to the kernel to limit the GPU memory growth rate of high-interference processes such as ffmpeg to within 1% / s.

[0224] S6.3. Pre-assess the effect before recovery, verify and correct deviations after recovery, and ensure pressure relief.

[0225] Preliminary assessment of recycling effect: Before recycling, the expected effect is calculated based on the list of recycling objects, using the following formulas: Expected recycling amount = Σ(GPU memory usage of recycled objects) - Compressed resource backup usage; Expected budget utilization rate = (Current simulation usage - Expected recycling amount) / Base budget; Expected global GPU memory utilization rate = (Current global used capacity - Expected recycling amount) / Global total capacity.

[0226] Assess whether the expected results are met, with the standards matching the stress level: Mild stress: expected budget utilization no more than 50%; Moderate stress: expected budget utilization no more than 70% and expected global GPU memory utilization no more than 80%; Heavy stress: expected budget utilization no more than 80% and expected global GPU memory utilization no more than 90%. If the expected results are not met, adjust the resource reclamation strategy: from mild to moderate stress, increase the proportion of medium-priority resource reclamation; from moderate to heavy stress, add high-priority non-core resource reclamation; from heavy to critical stress, request the kernel to forcibly reclaim the GPU memory of low-interference processes (sys_gpu_mem_force_release), releasing 5% to 10% of the total GPU memory.

[0227] Post-recycling effect verification and correction: After recycling is completed, re-collect indicators such as budget utilization and global GPU memory utilization, and calculate the deviation between the actual effect and the expected effect: Deviation rate = |(actual recycling amount - expected recycling amount) / expected recycling amount|*100%; If the deviation rate is greater than 10%, such as expected recycling of 100MB but only 80MB is actually recycled, analyze the reasons for the deviation and correct them: Reason 1: The resource is locked by the GPU, i.e., lock_count is greater than 0, then mark the resource as the next priority for recycling, and wait for the lock to be released before retrying; Reason 2: GPU memory fragmentation, i.e., free blocks are not merged after recycling, then trigger fragmentation defragmentation; Reason 3: The recycling object list is missing, then rescan the resource list and add recyclable but unmarked resources. If the actual results still do not meet the target, such as if the budget utilization rate is still greater than 90% after heavy pressure recovery, then the ultimate measure is to suspend unnecessary rendering threads, such as background loading threads and UI animation threads, and only keep the main thread rendering; disable non-core rendering features, such as multisampling MSAA and anisotropic filtering, to reduce GPU memory requirements; if the above measures are still ineffective, return a D3DERR_OUTOFVIDEOMEMORY error to the D3D application and exit the protection immediately to avoid game crashes.

[0228] For scenarios with high fragmentation rates, defragmentation is performed: defragmentation is triggered when the heap fragmentation rate is greater than 50% and the size of the free block after reclamation is less than the current maximum resource requirement. The defragmentation process is as follows: filter movable resources, exclude GPU-locked resources and rendering target resources, and only select textures and ordinary buffers; calculate the defragmentation target, and the maximum free block size after merging is not less than 1.2 times the current maximum resource requirement; move resources in descending order of size, that is, move large resources first to reduce the number of moves, copy resources to contiguous free blocks, and release the original scattered small blocks. The movement process uses vkCmdCopyBuffer / vkCmdCopyImage; after defragmentation, update the heap free block information heap_free_info of the kernel shared memory and synchronize the fragmentation rate field of DxvkMemBudgetModel; defragmentation is only performed between frames, and a maximum of 5 resources are moved per frame to avoid CPU / GPU overload.

[0229] When the S7 and DXVK processes exit, all resources are cleaned up to ensure no GPU memory leaks, consistent with the native exit logic of D3D.

[0230] S7.1, DXVK user-mode resource cleanup.

[0231] When a D3D application calls IDirect3D9::Release() / ID3D11Device::Release() to trigger DXVK exit, user-mode cleanup is performed: resource reference counts are forcibly reset to zero; all resource managers (DxvkImageManager / DxvkBufferManager / DxvkRenderTargetManager) are traversed, and for each resource, the following actions are performed: the reference count is forcibly set to 0, the reusable and other markers are cleared, and the resource is marked as forcibly released (forceRelease=true); for compressed resources, backup data in system memory is released to prevent system memory leaks.

[0232] Batch resource release: Release resources by priority grouping based on resource type to avoid dependency-induced release failures. The release order is from the temporary resource pool m_tempResourcePool, the pre-allocation pool m_preallocPool, render target or depth template resources, texture resources, buffer resources, to the memory allocator. Batch release of the temporary resource pool and pre-allocation pool directly calls vkFreeMemory to release the entire pool's memory blocks, without releasing resources one by one. For render targets, textures, and buffers, collect the VkImage / VkBuffer / VkDeviceMemory handles of all resources, group them into sets of 20, and call vkDestroyImage / vkDestroyBuffer / vkFreeMemory once to reduce the number of driver calls. For the memory allocator, destroy the DxvkMemoryAllocator instance and release all memory blocks and data structures managed by it. During the release process, ignore the return errors of vkFreeMemory, such as resources that have already been automatically released by the driver, to ensure that the cleanup process is not interrupted.

[0233] User-space data structure cleanup: Destroy core data structures such as D3DMemMapTable, DxvkMemBudgetModel, and CrossHeapAllocTable to release CPU memory; close mmap mapping with kernel shared memory to release shared memory handles; stop all monitoring threads, terminate threads by pthread_cancel, and call pthread_join to reclaim thread resources; clear the log file buffer to ensure that logs are completely written to disk.

[0234] S7.2, Kernel-mode GPU memory data synchronization and cleanup.

[0235] After the DXVK user-space cleanup is complete, it sends an exit notification sys_gpu_mem_exit to the kernel panoramic system, triggering kernel-space cleanup.

[0236] GPU memory usage data synchronization: After receiving the notification, the kernel panoramic system iterates through all drm_gem_objects associated with the DXVK process; for each drm_gem_object, it executes: mark status=GEM_STATUS_FREED, update the freeable capacity to heap_usage[heap_id].freeable+=size; if the resource is locked (i.e., lock_count is greater than 0), it forcibly unlocks drm_gem_unlock to prevent other processes from being unable to use the memory;

[0237] Recalculate global GPU memory data: Global used capacity = Global used capacity - Capacity released by DXVK process; Global free capacity = Global total capacity - Global used capacity; Update the baseline data area of ​​kernel shared memory and the process GPU memory usage table, and delete the record of DXVK process.

[0238] Monitoring resource cleanup: Stop listening for memory contention events on the DXVK process (drm_mem_monitor_stop) and delete the monitoring callback function for the process; if the DXVK process is the main source of contention, cancel the GPU memory limit on other processes (sys_gpu_mem_limit_cancel) and release the dedicated resources allocated by the kernel for DXVK, including the monitoring data buffer (drm_mem_monitor_buffe), the cross-process contention event queue (drm_mem_compete_queue), and the shared memory cache pool.

[0239] Hardware resource reset: If there is severe pressure anomaly or more than 10 GPU memory errors before DXVK exits, the kernel panoramic system sends a lightweight GPU memory reset request drm_gem_reset to the GPU driver; the driver performs the reset operation, clearing DXVK process-related data in the GPU cache; resetting the GPU memory controller's memory page table to prevent page table residue from causing address errors in subsequent processes; releasing GPU hardware-locked resources, such as incomplete DMA transfers; after the reset is complete, updating the GPU hardware characteristic data gpu_mem_attr in the kernel to ensure that the GPU memory used by subsequent processes is in a normal state.

[0240] 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 efficient Direct3D GPU memory management based on a hot-reused cache pool, characterized in that, Specifically, the following steps are included: When the GPU does not support the VK_EXT_memory_budget extension, during the device creation phase of the D3D application, DXVK initializes the Vulkan instance and establishes an independent hot-reused cache pool in user space. It collects GPU hardware and kernel heap attributes, writes them into the kernel-specific cache pool, and completes the mapping. It then traverses the processes that occupy GPU memory, generates a GPU memory baseline, and constructs a mapping table of D3D memory type, Vulkan memory type, and kernel heap ID. Calculate and adjust the kernel heap base budget, estimate heap simulation usage and available budget margin, and trigger a light reclamation when the margin is insufficient; When creating D3D resources, DXVK extracts resource attributes to obtain priority scores, queries the mapping table to determine the preferred kernel heap, reads real-time heap data to calculate load scores, and evaluates GPU memory status in conjunction with free blocks and available budget margins; it then searches the hot reuse cache pool, and if a matching memory block is found, it reuses it directly; otherwise, it allocates GPU memory and returns the resource handle. During the rendering phase, a tiered monitoring thread is enabled to collect GPU memory data, identify memory anomalies, and issue warnings. Interference indices are calculated based on the degree of process interference, and differentiated control is implemented for high-interference scenarios according to the source of contention. High and low reused compressed resources are distinguished based on the number of decompressions and intervals, and release strategies are configured accordingly. A circular buffer is used to maintain resource access trajectories, and resource priorities are updated based on the weighted trajectories. Trajectories are updated when resources are reused, and decompression and parameter reset are performed on highly reused compressed resources. Highly reused memory blocks are retained in the hot reuse cache pool, and cold resources are removed and marked as recyclable, with the budget model updated synchronously. Pressure scores are calculated based on multiple weighted indicators to determine the pressure level, and the corresponding thread is notified when the level changes, adjusting the rendering process and the pre-allocation pool. When the DXVK process exits, it performs cleanup in both user space and kernel space.

2. The Direct3D GPU memory efficiency management method according to claim 1, characterized in that, The method for traversing the processes that occupy GPU memory and generating a GPU memory baseline is as follows: traverse the processes that occupy GPU memory, identify their process identities including desktop compositor processes and background video rendering processes, and obtain their allocated capacity, locked capacity and freeable capacity. The calculation of GPU memory baseline includes global used GPU memory, global free GPU memory, and critical process utilization ratio. Global used GPU memory is the difference between the sum of the allocated capacity of all processes and the sum of the freeable capacity of all processes. Global free GPU memory is the difference between the total capacity of all kernel heaps and global used GPU memory. Critical process utilization ratio is the ratio of the sum of the allocated capacity of desktop compositor processes and background video rendering processes to global used GPU memory.

3. The Direct3D GPU memory efficiency management method according to claim 1, characterized in that, The method for calculating and adjusting the kernel heap base budget is as follows: For the DEVICE_LOCAL heap, the base budget is equal to the total heap capacity multiplied by a first ratio; if the memory type is LPDDR5, the base budget is equal to the total heap capacity multiplied by a second ratio; for the HOST_VISIBLE heap, the base budget is equal to the total heap capacity multiplied by a third ratio; if the total heap capacity is less than or equal to a threshold, the base budget is equal to the total heap capacity multiplied by a fourth ratio; if the GPU supports memory compression, the base budget obtained above is uniformly increased by the set ratio.

4. The Direct3D GPU memory efficiency management method according to claim 1, characterized in that, The method for obtaining priority scores by extracting resource attributes using DXVK is as follows: based on the actual situation of the extracted access frequency, lifecycle, and visual impact, access frequency score, lifecycle score, and visual impact score are determined according to preset rules, and then the access frequency score, lifecycle score, and visual impact score are weighted and summed to obtain the priority score.

5. The Direct3D GPU memory efficiency management method according to claim 1, characterized in that, The method for calculating the load score by reading real-time heap data is as follows: the ratio of the difference between the used heap capacity and the heap release capacity to the total heap capacity is used as the utilization rate, and the utilization rate score is determined according to the range of the utilization rate. The ratio of the difference between the total heap capacity and the maximum free block size to the total heap capacity is used as the fragmentation rate. The fragmentation rate score is determined based on the range of the fragmentation rate. The access latency score is determined based on the range of the access latency score. Finally, the load score is obtained by weighted summation of the utilization score, fragmentation rate score, and access latency score.

6. The Direct3D GPU memory efficiency management method according to claim 1, characterized in that, If the load score of the preferred kernel heap is less than the threshold, then the underlying GPU memory is directly allocated in it for the D3D resource to be created; otherwise, a compatible kernel heap with the same heap type as the preferred kernel heap, supporting the type of resource to be created, and with a load score less than the threshold is queried. If it exists, the underlying GPU memory is allocated in the compatible kernel heap for the resource to be created and the cross-heap allocation information is recorded. If it does not exist, the memory is allocated in the preferred kernel heap and the defragmentation forecast of the preferred kernel heap is triggered.

7. The Direct3D GPU memory efficiency management method according to claim 1, characterized in that, DXVK extracts scene features including frame type, resource demand trend, timestamp, and resource type proportion. It calculates the Euclidean distance between scene features in the historical scene library and the extracted scene features, selects the scene feature with the smallest distance as the matching result, and determines the current scene type for matching. The historical scene library is a database built based on scene data from multiple applications to store the mapping relationship between scene features and resource demand models. DXVK sets the pre-allocation ratio based on the matched scene type, calculates the pre-allocation capacity, and sets allocation constraints; it selects the memory type and kernel heap corresponding to the pre-allocation based on the resource type ratio of the current scene, allocates the pre-allocation capacity in the pre-allocation memory pool, and sets the pre-allocation identifier and expiration time; when a resource allocation request is received in the next frame, it prioritizes obtaining GPU memory blocks from the pre-allocation memory pool and marks the GPU memory block as used; after each frame is executed, it cleans up the expired and unused GPU memory blocks in the pre-allocation pool.

8. The Direct3D GPU memory efficiency management method according to claim 1, characterized in that, The hierarchical monitoring threads include a first-level monitoring thread for monitoring high-priority resource usage, kernel heap utilization, GPU memory controller real-time bandwidth usage, and bound resource conflict status; a second-level monitoring thread for monitoring medium-priority resource usage, GPU shared memory heap utilization, cross-process GPU memory usage, and pre-allocated pool utilization; and a third-level monitoring thread for monitoring low-priority resource usage, GPU memory fragmentation rate, kernel metadata integrity, and compressed resource status. The first-level monitoring thread has real-time priority, the second-level monitoring thread has normal priority, and the third-level monitoring thread has low priority. The first-level monitoring thread is bound to the rendering thread of the D3D application, and the second and third-level monitoring threads are scheduled to be executed only when the CPU is idle.

9. The Direct3D GPU memory efficiency management method according to claim 1, characterized in that, The high-interference scenario implements differentiated management based on the source of contention as follows: if the largest source of contention is a video rendering process, DXVK sends a memory limit request to trigger the kernel to limit the process's use of GPU memory; if the largest source of contention is a 3D application process, DXVK temporarily lowers the priority of non-critical resources and performs light recycling; if the largest source of contention is a system process, DXVK triggers dynamic degradation of texture resolution.

10. The Direct3D GPU memory efficiency management method according to claim 1, characterized in that, When recording rendering instructions in a D3D application and binding resources to the rendering pipeline using resource handles, DXVK checks the GPU memory allocation status of the resource during the resource binding operation. If it is not allocated, it triggers an emergency GPU memory allocation. It also checks the GPU lock status; if the resource is being accessed by the GPU, it sets a timeout to wait for the access to end. Finally, it checks the data synchronization status; when the resource is a shared resource between the CPU and GPU, it checks whether the CPU has modified the data. If it has, it synchronizes the modified data from the CPU to the GPU. If it is a compressed resource, it decompresses the resource to GPU memory. Iterate through the resources bound in the current command buffer. If there are two different resources being written to and read from the memory address at the same time, if the two resources have different priorities, the lower priority resource will be unbound from the memory address first. If the two resources have the same priority, the binding operation of either resource will be delayed to the next command buffer and the binding information and access type will be recorded. When the GPU load exceeds the threshold, resources with a priority lower than the threshold will be delayed until a set time before the Vulkan drawing command is executed to complete the batch binding.

Images