A Direct3D 12 resource management method based on virtual universal layout

Abstract

The application discloses a Direct3D 12 resource management method based on a virtual general layout, and after VKD3D is initialized when VK_KHR_unified_image_layouts is not supported, a mapping matrix of a D3D12 resource state, a virtual general layout, a Vulkan physical layout and a pre-compiled conversion path library are constructed by traversing a Vulkan image format, when a D3D application creates a D3D12 resource, parameters are parsed to divide a sub-resource, a resource handle containing a physical layout pool and a sub-resource view array is created, binding of a Vulkan image and memory is completed, when a resource state is set, a resource handle is inquired, the virtual general layout and the Vulkan physical layout are compared in sequence, redundant requests with no change in semantics and layout are filtered to obtain a resource conversion request, the resource conversion request is combined to generate a batch memory barrier instruction, and the batch memory barrier instruction is pre-submitted to a kernel, and execution is completed by a GPU idle time window.

Description

Technical Field

[0001] This invention belongs to the field of computer software development technology, and specifically relates to a Direct3D 12 resource management method based on a virtual universal layout. Background Technology

[0002] VKD3D is an open-source project that emulates Direct3D 12 (hereinafter referred to as D3D12) based on the Vulkan 1.3 standard. Its core workflow is to translate D3D12 API calls on the Windows platform into Vulkan API calls on the Linux platform. Its efficient operation heavily relies on the VK_KHR_unified_image_layouts extension feature. The core value of this feature lies in unifying Vulkan image layout semantics, enabling the VK_IMAGE_LAYOUT_GENERAL general layout to equivalently replace most dedicated layouts, while eliminating redundant layout transformation operations, reducing the CPU and GPU overhead caused by Pipeline Barrier instructions, and ensuring that the performance of the general layout is consistent with that of the dedicated layout.

[0003] Differences between D3D12 and Vulkan resource state models: D3D12 uses an implicit, lightweight resource state model. Applications only need to specify resource states such as render targets and shader resources when using them, and the driver automatically manages state transitions. This results in low transition overhead and a small number of states. Vulkan, on the other hand, uses an explicit, heavyweight image layout model. Layout transitions must be manually performed using Pipeline Barrier instructions, specifying the preceding and following layouts. This results in high transition overhead and can easily cause GPU pipeline stalls. The VK_KHR_unified_image_layouts extension is a standard feature of Vulkan 1.3, which unifies layout semantics. VK_IMAGE_LAYOUT_GENERAL can effectively replace most dedicated layouts, reducing transition overhead, eliminating the need for manual layout transitions, and reducing the number of Barriers. However, when the GPU does not support this feature, VKD3D will face the following technical challenges: First, the semantic gap between D3D12's implicit lightweight state model and Vulkan's explicit heavyweight layout model is difficult to bridge, requiring manual implementation of accurate mapping from D3D12 state to Vulkan layout, which is prone to mapping errors; second, frequent manual layout conversions will generate a large number of Barrier instructions, leading to a surge in CPU command logging overhead, GPU pipeline stalls, and a significant performance drop; third, resource state tracking in multi-threaded environments is prone to conflicts, and older GPUs have different support for Vulkan-specific layouts, resulting in poor cross-hardware compatibility.

[0004] Existing solutions achieve transformations only through simple state mapping tables and centralized state tracking, which suffers from problems such as low mapping accuracy, high transformation overhead, and numerous state synchronization conflicts, failing to meet the requirements for efficient VKD3D operation. Summary of the Invention

[0005] In view of this, the present invention provides a Direct3D 12 resource management method based on virtual universal layout, which achieves compatible operation of D3D12 applications without supporting the VK_KHR_unified_image_layouts extended feature.

[0006] This invention provides a Direct3D 12 resource management method based on a virtual universal layout, which specifically includes the following steps:

[0007] VKD3D is pre-executed to establish a virtual generic layout corresponding to the D3D12 resource state. The Vulkan physical layout is matched for the virtual generic layout. The mapping matrix formed by the correspondence between the D3D12 resource state, the virtual generic layout and the Vulkan physical layout is embedded in VKD3D. The Vulkan memory barrier instruction chain is pre-compiled to form a pre-compiled conversion path library.

[0008] When starting VKD3D and D3D applications, VKD3D determines the number of sub-resources when creating D3D12 resources. The mapping matrix determines the initial virtual general layout, establishes the first resource handle, allocates a Vulkan physical layout pool for it, and creates a Vulkan image view for the physical layout in the pool according to the number of sub-resources. Vulkan memory blocks are allocated, and the Vulkan memory blocks are bound to the Vulkan image view with the physical layout as a parameter. The creation timestamp of the physical layout and the initial sub-resource status are added to the sub-resource status array and added to the first resource handle table.

[0009] When setting the D3D12 resource status, the first resource handle is determined from the first resource handle table, and the current virtual general layout and sub-resource status array are obtained. The target virtual general layout corresponding to the target resource status is determined according to the parameters and mapping matrix passed by the application. If it is the same as the current virtual general layout and the status of the sub-resource range matches, the process ends. Otherwise, the current Vulkan physical layout and the target Vulkan physical layout are obtained from the Vulkan physical layout pool of the first resource handle. If they are the same, the current virtual general layout and the sub-resource status array are updated and the process ends. Otherwise, the conversion path is obtained from the pre-compiled conversion path library, the sub-resource range is recorded, and a resource conversion request is generated.

[0010] VKD3D adds dependency tags to resource conversion requests, adds them to the rendering channel partition based on the dependency tags, and generates a merge candidate set by grouping the resource conversion requests when executing the command queue. The parameters of the merge candidate set are replaced with memory barrier parameters from the pre-compiled conversion path library and pre-submitted to the kernel. The kernel allocates non-conflicting conversion instructions to the GPU's idle time window for execution.

[0011] Furthermore, the number of sub-resources is determined by the number of extracted MIP levels and the number of array slices, and the unique identifier of the sub-resource is determined by the MIP level and the array slice.

[0012] Furthermore, the first resource handle includes a unique resource identifier, the current abstract layout, the bound Vulkan image view, a physical layout pool pointer, a state update timestamp, a sub-resource state array, and a memory access counter.

[0013] Furthermore, the method of adding resource transformation requests to the rendering pass partition based on dependency tags is as follows:

[0014] Parse the first rendering command after the current resource barrier in the D3D12 command queue, record the access type of the resource to be transformed by the command, add a dependency flag that must be completed before the command to the resource transformation request if it is a write, and add a dependency flag that can be executed in parallel if it is a read.

[0015] VKD3D creates a hierarchical deferred conversion queue consisting of rendering channel partitions. Each rendering channel partition contains a high-priority subqueue and a low-priority subqueue. Requests that must be completed before the command are added to the high-priority subqueue, while requests that can be executed in parallel are added to the low-priority subqueue.

[0016] Furthermore, after generating a resource conversion request, the resources that need to be physically converted are grouped according to the source physical layout, target physical layout, and conversion path. Within each group, the resources are sorted in descending order of the number of sub-resources, with those having more sub-resources being processed first. A scheduling priority is assigned to each group, with resources that have a high dependency on the next rendering command having high priority and resources that have no direct dependency having low priority.

[0017] Furthermore, for requests for the same resource in the merge candidate set, overlapping or adjacent sub-resource ranges are merged to generate a merged sub-resource range; for requests for different resources with the same format or layout in the merge candidate set, the image fields in the memory barrier of the image resource are merged into an array, sharing the same pipeline stage mask and access mask; for requests in the merge candidate set that contain local transformations of sub-resources, the local range is specified in the memory barrier.

[0018] Furthermore, the method of replacing the parameters of the merge candidate set with the memory barrier parameters in the pre-compiled transformation path library is as follows: load the pre-compiled memory barrier parameters from the pre-compiled transformation path library, and replace the image view and sub-resource range therein with the merged data; if the merge candidate set contains requests that can be executed in parallel, set a flag in the memory barrier to allow the GPU to execute the transformation in parallel according to the sub-resource.

[0019] Furthermore, for complex transformations that require intermediate layout, independent sub-paths are first separated from the pre-compiled transformation path library. Each sub-path is matched with an independent memory barrier instruction and marked with the estimated execution time. According to the sub-path type, it is allocated to the pipeline stage corresponding to the GPU. The time balance is adjusted according to the idle threshold of each pipeline stage. If the total time of a sub-path in a certain stage exceeds the threshold, some sub-paths are split to adjacent idle stages.

[0020] Furthermore, a distributed state node containing a global master copy and a thread-local LRU cache copy is created for each first resource handle. The global master copy stores the resource authority state and is protected by atomic operations. Each command record thread maintains an independent LRU cache table to store the state of the most recently accessed resource and uses the LRU strategy to clean up expired and low-version caches.

[0021] When a thread modifies a resource's state, it first checks the local cache. If the cache hits and the version matches the global primary copy, it uses the resource directly. If the cache misses or the version doesn't match, it updates the local cache. The global primary copy is then updated using atomic operations. If the operation fails, a step-by-step backoff process, involving spinning, yielding the CPU, and then sleeping, is implemented based on the number of conflicts. If the number of retries exceeds a set number, the resource is marked as a high-conflict resource, and batch merging updates are used to reduce conflicts. After the global primary copy is successfully updated, the local cache is refreshed synchronously.

[0022] Furthermore, when the lifecycle of a D3D12 resource ends, the resource reference count returns to 0, triggering destruction. The corresponding handle is deregistered from the first resource handle table, and the resource status data in all thread-local caches is cleared. The kernel is notified to delete all unexecuted instructions for the resource in the kernel layout transformation queue and terminate related scheduling. The underlying resource reclamation is completed, the Vulkan image view in the physical layout pool is destroyed, and the Vulkan image memory and objects are unbound and released.

[0023] When an application actively discards a resource, it parses the passed-in sub-resource range, cleans up all pending conversion requests for that resource in the hierarchical delayed conversion queue and marks them as not needing to be executed; it notifies the kernel to stop conflict detection and scheduling for that resource, releases the kernel-side trace data; it resets the memory access counter of the first resource handle and marks the resource as discarded;

[0024] When VKD3D exits or is reinitialized, all static underlying resources that were built are cleaned up, and the kernel is notified to clean up static cache data synchronously.

[0025] Beneficial effects:

[0026] This invention, after VKD3D initialization, iterates through Vulkan image formats to generate a GPU layout support table and a conversion rule table, constructs a mapping matrix of D3D12 resource states, virtual generic layouts, and Vulkan physical layouts, and a pre-compiled conversion path library. When a D3D application creates D3D12 resources, VKD3D parses the parameters and divides the resources into sub-resources according to MIP levels and array slicing, creating resource handles containing physical layout pools and sub-resource view arrays, completing the binding of Vulkan images to memory and recording the initial state. When the application sets the resource state, VKD3D queries the resource... The source handle is compared with the abstract layout and the Vulkan physical layout. Redundant requests with no changes in semantics and layout are filtered out, and resource conversion requests are generated only for sub-resources with inconsistent states. Dependency tags are added to the conversion requests and stored in a hierarchical delay queue partitioned by rendering channel. When the queue is triggered, the sub-resource range and compatible instructions are merged to generate a batch of memory barrier instructions to be pre-submitted to the kernel. The kernel detects instruction conflicts, executes conflict-free instructions using the GPU idle time window, and synchronizes the resource state to VKD3D after execution. VKD3D updates the resource handle table and notifies the kernel to complete the cleanup. Attached Figure Description

[0027] Figure 1 This is a flowchart illustrating a Direct3D 12 resource management method based on a virtual universal layout, provided by the present invention. Detailed Implementation

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

[0029] This invention provides a Direct3D 12 resource management method based on a virtual universal layout. The core idea is as follows: After VKD3D initialization, it iterates through Vulkan image formats to generate a GPU layout support table and a conversion rule table, constructing a mapping matrix of D3D12 resource states, virtual universal layout, and Vulkan physical layout, as well as a pre-compiled conversion path library. When a D3D application creates D3D12 resources, VKD3D parses parameters and divides sub-resources according to MIP level and array slicing, creating resource handles containing a physical layout pool and a sub-resource view array, completing the binding of Vulkan images to memory and recording initial states. When the application sets resource states, VKD3D... KD3D queries resource handles, compares the abstract layout and Vulkan physical layout, filters redundant requests with no semantic or layout changes, and generates resource conversion requests only for sub-resources with inconsistent states. It then adds dependency tags to the conversion requests and stores them in a hierarchical delay queue partitioned by rendering channel. When the queue is triggered, it merges sub-resource ranges and compatible instructions, generating batch memory barrier instructions to be pre-submitted to the kernel. The kernel detects instruction conflicts, executes conflict-free instructions using the GPU idle time window, and synchronizes the resource state to VKD3D after execution. VKD3D updates the resource handle table and notifies the kernel to complete the cleanup.

[0030] This invention provides a Direct3D 12 resource management method based on a virtual universal layout, the processing flow of which is as follows: Figure 1 As shown, the specific steps include:

[0031] Step 1: Perform VKD3D initialization beforehand, traverse Vulkan image formats to record their supported image layouts, and generate a GPU layout support table, which includes image format, layout type, support status, and performance parameters. The support status indicates whether the Vulkan physical layout corresponding to the Vulkan image format is supported by the current GPU hardware, and the performance parameters include access latency, etc.; detect the GPU's restrictions on layout transformation and generate a GPU layout transformation rule table, which includes source layout, target layout, whether direct transformation is allowed, intermediate layout, and estimated transformation time, and record the execution efficiency parameters of the GPU's memory barrier instructions.

[0032] Simulate the general characteristics of VK_IMAGE_LAYOUT_GENERAL, establish an abstract layout that corresponds one-to-one with the D3D12 resource state. The abstract layout is the virtual general layout. Match the optimal Vulkan physical layout to the abstract layout according to the GPU layout support table, and mark the performance weight of the physical layout. The weight of the special layout is higher than that of the general layout. The mapping matrix is ​​composed of the correspondence between the D3D12 resource state, the abstract layout and the Vulkan physical layout. Compile the mapping matrix into a binary library file and embed it into the VKD3D code. Generate a mapping verification table to record the legality of the mapping and avoid illegal mapping.

[0033] The system identifies resource state transition sequences that occur more than a threshold in D3D12 applications, pre-calculates the required memory barrier instruction parameters, and maps intermediate states in the resource state transition sequence to Vulkan physical layout transition paths based on the mapping matrix. The system then pre-compiles and generates a complete Vulkan memory barrier instruction chain, forming a pre-compiled transition path library.

[0034] Step 2: Start VKD3D and D3D applications. When the D3D application creates D3D12 resources, VKD3D parses the creation parameters of the D3D12 resources to obtain the resource type, image format, resource purpose, initial resource status, number of sub-resources and memory attributes. The number of sub-resources is determined by the number of extracted MIP levels and the number of array slices. The unique identifier of a sub-resource is determined by the MIP level and the array slice.

[0035] Based on the initial resource state, the initial abstract layout matching the resource to be created is determined by the mapping matrix. A first resource handle is established for the resource to be created based on the initial abstract layout. A Vulkan physical layout pool is allocated to the first resource handle to store all Vulkan physical layouts that the first resource handle may use. For each physical layout in the physical layout pool, a corresponding Vulkan image view is pre-created according to the number of sub-resources, and an array of sub-resource views is generated. The activation status is marked for them. By default, only the optimal physical layout matching the initial abstract layout is activated, and the remaining layouts are set to a dormant state.

[0036] The system obtains the memory requirements of Vulkan image resources that match the optimal physical layout. Based on the memory attributes of the D3D12 resources, it matches the optimal Vulkan memory type from the memory types supported by the GPU, allocates the corresponding Vulkan memory block, binds the allocated Vulkan memory block to the created Vulkan image view with the physical layout as the binding parameter, records the creation timestamp of the physical layout and the initial sub-resource state, and saves them to the sub-resource state array. The system describes the first resource handle using the resource unique identifier, the current abstract layout, the bound Vulkan image view, the physical layout pool pointer, the state update timestamp, the sub-resource state array, and the memory access counter. The first resource handle is saved to the VKD3D first resource handle table, where the memory access counter is used to count the number of memory read and write operations.

[0037] Step 3: When the D3D application sets the D3D12 resource state, VKD3D looks up the first resource handle of the resource in the first resource handle table based on the D3D12 resource pointer, and obtains the current abstract layout and sub-resource state array; it parses the parameters passed by the application to extract the target resource state and the sub-resource range that needs to be modified, matches the target abstract layout corresponding to the target resource state according to the mapping matrix, and compares the current abstract layout with the target abstract layout. If they are the same and the state of the sub-resource range completely matches the sub-resource state array, it means that there is no semantic change, so the Vulkan layout conversion is not performed and the process ends; otherwise, proceed to step 4.

[0038] Step 4: From the Vulkan physical layout pool of the first resource handle, obtain the current Vulkan physical layout corresponding to the current abstract layout and the target Vulkan physical layout corresponding to the target abstract layout. If the current Vulkan physical layout and the target Vulkan physical layout are completely identical, only update the current abstract layout and the sub-resource state array, record the state update timestamp, do not perform Vulkan layout conversion, and end this process; if they are partially identical, only generate resource conversion requests for the sub-resources with inconsistent states, and execute Step 5; if they are completely inconsistent, find the conversion path ID from the current physical layout to the target physical layout from the pre-compiled conversion path library, record the sub-resource range, generate a resource conversion request, and execute Step 5.

[0039] Furthermore, when setting resource states in batches for D3D applications, after traversing all resources to be converted, uniformly executing the abstract layout semantic parsing in step 3 and the physical layout judgment in step 4, and filtering out resources that do not need to be converted, the following steps are also required: grouping the resources that need to be physically converted into groups according to the source physical layout, target physical layout, and conversion path ID; sorting the resources within each group in descending order of the number of sub-resources, prioritizing those with more sub-resources to reduce the number of subsequent merging operations; and assigning scheduling priorities to each group, with resources that have a high dependency on the next rendering command having high priority and resources that have no direct dependency having low priority, ensuring that critical conversions are executed first.

[0040] Step 5: Parse the first rendering command after the current resource barrier in the D3D12 command queue, and record the access type of the resource to be converted. If it is a write, add a dependency tag that must be completed before the command for the resource conversion request; if it is a read, add a dependency tag that can be executed in parallel.

[0041] VKD3D creates a hierarchical delayed conversion queue consisting of rendering channel partitions. Each rendering channel partition contains a high-priority sub-queue and a low-priority sub-queue. Resource conversion requests are added to the corresponding sub-queue within the rendering channel partition based on dependency tags and grouping priorities. Requests that must be completed before the command are added to the high-priority sub-queue, and requests that can be executed in parallel are added to the low-priority sub-queue.

[0042] When the command queue is triggered, resource conversion requests are regrouped according to conversion path ID and dependency flags to ensure that the barrier parameters of requests in the same group are compatible, and a merge candidate set is generated. For requests for the same resource in the merge candidate set, overlapping or adjacent sub-resource ranges are merged to generate a merged sub-resource range. For requests for different resources with the same format or layout in the merge candidate set, the image fields in the memory barrier of the image resource are merged into an array, sharing the same pipeline stage mask and access mask. For requests in the merge candidate set that contain local conversions of sub-resources, the local range is specified in the memory barrier.

[0043] For each merge candidate set, pre-compiled memory barrier parameters are loaded from the pre-compiled transformation path library, and the image view and sub-resource range are replaced with the merged data. If the merge candidate set contains requests that can be executed in parallel, a flag is set in the memory barrier to allow the GPU to execute the transformation in parallel according to the sub-resources. The batch memory barrier instructions are pre-submitted to the kernel layout transformation queue, and the submission timestamp of the instructions and the number of resources involved are recorded. The batch memory barrier instructions include resource identifier, transformation path ID, sub-resource range and dependency flag.

[0044] Furthermore, for complex transformations requiring intermediate layout, this invention first separates independent sub-paths from the pre-compiled transformation path library, matches each sub-path with an independent memory barrier instruction and marks the estimated execution time; then, according to the sub-path type, it allocates them to the corresponding pipeline stage of the GPU, utilizing the parallelism of the GPU pipeline to reduce the total execution time; finally, it performs time balancing adjustment based on the idle threshold of each pipeline stage. If the total execution time of a sub-path in a certain stage exceeds the threshold, some sub-paths are split to adjacent idle stages to ensure that the execution time of each stage's sub-path does not exceed its own idle time.

[0045] Furthermore, to adapt to the performance differences of different GPUs, this invention dynamically adjusts the trigger threshold of the tiered delay conversion queue. Specifically, by statistically analyzing the average execution time of memory barrier instructions after batch merging and the CPU commit time, the trigger thresholds of the high-priority sub-queue and the low-priority sub-queue are adjusted. If the average execution time of the memory barrier is greater than the threshold, the trigger threshold is lowered to reduce the number of resources in a single merge and avoid excessive execution time. If the CPU commit time is less than the threshold, the trigger threshold is raised to increase the number of resources in a single merge and further reduce the number of memory barrier instructions.

[0046] The present invention extends the conditions for triggering the execution of the delay queue, including: executing all sub-queues when the rendering channel ends; executing only the high-priority request of the resource when the resource is actually used for drawing or scheduling operations; executing the sub-queue when the number of requests in a certain sub-queue in the delay queue reaches a preset threshold; and clearing the queue when the remaining space in the command buffer is less than 10%.

[0047] Step 6: The kernel iterates through the instructions in the kernel layout translation queue. If the same sub-resource is operated on by two translation instructions simultaneously, it is marked as a conflict. The conflict information is sent to VKD3D to regenerate the instruction and pre-commit it. If there is no conflict, the kernel detects the GPU's idle time window in real time and allocates conflict-free instructions to the GPU's idle time window for execution. After the instruction is executed, the kernel writes the state of the translated resource to the kernel user-space shared memory area and notifies VKD3D that the state has been updated. VKD3D reads the state data in the shared memory, updates the first resource handle table, records the kernel synchronization timestamp, and notifies the kernel that the state has been synchronized. The kernel deletes the instruction from the kernel layout translation queue.

[0048] Specifically, when sending conflict information to VKD3D to regenerate instructions and pre-commit, if conflicts still exist after VKD3D regenerates instructions N times, the instruction is downgraded to user space and directly committed to ensure that the instruction is not lost.

[0049] This invention divides the GPU's idle time window into high-priority windows with a duration greater than a threshold and low-priority windows with a duration less than a threshold. When allocating conflict-free memory barrier instructions to the GPU's idle time window for execution, high-priority instructions are allocated to high-priority windows to ensure completion before rendering commands; low-priority instructions are allocated to low-priority windows, and if there are not enough windows, they are accumulated to the next high-priority window.

[0050] Furthermore, to resolve resource state conflicts during multi-threaded command recording and submission, this invention adds a cache expiration and fast repair process, as detailed below:

[0051] A distributed state node containing a global master copy and a thread-local LRU cache copy is created for each first resource handle. The global master copy stores the resource authority state and is protected by atomic operations. Each command record thread maintains an independent LRU cache table to store the state of the most recently accessed resource. The LRU strategy is used to clean up expired and low-version caches to reduce access contention for the global master copy.

[0052] When a thread modifies a resource's state, it first checks the local cache. If the cache hits and the version matches the global primary copy, it uses the resource directly. If the cache misses or the version doesn't match, it updates the local cache. The global primary copy is then updated using atomic operations. If the operation fails, a step-by-step backoff process, involving spinning, yielding the CPU, and then sleeping, is implemented based on the number of conflicts. If the number of retries exceeds a set number, the resource is marked as a high-conflict resource, and batch merging updates are used to reduce conflicts. After the global primary copy is successfully updated, the local cache is refreshed synchronously.

[0053] Furthermore, to avoid rendering errors caused by state conflicts, the following checks are performed sequentially: thread-level verification comparing the cached and global versions; kernel-level verification comparing the GPU hardware state with the expected state; and Vulkan driver-level verification for layout validity before command execution. If a conflict is detected, only the conflicting command fragment is regenerated to replace the original list, without a full rollback, and the conflict details are written to the debug log. When multiple threads submit their command queues to the same D3D12 command queue, all state modification records are grouped according to resource identifiers. Based on the submission order of the command queues, multi-step state modifications for the same resource are merged into a unified state sequence. Then, a globally unified layout transformation instruction is regenerated based on this sequence to ensure the continuity of resource states across threads and command queues, and to avoid cross-list state conflicts.

[0054] Furthermore, to resolve the dependency conflict issue during layout transformation before and after D3D12 synchronization points and avoid state inconsistencies, this invention performs the following processing steps for the two core synchronization interfaces, Signal and Wait:

[0055] For the Signal interface, the transformation dependencies are marked and the scheduling priority is increased. Specifically, the signal type, fence and event parameters of the Signal interface are parsed, all incomplete layout transformation instructions before the synchronization point are traversed, and a dependency mark that must be completed before the Signal is added to them; at the same time, the kernel interface is called to upgrade the scheduling priority of these instructions to the highest level, so as to ensure that all related layout transformations are completed before the synchronization signal is sent, and to avoid state gaps caused by transformations still being executed after the signal is sent.

[0056] For Wait interface processing, the transformation instructions are predicted and preloaded in advance. Specifically, the wait type, duration and other parameters of the Wait interface are parsed, and based on the analysis of historical command sequences, the first layout transformation instruction that needs to be executed after Wait is completed is predicted. This instruction is preloaded into the high-priority sub-queue of the hierarchical delayed transformation queue, and the corresponding memory barrier parameters are precompiled. After Wait is completed, it can be scheduled and executed immediately, which greatly reduces the transformation latency after waiting.

[0057] Before the Signal call, a pre-signal snapshot is generated for the abstract layout, Vulkan physical layout, and sub-resource status of all converted resources, and stored in the corresponding fence or event object. After the Wait is completed, a post-wait snapshot is generated. The resource status of the snapshots before and after are compared. If the status is consistent, the subsequent operations are executed normally. If they are inconsistent, the kernel interface is called to restore the resource status from the snapshot, so as to avoid synchronization failure caused by other queues modifying resources.

[0058] Furthermore, at the end of the D3D12 resource lifecycle, this invention achieves comprehensive resource reclamation in user mode, kernel mode, and hardware mode, avoiding memory leaks, instruction residues, and state pollution, forming a complete closed loop of resource management, as detailed below:

[0059] When the resource reference count reaches 0 and destruction is triggered, the corresponding handle is deregistered from the first resource handle table, and the resource status data in all thread-local caches is cleared; the kernel is notified to delete all unexecuted instructions for the resource in the kernel layout transformation queue and terminate related scheduling; the underlying resource reclamation is completed, the Vulkan image view in the physical layout pool is destroyed, the Vulkan image memory and objects are unbound and released, and related synchronization objects are reset;

[0060] When an application actively discards a resource, it parses the passed-in sub-resource range, cleans up all pending conversion requests for that resource in the hierarchical delayed conversion queue and marks them as not needing to be executed; it notifies the kernel to stop conflict detection and scheduling for that resource, releases the kernel-side trace data; it resets the memory access counter of the first resource handle and marks the resource as discarded;

[0061] When VKD3D exits or is reinitialized, all static base resources built are cleaned up, including GPU layout support tables, pre-compiled transformation path libraries, etc., and the kernel is notified to clean up static cache data synchronously.

[0062] Example:

[0063] This embodiment employs a Direct3D 12 resource management method based on a virtual universal layout provided by the present invention. It enables the normal operation of D3D 12 applications in a GPU hardware environment that does not support the VK_KHR_unified_image_layouts extended feature. The specific process includes:

[0064] S1. GPU layout capability detection and static mapping library construction during the initialization phase: obtain the layout support features of the GPU in advance, and construct static mapping resources that are semantically aligned with VK_KHR_unified_image_layouts, corresponding to the VKD3D initialization process vkd3d_instance_create.

[0065] S1.1, Full detection of GPU layout capabilities.

[0066] During VKD3D initialization, the Vulkan vkGetPhysicalDeviceImageFormatProperties2 and vkGetPhysicalDeviceFeatures2 interfaces are called to perform the following probing operations:

[0067] Iterate through all Vulkan image formats (such as VK_FORMAT_R8G8B8A8_UNORM, VK_FORMAT_D32_SFLOAT), record all image layouts supported by each format, such as whether VK_IMAGE_LAYOUT_DEPTH_STENCIL_READ_ONLY_OPTIMAL is supported, and generate a GPU layout support table. Each table entry contains a quadruple of image format, layout type, support status, and performance parameters.

[0068] Detect GPU restrictions on layout transformations, such as whether direct conversion from VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL to VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL is allowed, and whether an intermediate layout VK_IMAGE_LAYOUT_TRANSFER_DST_OPTIMAL is required. Generate a GPU layout transformation rule table, with each entry containing a 5-tuple of source layout, target layout, whether direct conversion is allowed, intermediate layout (if any), and estimated conversion time.

[0069] Record GPU barrier instruction execution efficiency parameters, such as CPU commit time for a single barrier, GPU execution time, and maximum number of parallel barriers, to provide data for subsequent performance optimization.

[0070] Construct the static mapping matrix from S1.2 and D3D12 states to Vulkan layout.

[0071] Based on the unified layout semantics of VK_KHR_unified_image_layouts, a D3D12 state, VGL, and Vulkan layout mapping matrix is ​​defined. This matrix has a three-dimensional structure, with dimensions representing D3D12 resource state, VGL abstract layout, and Vulkan physical layout, respectively. The specific design is as follows:

[0072] VGL Abstract Layout Definition: Simulates the general characteristics of VK_IMAGE_LAYOUT_GENERAL, defining 8 types of VGL layouts that correspond one-to-one with the core states of D3D12, including VGL_LAYOUT_RENDER_TARGET, VGL_LAYOUT_SHADER_RESOURCE, VGL_LAYOUT_DEPTH_WRITE, VGL_LAYOUT_PRESENT_SRC, VGL_LAYOUT_COPY_DST, etc., covering all standard resource states of D3D12 (including advanced states such as D3D12_RESOURCE_STATE_RAYTRACING_ACCELERATION_STRUCTURE);

[0073] Mapping rule definition: For each D3D12 resource state (e.g., D3D12_RESOURCE_STATE_RENDER_TARGET), bind a unique VGL layout (e.g., VGL_LAYOUT_RENDER_TARGET). Then, according to the GPU layout support table, match the optimal Vulkan physical layout for the VGL layout (prioritize dedicated layouts, and if not supported, downgrade to VK_IMAGE_LAYOUT_GENERAL), and mark the performance weight of the layout (e.g., dedicated layout weight 1.0, general layout weight 0.7).

[0074] Static mapping library compilation: The mapping matrix is ​​compiled into a binary library file and embedded into the VKD3D code for direct loading at runtime; at the same time, a mapping verification table is generated to record the validity basis of each mapping (such as GPU model, Vulkan version) to avoid illegal mappings.

[0075] S1.3, Layout Transition Path Precompilation. For frequently occurring state transition sequences in D3D12 applications (such as render target to shader resource and back to render target, copy target to shader resource), based on the GPU layout transition rule table, all legal layout transition paths are precompiled, generating a precompiled transition path library:

[0076] For each transformation sequence, the required barrier parameters (such as source pipeline stage mask, target pipeline stage mask, memory access mask, image sub-resource range, and dependency_flags) are pre-computed and stored as binary structures. For transformations requiring intermediate layout (such as COLOR_ATTACHMENT_OPTIMAL to TRANSFER_DST_OPTIMAL → SHADER_READ_ONLY_OPTIMAL), a complete barrier instruction chain is pre-generated, and the execution order dependency of each sub-transformation is marked. A unique ID is assigned to each transformation path (such as 0x001 representing COLOR_ATTACHMENT_OPTIMAL to SHADER_READ_ONLY_OPTIMAL), and an index table of path IDs to performance consumption is established to facilitate the selection of low-cost paths during subsequent scheduling.

[0077] The VGL handle binding and physical layout pre-allocation of S2 and D3D12 resources correspond to the ID3D12Device::CreateResource interface conversion of D3D12. A VGL abstract handle and Vulkan physical layout pool are allocated to each D3D12 resource to simulate the single layout management characteristics of VK_KHR_unified_image_layouts.

[0078] S2.1, VGL resource handle creation.

[0079] When VKD3D receives a resource creation request from D3D12, it performs the following operations:

[0080] Parse the creation parameters of the D3D12 resource (such as resource type, format, purpose, initial state, number of sub-resources, and memory attributes), and match the corresponding initial VGL layout from the mapping matrix between D3D12 state, VGL, and Vulkan layout; create a VGL resource handle for the resource, which contains the following attributes: resource unique identifier (UUID), current VGL layout, bound Vulkan image object (VkImage), physical layout pool pointer, state update timestamp, sub-resource state array (recording the independent state of each mipmap level and array slice), and memory access counter (counting the number of read and write operations); store the VGL handle in the VKD3D VGL resource handle table, which uses a hash table structure for storage, with the key being the D3D12 resource pointer and the value being the VGL handle, supporting lookup with O(1) time complexity.

[0081] S2.2 Vulkan physical layout pool pre-allocation solves the problem of adapting a single resource to multiple Vulkan layouts. Based on the layout equivalence of VK_KHR_unified_image_layouts, a physical layout pool is pre-allocated for each VGL resource handle. The specific design is as follows:

[0082] The physical layout pool contains all the Vulkan physical layouts that the resource may use, determined by the GPU layout support table and mapping matrix. For example, the layout pool for rendering the target resource contains VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL, VK_IMAGE_LAYOUT_GENERAL, and VK_IMAGE_LAYOUT_PRESENT_SRC_KHR.

[0083] For each physical layout in the layout pool, a corresponding Vulkan image view (VkImageView) is pre-created, and an array of sub-resource views is generated according to the number of sub-resources (e.g., 5 views corresponding to mipmap levels 0-5), avoiding the overhead of creating views at runtime.

[0084] Mark the activation status for each layout in the layout pool (by default, only the optimal layout is activated, and other layouts are in a dormant state). When a non-optimal layout is needed, it is activated through vkCmdPipelineBarrier to reduce the initial memory usage.

[0085] S2.3, Initial Vulkan resource creation for the initial layout. Based on the initial VGL layout of the VGL handle, the optimal Vulkan physical layout is selected from the physical layout pool, and the following creation process is executed:

[0086] The system calls `vkGetImageMemoryRequirements` to obtain the image memory requirements, combines the memory attributes of the D3D12 resource (such as `D3D12_HEAP_TYPE_DEFAULT`), and selects the matching Vulkan memory type. It then calls `vkAllocateMemory` to allocate memory and `vkBindImageMemory` to bind the image to the memory, specifying the initial physical layout in the binding parameters. The system records the creation timestamp of the initial layout and the initial sub-resource state, storing them in the sub-resource state array of the VGL handle to ensure the accuracy of the starting point for subsequent state tracking.

[0087] The S3 and D3D12 state settings determine the necessity of VGL semantic transformation and layout transformation, corresponding to the ID3D12GraphicsCommandList::ResourceBarrier interface transformation of D3D12. Based on VGL semantics, it determines whether the actual Vulkan layout transformation needs to be performed, simulates the reduced redundant transformation characteristics of VK_KHR_unified_image_layouts, and adds synchronous dependency processing logic.

[0088] VGL semantic parsing of S3.1 and D3D12 states.

[0089] When VKD3D receives a resource status setting request from D3D12, such as switching a resource from a render target to a shader resource, it performs the following parsing operations:

[0090] Find the VGL handle of the target resource from the VGL resource handle table, and obtain its current VGL layout CurrentVglLayout and subresource state array SubresourceStates;

[0091] Parse the D3D12_RESOURCE_BARRIER parameter of D3D12 to extract the target state TargetD3D12State and the subresource range, such as mipmap level 0 to 2 and array slice 1;

[0092] Find the target VGL layout TargetVglLayout corresponding to TargetD3D12State from the D3D12 state, VGL to Vulkan layout mapping matrix;

[0093] Comparing CurrentVglLayout and TargetVglLayout, if they are consistent and the state of the sub-resource range matches SubresourceStates, then skip the subsequent operations and no conversion is needed; if they are inconsistent or the sub-resource states do not match, then proceed to the layout conversion necessity judgment stage.

[0094] S3.2, Determine the necessity of conversion based on the physical layout pool.

[0095] To avoid redundant conversions where the VGL layout changes but the physical layout does not, the following judgment logic is executed:

[0096] From the physical layout pool of the VGL resource handle, obtain the physical layout CurrentVkLayout corresponding to CurrentVglLayout and the physical layout TargetVkLayout corresponding to TargetVglLayout respectively.

[0097] Check the consistency between CurrentVkLayout and TargetVkLayout:

[0098] If they are completely identical, only the CurrentVglLayout and SubresourceStates arrays of the VGL handle are updated, and the state update timestamp is recorded. No Vulkan layout conversion operation is performed. If they are partially identical, such as the parent resource layout is the same but the child resource layout is different, only the inconsistent child resources are converted, and a child resource partial conversion request is generated. If they are completely inconsistent, the conversion path ID from CurrentVkLayout to TargetVkLayout is searched in the pre-compiled conversion path library. The low-cost path is selected first, the range of child resources required for conversion is recorded, and the subsequent conversion scheduling stage begins.

[0099] S3.3 Batch semantic parsing and priority sorting of multi-resource status settings.

[0100] For batch ResourceBarrier requests in D3D12, setting the status of multiple resources at once employs a strategy of batch semantic parsing and grouping sorting:

[0101] Iterate through all resources to be converted, uniformly perform VGL semantic parsing and conversion necessity judgment, and filter out resources that do not need to be converted; group the resources that need to be converted into physical layouts according to source layout, target layout and conversion path ID, sort the resources in each group in descending order of the number of sub-resources, and prioritize the ones with more sub-resources to reduce the number of subsequent mergings; assign scheduling priorities to each group, with high priority to groups that are highly dependent on the next rendering command (such as Draw or Dispatch) (such as rendering target resources), and low priority to groups that have no direct dependency (such as backup buffer resources), to ensure that critical conversions are scheduled first.

[0102] S3.4, Dependency records for state transitions.

[0103] To avoid conflicts between the transformation and subsequent commands, the dependencies of each transformation request are recorded:

[0104] Parse the first rendering command (e.g., vkCmdDrawIndexed) after the current ResourceBarrier in the D3D12 command queue, and record the access type (read or write) of the transformation resource by the command; add a dependency flag to the transformation request, if the subsequent command is a write access, the transformation request is marked as must be completed before the command, if it is a read access, it is marked as can be executed in parallel (synchronization required); bind the dependency flag to the transformation request, and store it in the delay queue as the basis for scheduling.

[0105] S4. Delayed scheduling and batch merging of layout transformations correspond to the command recording stage of VKD3D. By delaying scheduling, fine merging, and pipeline rearrangement, the number and time of Barrier instructions are reduced, simulating the low transformation overhead characteristics of VK_KHR_unified_image_layouts.

[0106] S4.1, Design of a hierarchical delayed conversion queue.

[0107] In VKD3D, a hierarchical deferred conversion queue is created. The queue adopts a structure of rendering pass partitions and priority sub-queues. Each rendering pass partition is defined by ID3D12GraphicsCommandList::BeginRenderPass and EndRenderPass, and each contains high-priority sub-queues and low-priority sub-queues. The specific operations are as follows:

[0108] When a conversion request is received, a Barrier instruction is not generated immediately. Instead, based on dependency tags and grouping priorities, the conversion information, including the resource VGL handle, source physical layout, target physical layout, conversion path ID, sub-resource range, and dependency tags, is stored in the sub-queue of the corresponding rendering pass partition. Conversion requests that must be completed before the command are stored in the high-priority sub-queue, while conversion requests that can be executed in parallel are stored in the low-priority sub-queue. The conditions for triggering the execution of the delayed queue have been increased to four categories, including: when the rendering pass ends (execute all sub-queues), when the resource is actually used for drawing or scheduling operations (execute only the high-priority request containing that resource), when the number of requests in a sub-queue in the delayed queue reaches a preset threshold (32 for high-priority and 64 for low-priority), and when the remaining space in the command buffer is less than 10% (clean up the queue in advance to avoid command overflow).

[0109] S4.2 Fine-grained batch merging based on sub-resources.

[0110] When the delayed queue is triggered, the transformation information in the queue is processed in three steps: path grouping, sub-resource merging, and instruction generation, to minimize the number of barriers.

[0111] Path grouping: Traverse the transformation requests in the sub-queue, group them again by transformation path ID and dependency flag, ensure that the Barrier parameters of requests in the same group are compatible, and generate a merge candidate set for each group;

[0112] Fine-grained sub-resource merging is implemented as follows: For the same resource in the merge candidate set, overlapping or adjacent sub-resource ranges are merged (e.g., mipmap levels 0 to 2 and 1 to 3 are merged into 0 to 3), generating a merged sub-resource range; For requests with different resources but the same format or layout, the image field in their VkImageMemoryBarrier structures is merged into an array (supporting up to 256 resources at a time, conforming to the Vulkan 1.3 specification), sharing the same source and target pipeline stage masks and access masks; For requests involving partial sub-resource transformations, the local range is precisely specified in the subresourceRange field of the Barrier to avoid the overhead of full resource transformation;

[0113] Batch Barrier instruction generation: For each merge candidate set, load the pre-compiled Barrier parameters from the pre-compiled transformation path library and replace the image and subresourceRange with the merged data;

[0114] If the merged candidate set contains requests that can be executed in parallel, set the VK_DEPENDENCY_BY_REGION_BIT flag in the Barrier to allow the GPU to perform the transformation in parallel by sub-resources, thereby improving efficiency; call the vkCmdPipelineBarrier interface to submit batch Barrier instructions, and record the submission timestamp of the instructions and the number of resources involved for subsequent performance statistics.

[0115] S4.3 Pipeline rearrangement and time balancing of conversion paths.

[0116] For complex transformations requiring intermediate layouts (such as from A to B and then to C, where A=COLOR_ATTACHMENT_OPTIMAL, B=TRANSFER_DST_OPTIMAL, C=SHADER_READ_ONLY_OPTIMAL), a strategy is adopted that involves sub-path splitting, pipeline allocation, and time balancing.

[0117] Sub-path splitting: Extract complex transformation sub-paths (such as A to B and B to C) from the pre-compiled transformation path library. Each sub-path corresponds to an independent Barrier instruction, and the estimated execution time of the sub-path is marked (obtained from the GPU layout transformation rule table).

[0118] GPU pipeline stage allocation:

[0119] The GPU pipeline stages (such as the transport stage, vertex shader stage, and fragment shader stage) are analyzed, and stages are allocated according to the type of the subpath: transport-type conversions from A to B are allocated to the transport stage, and shader access-type conversions from B to C are allocated to the vertex shader stage. In the command buffer, the barrier instructions of the subpath are inserted into the command sequence of the corresponding stage, and the total time is reduced by utilizing the pipeline parallelism of the GPU (such as the parallelism of the transport stage and the vertex shader stage).

[0120] Time-balanced adjustment:

[0121] If the total time of a sub-path in a certain pipeline stage exceeds the stage idle threshold (e.g., the idle time of the transmission stage is only 5ms, but the total time of the sub-path is 8ms), then some sub-paths will be split into adjacent idle stages (e.g., splitting the conversion of some sub-resources from B to C into the fragment coloring stage). After adjustment, ensure that the total time of the sub-paths in each stage is less than or equal to the idle time of that stage to avoid pipeline stalling.

[0122] S4.4 Dynamic threshold adjustment for delay queues.

[0123] To accommodate the performance differences of different GPUs, the trigger threshold of the delay queue is dynamically adjusted:

[0124] After every 10 batch merges, the average execution time of the Barrier instruction and the CPU commit time are calculated. If the average execution time is greater than 30% of the GPU's single-frame idle time, the trigger threshold is lowered (the high-priority threshold is changed from 32 to 24, and the low-priority threshold is changed from 64 to 48) to reduce the number of resources in a single merge and avoid excessive time consumption. If the CPU commit time is less than 10% of the total time recorded by the command, the trigger threshold is raised (the high-priority threshold is changed to 48, and the low-priority threshold is changed to 96) to increase the number of resources in a single merge and further reduce the number of Barriers.

[0125] S5, kernel-mode layout transformation command pre-scheduling and idle time filling, by modifying the Linux kernel source code, achieves deep collaborative scheduling between user mode and kernel mode, further reducing the GPU overhead of layout transformation, simulating the performance guarantee characteristics of VK_KHR_unified_image_layouts, and adding conflict detection and dynamic window adjustment.

[0126] S5.1, an extension of the Vulkan command scheduling interface for the Linux kernel.

[0127] Modify the Linux kernel's Direct Rendering Manager (DRM) subsystem, adding the following four core interfaces to the drm_vulkan module to form a closed loop of pre-commitment, detection, scheduling, and synchronization:

[0128] The drm_vk_layout_transition_pre_submit interface allows VKD3D to pre-submit the binary data of batch Barrier instructions (including resource UUID, transformation path ID, sub-resource range, and dependency flags) to the kernel's kernel layout transformation queue (a circular buffer structure with configurable capacity), and returns the pre-submission ID for subsequent queries;

[0129] The `drm_vk_layout_conflict_detect` interface is called by the kernel after receiving a pre-commit instruction to detect conflicts: it iterates through the existing instructions in the kernel layout transformation queue, compares the resource UUID and the sub-resource range, and if the same sub-resource is operated on by two transformation instructions at the same time, it is marked as a conflict; for conflicting instructions, they are retained according to the principle of earlier pre-commit time, and the later-committed instructions are marked as pending rescheduling, and the conflict information is returned to VKD3D;

[0130] The drm_gpu_idle_window_detect interface detects the GPU's idle time window in real time, using a combination of hardware counters and software estimation: it reads the GPU's hardware performance counters, such as GPU_IDLE_COUNTER, to obtain the actual idle time; and combines this with the execution progress of the current command stream (such as the time until the next VSync) to estimate the available idle window duration (actual idle time × 0.8, with a safety margin).

[0131] The drm_barrier_pipeline_schedule interface allocates conflict-free barrier instructions to the GPU's idle time window for execution, supporting multi-window splitting (if an instruction takes longer than a single window, it is split into multiple sub-instructions for execution in separate windows).

[0132] S5.2, Pre-commit and conflict handling of user-mode conversion commands.

[0133] After generating the batch Barrier instructions, VKD3D performs the following pre-commit process:

[0134] Call the drm_vk_layout_transition_pre_submit interface to submit the instruction binary data, execution priority (high or low), and dependencies (if they need to be completed before Draw) to the kernel;

[0135] Receive the conflict detection result returned by the kernel: if there is no conflict, record the pre-commit ID and wait for the synchronization signal of the kernel scheduling completion; if there is a conflict (the instruction is marked as to be rescheduled), regenerate the conversion instruction of the conflicting resource (adjust the sub-resource range or conversion path), and pre-commit again, retrying up to 3 times (to avoid infinite loop).

[0136] For instructions that still conflict after 3 retries, the process is downgraded to direct commit in user mode to ensure that the instructions are not lost.

[0137] S5.3, Dynamic scheduling and priority adaptation of idle time in kernel mode.

[0138] After obtaining available free windows through the drm_gpu_idle_window_detect interface, the Linux kernel's DRM subsystem performs the following scheduling operations: window classification, dividing free windows into high-priority windows (such as VSync gaps, duration ≥ 1ms) and low-priority windows (such as rendering pass gaps, duration < 1ms).

[0139] Command allocation: High-priority barrier commands (such as render target transformations) are assigned to high-priority windows to ensure they are completed before rendering commands; low-priority commands (such as back buffer transformations) are assigned to low-priority windows, and if there are not enough windows, they are accumulated to the next high-priority window.

[0140] Dynamically adjust the window detection threshold: If the GPU load is <30% (judged by GPU_UTILIZATION_COUNTER), the window detection threshold is lowered (scheduling is triggered when the available idle window is ≥0.5ms), increasing the scheduling frequency; if the GPU load is >80%, the threshold is raised (triggered ≥2ms) to avoid frequent scheduling consuming GPU resources.

[0141] Instruction execution monitoring: The kernel monitors the execution progress of Barrier instructions in real time. If an instruction is not completed within the window, it is marked as timed out, the remaining part is split into the next window, and the priority of the instruction is reduced (to avoid occupying a critical window).

[0142] S5.4. Two-way state synchronization and confirmation between kernel and user space.

[0143] After executing the Barrier instruction, the kernel achieves bidirectional synchronization through shared memory and semaphores:

[0144] The kernel writes the converted resource state (resource UUID, new physical layout, sub-resource state, execution completion timestamp) to the shared memory area between the kernel and user space (created during VKD3D initialization, 4MB in size); the kernel sends the VK_SEMAPHORE_SIGNALED semaphore to VKD3D to notify that the state has been updated; after receiving the semaphore, VKD3D reads the state data in the shared memory, updates the CurrentVkLayout and SubresourceStates arrays of the corresponding resource in the VGL resource handle table, and records the kernel synchronization timestamp; VKD3D calls the drm_vk_layout_sync_ack interface to send back confirmation information that the state has been synchronized to the kernel. After receiving the confirmation, the kernel deletes the instruction from the kernel layout conversion queue (to avoid duplicate processing).

[0145] S6. Distributed lock-free resource state tracking in a multi-threaded environment: This solves the resource state conflict problem when recording multi-threaded commands. It designs a distributed mechanism of global master replica, thread caching, and consistency verification to ensure the accuracy of the state. It corresponds to the multi-threaded command recording process of VKD3D (such as ID3D12CommandQueue::ExecuteCommandLists) and adds cache expiration and fast repair logic.

[0146] S6.1 Distributed Deployment and Cache Management of VGL State Nodes.

[0147] A distributed state node is created for each VGL resource handle. The node adopts a two-layer structure of a global primary copy and a thread-local cache copy, as detailed below:

[0148] Global Master Copy: Stores the authoritative state of resources, located in the global memory area of ​​VKD3D. It includes the current VGL layout, the current Vk layout, the sub-resource state array, the last modified thread ID, the modified version number (incremented by 1 with each update), and read-write lock flags (0 indicates no lock, 1 indicates read lock, 2 indicates write lock). All fields are modified by std::atomic, supporting atomic operations.

[0149] Thread-local cache copy: Each command record thread (such as the thread corresponding to ID3D12GraphicsCommandList in D3D12) maintains an LRU cache table (64 nodes in size to avoid excessive memory consumption) to store the state of the resources recently accessed by the thread: the cache table entries include the resource UUID, cached state data (VGL layout, Vk layout, sub-resource state), cache version number (corresponding to the modification version number of the global main copy), and access timestamp; an LRU strategy is used to clean up expired cache: when the cache table is full, the table entries with the earliest access timestamp and cache version number less than the global version number are deleted to ensure cache validity.

[0150] S6.2 Lock-free state update protocol and backoff mechanism.

[0151] When a thread needs to modify the state of a resource, it executes the following lock-free update protocol to avoid lock overhead:

[0152] Cache hit determination: The thread first queries the local LRU cache table and looks up the cache entry based on the resource UUID. If a hit occurs and the cache version number is equal to the modification version number of the global primary replica, the state data in the cache is used directly without accessing the global primary replica. If a miss occurs or the version number does not match, the global primary replica is read. The state data and modification version number of the global primary replica are read through atomic operations, and the local cache table is updated (overwriting the old table entry).

[0153] Atomic update of the global primary replica: When a thread is about to modify the state, it executes the `std::atomic_compare_exchange_strong` operation: Expected value: the current modification version number of the global primary replica; New value: the modified state data, the sum of the modification version number and 1; If the operation succeeds (expected value matches), the update is successful, and the last modifying thread ID is recorded; If the operation fails (expected value does not match, indicating that another thread has already modified it), it enters the backoff and retry process: First failure: spin wait 10ns (short wait, suitable for high-frequency short conflicts); Second failure: call `std::this_thread::yield()` (yield the CPU, suitable for medium-frequency conflicts); Third failure: call `std::this_thread::sleep_for(1us)` (long wait, suitable for low-frequency long conflicts); If the number of retries exceeds 5, the resource is marked as a high-conflict resource, and subsequent updates will use batch merging updates (accumulating multiple modification requests and updating at once) to reduce the probability of conflict;

[0154] Cache synchronization: After the global primary replica is successfully updated, the cache entries (status data and version number) of the corresponding resources in the local cache table are updated synchronously, and the access timestamp is recorded.

[0155] S6.3, Detection, rapid repair, and logging of state conflicts.

[0156] To avoid rendering errors caused by multi-threaded state modifications, a three-level verification and rapid repair mechanism is designed:

[0157] Level 1 verification (in-thread verification): Before the command is submitted to the queue, the thread traverses the local cache table and compares the cache version number of all modified resources with the modification version number of the global primary replica: if the version numbers match, the verification is marked as passed; if the version numbers do not match, the verification is marked as pending Level 2 verification.

[0158] Level 2 verification (kernel-mode verification): VKD3D calls the drm_vk_validate_resource_state interface to submit the list of resources to be verified (UUID and expected state) to the kernel. The kernel reads the GPU's hardware status register (such as RESOURCE_STATE_REG) to obtain the actual state of the resources; it compares the expected state with the actual state: if they match, it returns a verification pass; if they do not match, it returns conflict details (such as the actual layout is A, and the expected layout is B).

[0159] Level 3 validation (pre-command execution validation): Before submitting commands to the GPU, the Vulkan driver validates the legality of the resource layout again (using the VK_LAYER_KHRONOS_validation layer of Vulkan Validation Layers) to ensure that nothing is missed;

[0160] Quick Repair: For conflicting resources detected by secondary verification: VKD3D directly reuses the actual GPU state as the new expected state based on the conflict details returned by the kernel, and regenerates the command fragment containing the correct layout transformation; it replaces the conflicting part in the command queue without rolling back the entire command queue, and the repair time is no more than 100us (far faster than traditional full rollback).

[0161] Conflict logging: Writes conflict details (resource UUID, conflict type, fix result, and occurrence time) to the VKD3D debug log (supports VK_EXT_debug_utils extended output), making it easier for developers to optimize multi-threaded logic.

[0162] S6.4, Merging the state consistency of multi-threaded command queues.

[0163] When multiple command queues (corresponding to different threads) are submitted to the same command queue (ID3D12CommandQueue), the following state merging is performed:

[0164] Iterate through all resource status modification records in the command queues and group them by resource UUID. For each group of resources, compare the status modification order in different command queues and merge them into a unified status sequence according to the command queue submission order (e.g., if thread 1 modifies status A to B and thread 2 modifies status B to C, merge them into A to B and then C). Based on the merged status sequence, regenerate globally unified layout conversion instructions to ensure the continuity of resource status in the command queues and avoid status conflicts across lists.

[0165] The layout conversion dependency handling of the S7 and D3D12 synchronization interfaces corresponds to the conversion of the ID3D12CommandQueue::Signal and ID3D12CommandQueue::Wait interfaces of D3D12, which solves the dependency problem of layout conversion before and after the synchronization point and avoids inconsistency in state.

[0166] S7.1, Signal interface conversion dependency tags.

[0167] When VKD3D receives a Signal interface call (the command queue sends signals to fences and events):

[0168] Parse the parameters of Signal (such as hFence, Value) to determine the signal type of the synchronization point (fence signal and event signal); traverse all incomplete layout transformation instructions before Signal and add signal dependency flags to these instructions: mark them as instructions that must be completed before Signal; call the drm_vk_layout_transition_priority_upgrade interface to upgrade the kernel scheduling priority of these instructions to the highest level, ensuring that all transformations are completed before the synchronization point and preventing transformations from continuing to execute after the signal is sent.

[0169] S7.2 Wait interface conversion dependency preloading.

[0170] When a Wait interface call is received (command queue waiting for fence or event signal):

[0171] Parse Wait parameters (such as hFence and Timeout) to determine the wait type and duration of the synchronization point; predict the first layout transformation instruction to be executed after Wait is completed (based on historical command sequence analysis, such as the transformation from the back buffer to the rendering target is usually executed after Wait); preload the predicted transformation instructions into the high-priority sub-queue of the hierarchical delayed transformation queue in advance, precompile the Barrier parameters, and schedule them immediately after Wait is completed to reduce the latency after Wait.

[0172] S7.3, State snapshots before and after the synchronization point.

[0173] To ensure that the state before and after the synchronization point is traceable, perform the following snapshot operation:

[0174] Before a Signal is generated, a snapshot of the state of all converted resources (VGL layout, Vk layout, and sub-resource state) is generated and stored in the fence or event object corresponding to the Signal. After a Wait is completed, a snapshot of the state after the Wait is generated and compared with the current state. If the state is consistent, the subsequent conversion is executed normally. If the state is inconsistent (e.g., other queues have modified resources), the drm_vk_layout_state_restore interface is called to restore the state from the snapshot to avoid synchronization failure.

[0175] S8 features hardware-independent layout degradation and performance compensation, addressing the issue of insufficient support for dedicated layouts on older GPUs. It implements a hardware-independent mechanism for automatic degradation, performance compensation, and vendor adaptation, ensuring compatibility with GPUs of different generations and corresponding to the cross-GPU adaptation process of VKD3D.

[0176] S8.1 Automatic triggering and hierarchical division of layout degradation.

[0177] When the GPU does not support the optimal physical layout corresponding to a certain VGL layout, execute the following fallback logic to ensure semantic consistency:

[0178] Degradation tiers: Vulkan layouts are divided into three levels based on performance and functionality: Level 1 (optimal), dedicated layouts (e.g., COLOR_ATTACHMENT_OPTIMAL), highest performance, full functionality; Level 2 (second best), vendor-extended layouts (e.g., VK_IMAGE_LAYOUT_AMD_SHADER_READ_ONLY), performance close to Level 1, partial functionality support; Level 3, general layouts (VK_IMAGE_LAYOUT_GENERAL), lowest performance, most complete functionality.

[0179] Automatic triggering process: Search for supported layouts in the physical layout pool of VGL resource handles in order from level 1 to level 2 and then to level 3; if level 1 layout is not supported (e.g., older Intel HD 530 does not support VK_IMAGE_LAYOUT_DEPTH_STENCIL_READ_ONLY_OPTIMAL), then try level 2 layout; if level 2 is also not supported, then downgrade to level 3 layout;

[0180] Update the layout mapping in the VGL resource handle table, record the degradation level, degradation reason (e.g., the GPU does not support level 1 layout), degradation timestamp, and output degradation prompt (including GPU model) to the log system.

[0181] S8.2, Multi-dimensional performance compensation after degradation.

[0182] For resources downgraded to level 2 or 3 layouts, a three-dimensional compensation strategy involving shaders, memory, and scheduling is employed to improve performance to near level 1:

[0183] Shader access optimization: Modify the SPIR-V shader code generated by VKD3D: For Level 3 layout (GENERAL) resources, replace the imageLoad or imageStore instructions with optimized versions of imageRead or imageWrite (utilizing the GPU's general access hardware acceleration); for Level 2 vendor extended layouts, insert vendor-specific optimization instructions (such as AMD's OPTION AMD_shader_image_load_store) to enable hardware-specific paths;

[0184] Memory bandwidth optimization: Call the Linux kernel's drm_gpu_memory_optimize interface to allocate high-bandwidth memory partitions (such as NVIDIA's VRAM high-speed partitions and Intel's eDRAM) for degraded resources; if the resource is read-only (such as texture resources), enable memory compression (such as VK_IMAGE_USAGE_TRANSFER_DST_BIT+ compression format) to reduce memory bandwidth usage;

[0185] Scheduling frequency optimization: Extend the trigger threshold for degraded resources in the tiered delayed conversion queue (e.g., from 32 to 64) to reduce the number of layout conversions; for frequently accessed degraded resources, pre-allocate a double-buffered layout pool (maintaining resource copies of two different layouts simultaneously to avoid real-time conversions), such as a render target copy (GENERAL layout) and a display copy (PRESENT_SRC layout), and synchronize data through vkCmdCopyImage.

[0186] S8.3, Vendor-specific layout adaptation and optimization table.

[0187] For GPUs from major manufacturers such as NVIDIA, AMD, and Intel, predefined manufacturer-specific layout adaptation tables are used to maximize the utilization of hardware features.

[0188] NVIDIA GPUs: Prioritize the use of VK_IMAGE_LAYOUT_NV_SHADER_READ_ONLY_OPTIMAL as the level 2 layout, replacing SHADER_READ_ONLY_OPTIMAL; for resources in the GENERAL layout, enable VK_NV_memory_attachment extension to improve memory access efficiency;

[0189] AMD GPU: Uses VK_IMAGE_LAYOUT_AMD_DEPTH_CLAMP_OPTIMAL as a two-level layout for depth buffering to reduce depth testing overhead; for multi-threaded conversion, enables VK_AMD_gpu_shader_int16 extension to optimize sub-resource state calculation;

[0190] Intel GPUs: For older integrated graphics (such as HD 530), the resources of the GENERAL layout are bound to the high-speed channel of the Unified Memory Architecture (UMA) to reduce the latency of data interaction between the CPU and the GPU; partial conversion of sub-resources is disabled and full resource conversion is used (older Intel drivers have poor support for partial conversion) to avoid rendering errors.

[0191] S9, the cleanup of layout conversion remnants during the resource destruction and discard phase, corresponds to the conversion of the ID3D12Resource::Release and ID3D12GraphicsCommandList::DiscardResource interfaces in D3D12. The core is to clean up the residual data of the layout conversion to avoid memory leaks and resource conflicts.

[0192] S9.1, Unregistering and clearing cached VGL resource handles.

[0193] When a D3D12 resource is destroyed (Release interface call, reference count is 0), VKD3D performs the following operations: removes the corresponding VGL handle from the VGL resource handle table and releases the memory occupied by the handle (including the sub-resource state array and physical layout pool pointer); traverses the local LRU cache tables of all threads, deletes the cache entry for the resource, and updates the cache version number; and calls the drm_vk_layout_resource_remove interface to notify the kernel to remove all unexecuted instructions for the resource from the kernel layout conversion queue, preventing the kernel from continuing to schedule destroyed resources.

[0194] S9.2, Vulkan physical resource reclamation and state reset.

[0195] Destroy all pre-created VkImageView objects (including the array of child resource views) in the physical layout pool by calling the vkDestroyImageView interface; unbind and release Vulkan image resources: call vkUnbindImageMemory to unbind memory, vkFreeMemory to release memory, and vkDestroyImage to destroy the image object; reset the synchronization objects (such as VkSemaphore and VkFence) associated with the resource to prevent synchronization object leakage.

[0196] S9.3 Cleanup of layout conversion remnants in the DiscardResource interface.

[0197] When a D3D12 resource is discarded (via the DiscardResource API call; the resource content does not need to be retained):

[0198] Parse the parameters of DiscardResource (such as DiscardSubresourceRanges) to determine the range of sub-resources that need to be discarded; clean up all pending conversion requests for this resource in the hierarchical delayed conversion queue, mark them as discarded, and do not need to be executed; call the drm_vk_layout_discard_notify interface to notify the kernel that the resource has been discarded, the kernel stops conflict detection and scheduling for this resource, and releases related trace data; reset the memory access counter of the VGL handle to 0, mark the resource status as discarded, and avoid subsequent misoperations.

[0199] S9.4, Cache cleanup of statically mapped resources (when VKD3D exits).

[0200] When VKD3D exits or is reinitialized: it cleans up static resources such as the GPU layout support table, GPU layout conversion rule table, and pre-compiled conversion path library to release memory space; it calls the drm_vk_layout_static_cache_clear interface to clean up the static mapping data stored in the kernel to avoid using old data during the next initialization.

[0201] This embodiment mainly involves the following technical terms:

[0202] VGL (Virtual General Layout), also known as abstract layout, is an abstract layout concept proposed in this invention to simulate the general adaptability of VK_IMAGE_LAYOUT_GENERAL in VK_KHR_unified_image_layouts. Eight types of VGL layouts (such as VGL_LAYOUT_RENDER_TARGET) are defined, each corresponding one-to-one with a D3D12 core state. These serve as an intermediate adaptation layer between the D3D12 state and the Vulkan physical layout, shielding the differences in the underlying layout and achieving a single semantic abstraction.

[0203] The D3D12 state and VGL to Vulkan layout mapping matrix is ​​the three-dimensional mapping structure established in this invention, with dimensions of D3D12 resource state, VGL abstract layout, and Vulkan physical layout, respectively. It is used to solidify the correspondence among the three and dynamically match the optimal physical layout (e.g., from D3D12's RENDER_TARGET to VGL's VGL_LAYOUT_RENDER_TARGET and then to Vulkan's COLOR_ATTACHMENT_OPTIMAL) using the GPU layout support table, ensuring mapping accuracy.

[0204] The hierarchical delayed conversion queue, proposed in this invention, divides the rendering pass into sub-queues. Each sub-pass is further divided into high-priority sub-queues (conversions that need to be completed first) and low-priority sub-queues (conversions that can be delayed). This is used to implement hierarchical scheduling of conversion requests, avoiding the mixing of conversions of different scenarios and priorities, and reducing invalid barriers.

[0205] The kernel layout transition queue, defined in the Linux kernel DRM subsystem of this invention, is used to receive VKD3D pre-committed Barrier instructions. The kernel detects GPU idle time windows and allocates instructions in the queue to idle periods for execution, avoiding the occupation of GPU time for rendering commands and reducing pipeline stalls.

[0206] The distributed state nodes (global primary replica and thread-local cache replica) are the multi-threaded state tracking structure proposed in this invention: the global primary replica stores the authoritative state of resources (atomic operation protection), and the thread-local cache replica maintains an LRU cache (storing the most recently accessed state) for each command record thread, which is used to reduce the competition of multiple threads for global resources, reduce the overhead of atomic operations, and improve the efficiency of state access.

[0207] The three-level verification and fast repair mechanism is the state conflict detection and repair scheme proposed in this invention. The first level of verification (comparing the cache and global version within the thread), the second level of verification (the kernel reads the GPU hardware status for confirmation), and the third level of verification (Vulkan driver legality verification) are used. When a conflict occurs, only the conflicting command fragment is regenerated (instead of rolling back the entire command queue). The repair time is no more than 100us, ensuring accurate status and efficient repair.

[0208] The three-tier degradation strategy (Level 1, Level 2, and Level 3 layouts) is the hardware adaptation strategy proposed in this invention: Level 1 is a Vulkan-specific layout (optimal performance, such as COLOR_ATTACHMENT_OPTIMAL); Level 2 is a vendor-extended layout (performance close to Level 1, such as VK_IMAGE_LAYOUT_AMD_SHADER_READ_ONLY); and Level 3 is VK_IMAGE_LAYOUT_GENERAL (most feature-rich but lowest performance). Degradation occurs sequentially based on GPU support, balancing compatibility and performance.

[0209] The three-dimensional performance compensation (shader, memory, scheduling) is the performance optimization scheme proposed in this invention after degradation: the shader layer optimizes SPIR-V instructions (such as replacing imageLoad with vendor-optimized instructions), the memory layer allocates high-bandwidth memory partitions and enables compression, and the scheduling layer extends the delay queue threshold to reduce the number of conversions. This three-dimensional collaborative compensation for the performance loss caused by degradation brings the performance of a Level 3 layout close to that of a Level 1 layout.

[0210] Experiments have verified that this invention achieves the goal of efficiently running VKD3D on GPUs that do not support VK_KHR_unified_image_layouts. Specific beneficial effects include:

[0211] Mapping accuracy and compatibility: Through a static mapping matrix and vendor adaptation table, it achieves a 1:1 accurate mapping from D3D12 states to Vulkan layouts, supports most mainstream GPUs (Intel HD 530, NVIDIA GTX 960, AMD RX 580, etc.), reduces the mapping error rate to below 0.05%, and covers 100% of D3D12 standard resource states (including advanced features such as Workgraphs and ray tracing).

[0212] Performance optimizations include: delayed scheduling and fine-grained batch merging reduce the number of Barrier instructions by over 45% (compared to 30% in traditional solutions); kernel idle time scheduling reduces GPU pipeline downtime by 40% and CPU command logging overhead by 35%; performance compensation strategies for degraded resources bring the performance of Level 3 layouts (GENERAL) close to that of Level 1 layouts (dedicated layouts), with a performance difference of no more than 5% (compared to no less than 20% in traditional solutions); and overall performance is close to that of GPUs supporting VK_KHR_unified_image_layouts, with a difference of no more than 6% (compared to no less than 15% in the original solutions).

[0213] State accuracy is ensured by a distributed lock-free tracking mechanism that reduces the multi-threaded state conflict rate to below 0.02% (compared to no less than 5% in traditional centralized solutions); a three-level verification and fast repair mechanism reduces the rendering error rate by 99%, and the conflict repair time is no more than 100us.

[0214] Resource and memory efficiency: The sleep activation mechanism of the physical layout pool reduces initial memory usage by 30%; the thread LRU cache table reduces the number of global primary copy accesses by 60%, reducing CPU atomic operation overhead; the resource destruction and cleanup mechanism avoids memory leaks, and memory usage is stable (without continuous growth).

[0215] Scalability: Static mapping libraries and pre-compiled path libraries support rapid adaptation to new D3D12 states (such as D3D12_RESOURCE_STATE_VIDEO_DECODE) and new Vulkan layouts (such as VK_IMAGE_LAYOUT_VIDEO_ENCODE_DST_OPTIMAL_KHR). Adding new mappings only requires updating the configuration table, without modifying the core code, reducing the adaptation cycle by 80%.

[0216] 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 Direct3D 12 resource management method based on a virtual universal layout, characterized in that, Specifically, the following steps are included: VKD3D is pre-executed to establish a virtual generic layout corresponding to the D3D12 resource state. The Vulkan physical layout is matched for the virtual generic layout. The mapping matrix formed by the correspondence between the D3D12 resource state, the virtual generic layout and the Vulkan physical layout is embedded in VKD3D. The Vulkan memory barrier instruction chain is pre-compiled to form a pre-compiled conversion path library. When starting VKD3D and D3D applications, VKD3D determines the number of sub-resources when creating D3D12 resources. The mapping matrix determines the initial virtual general layout, establishes the first resource handle, allocates a Vulkan physical layout pool for it, and creates a Vulkan image view for the physical layout in the pool according to the number of sub-resources. Vulkan memory blocks are allocated, and the Vulkan memory blocks are bound to the Vulkan image view with the physical layout as a parameter. The creation timestamp of the physical layout and the initial sub-resource status are added to the sub-resource status array and added to the first resource handle table. When setting the D3D12 resource status, the first resource handle is determined from the first resource handle table, and the current virtual general layout and sub-resource status array are obtained. The target virtual general layout corresponding to the target resource status is determined according to the parameters and mapping matrix passed by the application. If it is the same as the current virtual general layout and the status of the sub-resource range matches, the process ends. Otherwise, the current Vulkan physical layout and the target Vulkan physical layout are obtained from the Vulkan physical layout pool of the first resource handle. If they are the same, the current virtual general layout and the sub-resource status array are updated and the process ends. Otherwise, the conversion path is obtained from the pre-compiled conversion path library, the sub-resource range is recorded, and a resource conversion request is generated. VKD3D adds dependency tags to resource conversion requests, adds them to the rendering channel partition based on the dependency tags, and generates a merge candidate set by grouping the resource conversion requests when executing the command queue. The parameters of the merge candidate set are replaced with memory barrier parameters from the pre-compiled conversion path library and pre-submitted to the kernel. The kernel allocates non-conflicting conversion instructions to the GPU's idle time window for execution.

2. The Direct3D 12 resource management method according to claim 1, characterized in that, The number of sub-resources is determined by the number of extracted MIP levels and the number of array slices, and the unique identifier of a sub-resource is determined by the MIP level and the array slice.

3. The Direct3D 12 resource management method according to claim 1, characterized in that, The first resource handle contains a unique resource identifier, the current abstract layout, the bound Vulkan image view, a physical layout pool pointer, a state update timestamp, a sub-resource state array, and a memory access counter.

4. The Direct3D 12 resource management method according to claim 1, characterized in that, The method of adding resource conversion requests to the rendering pass partition based on dependency tags is as follows: Parse the first rendering command after the current resource barrier in the D3D12 command queue, record the access type of the resource to be transformed by the command, add a dependency flag that must be completed before the command to the resource transformation request if it is a write, and add a dependency flag that can be executed in parallel if it is a read. VKD3D creates a hierarchical deferred conversion queue consisting of rendering channel partitions. Each rendering channel partition contains a high-priority subqueue and a low-priority subqueue. Requests that must be completed before the command are added to the high-priority subqueue, while requests that can be executed in parallel are added to the low-priority subqueue.

5. The Direct3D 12 resource management method according to claim 1, characterized in that, After generating a resource conversion request, the resources that need to be physically converted are grouped according to the source physical layout, target physical layout, and conversion path. Within each group, the resources are sorted in descending order of the number of sub-resources, with those having more sub-resources being processed first. A scheduling priority is assigned to each group, with resources whose dependency on the next rendering command is greater than a threshold having high priority and resources with no direct dependency having low priority.

6. The Direct3D 12 resource management method according to claim 1, characterized in that, For requests for the same resource in the merge candidate set, merge overlapping or adjacent sub-resource ranges to generate a merged sub-resource range; for requests for different resources with the same format or layout in the merge candidate set, merge the image fields in the memory barrier of the image resource into an array, sharing the same pipeline stage mask and access mask; for requests in the merge candidate set that contain local transformations of sub-resources, specify the local range in the memory barrier.

7. The Direct3D 12 resource management method according to claim 6, characterized in that, The method of replacing the parameters of the merge candidate set with the memory barrier parameters in the pre-compiled transformation path library is as follows: load the pre-compiled memory barrier parameters from the pre-compiled transformation path library, and replace the image view and sub-resource range in them with the merged data; if the merge candidate set contains requests that can be executed in parallel, set a flag in the memory barrier to allow the GPU to execute the transformation in parallel according to the sub-resources.

8. The Direct3D 12 resource management method according to claim 1, characterized in that, For complex transformations that require intermediate layout, independent sub-paths are first separated from the pre-compiled transformation path library. Each sub-path is matched with an independent memory barrier instruction and marked with the estimated execution time. According to the sub-path type, it is assigned to the corresponding pipeline stage of the GPU. The time balance is adjusted according to the idle threshold of each pipeline stage. If the total time of a sub-path in a certain stage exceeds the threshold, some sub-paths are split to adjacent idle stages.

9. The Direct3D 12 resource management method according to claim 1, characterized in that, A distributed state node containing a global master copy and a thread-local LRU cache copy is created for each first resource handle. The global master copy stores the authoritative state of the resource and is protected by atomic operations. Each command record thread maintains an independent LRU cache table to store the state of the most recently accessed resource and uses the LRU strategy to clean up expired and low-version caches. When a thread modifies the resource status, it first checks the local cache. If the cache is found and the version is consistent with the global primary copy, it uses the resource directly. If the cache is not found or the version is inconsistent, the local cache is updated. The global primary copy is updated via atomic operations. If the operation fails, a step-by-step backoff retry is performed based on the number of conflicts, such as spinning, yielding the CPU, and going to sleep. If the number of retries exceeds the set number, the resource is marked as a high-conflict resource and batch merging is used to reduce conflicts. After the global primary copy is updated successfully, the local cache is refreshed synchronously.

10. The Direct3D 12 resource management method according to claim 1, characterized in that, When the lifecycle of a D3D12 resource ends, the resource reference count returns to 0, triggering destruction. The corresponding handle is deregistered from the first resource handle table, and the resource status data in all thread-local caches is cleared. The kernel is notified to delete all unexecuted instructions for the resource in the kernel layout transformation queue and terminate related scheduling. The underlying resource is reclaimed, the Vulkan image view in the physical layout pool is destroyed, and the Vulkan image memory and objects are unbound and released. When an application actively discards a resource, it parses the passed-in sub-resource range, cleans up all pending conversion requests for that resource in the hierarchical delayed conversion queue and marks them as not needing to be executed; it notifies the kernel to stop conflict detection and scheduling for that resource, releases the kernel-side trace data; it resets the memory access counter of the first resource handle and marks the resource as discarded; When VKD3D exits or is reinitialized, all static underlying resources that were built are cleaned up, and the kernel is notified to clean up static cache data synchronously.

Images