Shader cache optimization method based on semantic normalization and multi-dimensional dynamic adaptation

Abstract

This invention discloses a shader cache optimization method based on semantic normalization and multidimensional dynamic adaptation. When the GPU does not support the VK_EXT_shader_module_identifier extension, a heterogeneous three-level hierarchical cache pool is constructed. When the system is idle, the L3 cache is pre-searched and missing cache entries are pre-compiled. When the D3D application creates a shader, the shader bytecode is converted to SPIR-V, semantics are extracted, a control flow graph is constructed to generate a standard semantic intermediate representation, and compressed SPIR-V is obtained. The shader semantic fingerprint is calculated, and hardware, driver, and DXVK version hashes are concatenated to form a multidimensional identifier. When the D3D rendering pipeline is created, the three-level cache is searched sequentially using the multidimensional identifier. If a valid pipeline binary is hit, the physical page is reused to rebuild the Vulkan pipeline. If no hit is found, SPIR-V is decompressed and compiled back to the cache pool, completing the conversion of the D3D pipeline to the Vulkan pipeline.

Description

Technical Field

[0001] This invention belongs to the field of computer software development technology, specifically relating to a shader cache optimization method based on semantic normalization and multi-dimensional dynamic adaptation. Background Technology

[0002] DXVK, as the core project of the open-source graphics API conversion layer, is primarily responsible for converting the shader bytecode (DXBC or DXSO) of Direct3D (D3D9-11) into the Vulkan-compatible SPIR-V format. It then uses the Vulkan API to create the rendering pipeline, enabling the running of Windows-based 3D applications on Linux systems. The VK_EXT_shader_module_identifier extension is crucial for DXVK's high-performance operation. This extension allows the Vulkan driver to generate a globally unique identifier (Identifier) ​​for each SPIR-V module. When creating the rendering pipeline later, it eliminates the need to repeatedly transmit the complete SPIR-V binary data; only this identifier needs to be passed to reuse the already compiled pipeline object within the driver. This significantly reduces CPU and GPU data transfer overhead, shader compilation time, and memory usage.

[0003] However, when the GPU or its driver does not support the VK_EXT_shader_module_identifier extension, existing alternative simulation solutions suffer from the following intractable technical problems: First, SPIR-V fingerprint consistency is lacking. User-space hash calculations based on SPIR-V binary are easily affected by factors such as debugging information, memory alignment bytes, and differences in compilation options, resulting in shaders with the same semantics generating different fingerprints and low cache hit rates. Second, the cache invalidation mechanism is rigid. Relying on version markers maintained in DXVK user space, such as driver version and DXVK version, to trigger cache invalidation fails to detect dynamic scenarios such as changes in GPU hardware status and hot driver updates, easily leading to pipeline compatibility errors. Third, pipeline creation overhead remains high, requiring the complete SPIR-V module creation and pipeline creation process to be repeatedly executed. The SPIR-V data transmission, driver syntax parsing and verification account for a significant proportion of the total pipeline creation time; fourth, cache resource management is inefficient, with user-mode cache using a single storage level, which cannot adapt to shaders with different access frequencies. High-frequency shaders are not loaded first, while low-frequency shaders consume a large amount of memory, resulting in large fluctuations in cache access latency; fifth, cross-scenario reuse capability is insufficient, with caches in different application processes and virtualization environments being isolated from each other, requiring the same shaders to be compiled repeatedly, doubling disk usage and total compilation time; sixth, cache synchronization after shader updates is lacking, after application shader files are updated, only the old cache is invalidated, failing to achieve association and reuse between the new shader and the old cache, resulting in complete recompilation; seventh, cache access permission control is lacking, when sharing cache across processes, read and write permissions are not distinguished, which easily leads to the security risk of malicious processes tampering with cache data.

[0004] In summary, existing simulation solutions lack in-depth understanding of the semantic essence of SPIR-V, system-level caching coordination, and event-driven dynamic adaptation capabilities, resulting in a significant performance gap between the simulation effects and the native VK_EXT_shader_module_identifier extension, making it difficult to meet the high-performance requirements of 3D applications and real-time rendering. Summary of the Invention

[0005] In view of this, the present invention provides a shader cache optimization method based on semantic normalization and multi-dimensional dynamic adaptation. When the GPU does not support the VK_EXT_shader_module_identifier extension, it constructs a heterogeneous three-level cache pool, combines offline pre-compiled high-frequency pipeline fragments, shader semantic normalization to generate standard semantic intermediate representations and compressed SPIR-V, concatenates multi-dimensional identifiers based on semantic fingerprints and hardware driver version hashes and persists them, and uses the identifier to retrieve the three-level cache during runtime pipeline creation to achieve zero-copy reuse for hits and compilation writeback for misses. This achieves the technical effects of improving cache hit rate, converting runtime shader compilation overhead into background idle tasks, dynamic adaptation and accurate cache invalidation based on hardware driver version dimension, reducing CPU and GPU resource consumption, and improving the smoothness of D3D application startup and operation.

[0006] The shader cache optimization method based on semantic normalization and multi-dimensional dynamic adaptation provided by this invention specifically includes the following steps:

[0007] When the GPU does not support the VK_EXT_shader_module_identifier extension, a heterogeneous three-level hierarchical cache pool is constructed, including an in-process high-speed cache L1, a cross-process shared memory cache L2, and a persistent disk cache L3. Before the installed D3D application is started or when the system is idle after the Vulkan graphics driver is updated, each D3D application is divided into popular applications, recently run applications, and unrun applications based on historical running logs. For the D3D applications that have been run, their exclusive high-frequency pipeline fragment templates are mined, and for the D3D applications that have not been run, a general high-frequency pipeline fragment template is used. L3 is searched in the order of popular applications, recently run applications, and unrun applications. For entries that do not exist in the cache, pre-compilation is performed and the compiled products are stored in L3.

[0008] When a D3D application creates a shader, the shader bytecode is converted into SPIR-V binary. The binary is parsed using a dual-mode approach of instruction flow traversal and CFG analysis. Core semantic information is extracted according to the segment structure, and a control flow graph is constructed. A standard semantic intermediate representation is generated and standardized. Dead code is eliminated and compressed to obtain compressed SPIR-V.

[0009] Based on the standard semantic intermediate representation, the shader semantic fingerprint is calculated. The shader semantic fingerprint, GPU hardware context hash, driver metadata hash and DXVK semantic version hash are concatenated into a multidimensional identifier to realize the binding of hardware, driver, DXVK semantic version and shader semantics. The multidimensional identifier and compressed SPIR-V are persistently stored in the L3 index area and data area respectively.

[0010] When a D3D application creates a D3D rendering pipeline, it sequentially searches the L1, L2, and L3 caches using the multidimensional identifier corresponding to the shader bound to the pipeline as the primary key. If a matching valid pipeline binary exists, the pipeline binary is read into the current process memory, and physical page reuse is achieved through shared memory to rebuild the Vulkan pipeline object. If it does not exist, it reads the compressed SPIR-V decompressed data from L3, calls the Vulkan driver interface in user space to complete the pipeline compilation, and writes the compiled artifacts back to the three-level cache pool, thus completing the creation of the D3D rendering pipeline into the Vulkan rendering pipeline.

[0011] Furthermore, the upgrade flow of cached data from L2 to L1 requires that the cached data be accessed frequently multiple times or that the time taken for a single access exceeds a threshold. The upgrade flow from L3 to L2 requires that the cumulative access of the cached data reach a set number of times or hit the application's preload list. During the downgrade flow, the downgraded cached data is recompressed and optimized. After the L3 is updated, the L2 and L1 are notified of the update level by level through the reverse synchronization mechanism.

[0012] Furthermore, the GPU hardware context hash is calculated by collecting inherent GPU information and dynamic runtime status, the driver metadata hash is calculated by collecting static driver version and dynamic compilation level, and the DXVK semantic version hash is calculated for the core logic version of DXVK that is only related to shader processing.

[0013] Furthermore, when a new shader enters the compilation process, a semantic feature vector is constructed, including low-level features of instruction sequence statistics and resource binding type distribution, mid-level features of control flow graph structure and input / output layout dimensions, and high-level features of shader functional semantic identifiers. In the cache, candidate shaders are first excluded based on the Euclidean distance of the low-level features, then the cosine similarity of the mid-level features is calculated, and finally the Jaccard similarity of the high-level features is calculated. Candidate shaders with a comprehensive similarity greater than a set threshold are selected. If a matching candidate shader exists, differences are extracted according to semantic unit classification and comparison to generate a difference tree. An incremental compilation instruction set is generated according to the difference type and incremental compilation is performed. The compilation product is written to the cache pool, and a reuse index is established. If no matching candidate shader exists, a full compilation is triggered. When a candidate cache item becomes invalid due to driver update or semantic change, all associated target shaders are notified through the reuse index. When the target shader is accessed again, the similarity is recalculated. If it still meets the set threshold, incremental compilation is performed based on the new candidate. If it is lower than the set threshold, a full compilation is triggered.

[0014] Furthermore, when the D3D application starts, DXVK scans the shader files in the application's installation directory, calculates the file checksum, and compares it with the checksum stored from the last run. If the checksums do not match, semantic normalization is performed on the updated shader to generate a standard semantic intermediate representation and a temporary multidimensional identifier. Semantic similarity is used to match the source cache item before the update. If a match is successful, the semantic differences between the updated shader and the source cache item are extracted to generate an incremental compilation instruction set. Incremental compilation is performed based on the compiled pipeline binary of the source cache item to generate the compilation artifact of the updated shader, establishes the update association, and marks the source cache item as a historical version. If no source cache item is matched, a full compilation is performed.

[0015] Furthermore, when multiple shaders are updated simultaneously, batch difference extraction is used to group them by difference type. Half the number of background compilation threads are started to process the incremental compilation tasks of different groups in parallel, and a shader update report is generated to record the number of updates, the number of reused source cache items, the incremental compilation time and storage space saved, and stored in the shader update log.

[0016] Furthermore, state detection is performed during program startup, frame idle intervals, and after GPU device reset and recovery to identify hardware events, driver events, or system events. Hardware failure events are handled first, driver configuration updates are handled with medium priority, and system kernel updates are delayed until after application exit. Hardware events evict cache entries bound to the old hardware state based on changes in hardware context hashes. If a driver event only modifies the compilation logic of a specific shader stage, only cache entries for that stage are evicted. In system events involving Vulkan runtime library updates, only cache entries using incompatible API features are evicted. When an event is detected, the invalid cache entry is marked as invalid without immediately clearing the data. Storage resources are cleared and released in batches by a background thread when the application exits, the system is idle, or the cache capacity is insufficient. At the same time, a cache invalidation notification carrying a summary of the list of invalid multidimensional identifiers is sent to all running DXVK processes. After receiving the notification, the corresponding cache entry is cleared locally. When invalid cache entries are restored, they are sorted by priority, with high-frequency access items and items currently used by the application being restored first, while low-frequency items are restored later or as needed.

[0017] Furthermore, in cross-scenario reuse scenarios, three levels of access permissions are defined: read permission, read-write permission, and management permission. When a process starts, permissions are assigned based on the process owner and process signature. Ordinary user application processes are assigned read permissions by default, trusted application processes are assigned read-write permissions, and only the root process is assigned management permissions. When processing cache access requests, process permissions are verified first. If permissions are insufficient, the request is rejected and a security log is recorded. When invalid accesses are detected for a number of times not less than a set threshold within a set time, the process is added to the cache access blacklist and saved for a set time. For write operations that modify cached data, the process ID, operation time, and a summary of the data before modification are recorded.

[0018] Furthermore, in a virtualization environment, each virtual machine is allocated an independent L2 cache partition, and the L3 cache is partitioned according to the virtual machine ID and GPU passthrough identifier. Cache sharing between virtual machines is prohibited by default. In the virtual machine GPU passthrough scenario, the physical GPU registers are read directly to obtain the real hardware information.

[0019] Furthermore, in a containerized environment, containers on the same host need to be configured and have cache sharing permissions enabled to share the L2 cache, and a memory isolation mapping mechanism is used to ensure that each container can only access cache items within its own permission scope; the L3 cache shares the same partition, and the owner of each cache item is distinguished by the container ID.

[0020] Beneficial effects:

[0021] This invention constructs a heterogeneous three-level cache pool, where cached data dynamically flows between the three levels based on access frequency and adaptively adjusts capacity and background tasks according to system load. Before installed D3D applications are started or when the system is idle after a Vulkan graphics driver update, applications are categorized into popular applications, recently run applications, and inactive applications based on historical runtime logs. For applications with shader access logs, their specific high-frequency pipeline fragment templates are mined; for inactive applications, general high-frequency pipeline fragment templates are used. The L3 cache is searched according to priority, and non-existent entries are pre-compiled and the compiled artifacts are stored in L3. When a D3D application creates a shader, DXVK converts the shader bytecode to SPIR-V binary, extracts five types of core semantic information, constructs a control flow graph, generates and standardizes the semantic intermediate representation, and eliminates dead code. The compressed SPIR-V is then obtained. Subsequently, the shader semantic fingerprint is calculated based on the standard semantic intermediate representation. Combined with the hardware context hash, driver metadata hash, and DXVK semantic version hash collected by the kernel, it is concatenated into a multidimensional identifier to realize the binding of hardware, driver, version, and shader semantics. The identifier and the compressed SPIR-V are persistently stored in the index area and data area of ​​L3, respectively. When the D3D application creates the rendering pipeline, DXVK intercepts the call and searches the L1, L2, and L3 caches in sequence with the multidimensional identifier of the bound shader as the primary key. If a matching valid pipeline binary exists, it is directly mapped to the current process address space to reconstruct the Vulkan pipeline object through zero copy. If it does not exist, the compressed SPIR-V is retrieved from L3, decompressed, and submitted to the kernel-mode compiler to execute pipeline compilation. The compilation product is then written back to the L3 cache pool. The above methods significantly improve cache hit rate by utilizing offline pre-compilation and three-level cache layered reuse, transforming runtime shader compilation overhead into background idle tasks and effectively reducing pipeline compilation stuttering during D3D application startup and scene switching. On the other hand, semantic normalization eliminates the impact of differences in shader syntax on cache matching, and combined with multidimensional identifiers, it achieves dynamic adaptation across hardware, driver, and version dimensions. Changes in any dimension only cause the affected cache items to be precisely invalidated rather than being completely cleared. While ensuring cross-environment compatibility, it maximizes the retention of reusable cache data, ultimately achieving the technical effects of reduced shader compilation latency, reduced CPU and GPU resource consumption, and improved application smoothness. Attached Figure Description

[0022] Figure 1 This is a flowchart illustrating the shader cache optimization method based on semantic normalization and multi-dimensional dynamic adaptation provided by the present invention. Detailed Implementation

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

[0024] The shader cache optimization method based on semantic normalization and multi-dimensional dynamic adaptation provided by this invention has the following core idea: When the GPU does not support the VK_EXT_shader_module_identifier extension, a heterogeneous three-level cache pool is constructed. Cache data dynamically flows between the three levels according to the access frequency and adaptively adjusts the capacity and background tasks according to the system load. Before the installed D3D application is started or when the system is idle after a Vulkan graphics driver update, the application is divided into popular applications, recently run applications, and unrunned applications based on historical running logs. For applications with shader access logs, their exclusive high-frequency pipeline fragment templates are mined; for unrunned applications, general high-frequency pipeline fragment templates are used. The L3 cache is searched according to priority order. For non-existent entries, pre-compilation is performed, and the compiled products are stored in L3. When the D3D application creates a shader, DXVK converts the shader bytecode into SPIR-V binary. Five types of core semantic information are extracted and a control flow graph is constructed. A semantic intermediate representation is generated and standardized, while dead code is eliminated and compressed to obtain compressed SPIR-V. Subsequently, the shader semantic fingerprint is calculated based on the standard semantic intermediate representation. Combined with the hardware context hash, driver metadata hash, and DXVK semantic version hash collected by the kernel, a multi-dimensional identifier is constructed to achieve the binding of hardware, driver, version, and shader semantics. The identifier and compressed SPIR-V are persistently stored in the index area and data area of ​​L3, respectively. When the D3D application creates the rendering pipeline, DXVK intercepts the call and searches the L1, L2, and L3 caches in sequence with the multi-dimensional identifier of the bound shader as the primary key. If a matching valid pipeline binary exists, it is directly mapped to the current process address space to reconstruct the Vulkan pipeline object through zero copy. If it does not exist, the compressed SPIR-V is retrieved from L3, decompressed, and submitted to the kernel-mode compiler to execute pipeline compilation. The compilation product is then written back to the L3 cache pool.

[0025] The shader cache optimization method based on semantic normalization and multi-dimensional dynamic adaptation provided by this invention has the following processing flow: Figure 1 As shown, the specific steps include:

[0026] Step 1: When the GPU does not support the VK_EXT_shader_module_identifier extension, construct a heterogeneous three-level cache pool including an in-process high-speed cache L1, which adopts an LRU eviction policy and can prefetch high-frequency items to the CPU core cache; a cross-process shared memory cache L2, which achieves concurrent access for multi-process read-write separation through set-associative mapping and pseudo-LRU, and ensures cross-process data consistency through a cache consistency protocol; and a persistent disk cache L3, which is partitioned according to hardware, driver, and application dimensions, with separate index and data areas, multiple replicas of data blocks for fault tolerance, and caches of applications with access frequency greater than a threshold are retained for a long time; cached data in the three-level cache pool dynamically flows between the three-level caches according to its access frequency, and the cache capacity and background tasks of each level are dynamically adjusted according to memory usage, SSD remaining space, and CPU load. During high load, migration is paused and only read operations are retained.

[0027] Furthermore, the upgrade flow of cached data from L2 to L1 requires that the cached data be accessed frequently multiple times or that the time taken for a single access exceeds a threshold. The upgrade flow from L3 to L2 requires that the cumulative access of the cached data reach a set number of times or hit the application's preload list. During the degradation flow, the degradation cached data is compressed at the highest level to reduce disk usage. After the L3 is updated, the L2 and L1 are notified to update level by level through the reverse synchronization mechanism. When reading a cached item, a checksum verification is performed first. If it fails, the next level is tried to recover. If all levels fail, it is marked as corrupted and reconstruction is triggered.

[0028] Step 2: Before the installed D3D applications are started and after the Vulkan graphics driver is updated, when the system is idle, obtain the usage count and frequency of each D3D application based on historical running logs, and categorize the D3D applications into popular applications, recently run applications, and unrun applications. For D3D applications with shader access logs, mine their specific high-frequency pipeline fragment templates; for unrunn D3D applications, use general high-frequency pipeline fragment templates. According to the priority order of popular applications, recently run applications, and unrunn applications, retrieve the high-frequency pipeline fragment templates corresponding to each D3D application in turn, and search the L3 persistent cache of the heterogeneous three-level cache pool. If the corresponding entry does not exist in the cache, perform pre-compilation to obtain the corresponding kernel-mode shader module handle, pipeline state object, driver native format compiled binary, dependency resource list, and CRC64 checksum, and store it in the L3 cache pool. If the corresponding entry already exists in the cache, skip this pre-compilation.

[0029] Furthermore, this invention employs frequent itemset mining algorithms such as FP-Growth, Apriori, Eclat, or H-Mine to mine high-frequency pipeline segment templates based on the application shader access log.

[0030] Among them, the high-frequency pipeline fragment template is divided into fixed-state fragments and variable-state fragments according to function. Fixed-state fragments, such as vertex input layout and rendering target format, are pre-compiled and permanently cached, while variable-state fragments, such as blend mode and depth offset, are pre-compiled by combination.

[0031] The generic high-frequency pipeline fragment template is derived from pre-analyzing the runtime logs of numerous different D3D applications to identify pipeline state combinations that are common across applications and occur frequently. For D3D applications that have never been run on the system, there are no shader access logs specific to those applications, making it impossible to discover application-specific high-frequency pipeline fragment templates. Therefore, this generic high-frequency pipeline fragment template is selected as the pre-compilation object. This template contains highly generic pipeline fragment combinations such as vertex input layout, render target format, depth stencil state, and blend state. It does not rely on the historical runtime data of the application on the local machine and can be pre-compiled before the application's first launch, pre-covering common pipeline scenarios for this type of application and reducing the risk of real-time compilation stuttering after application startup.

[0032] Furthermore, pre-compilation adopts a performance-priority optimization level, and fast compilation for runtime cache misses only enables core optimizations and automatically upgrades and recompiles when the system is idle; pipeline fragments support reuse by combination query; fragment dependencies are checked before complex pipeline splicing, missing fragments are automatically loaded or compiled on the spot, and a link cache is generated after linking for subsequent reuse; when driver updates cause fragment version incompatibility, fragment adaptation compilation is triggered according to the compatibility matrix.

[0033] Step 3: When a D3D application creates a shader, DXVK converts the created shader bytecode into SPIR-V binary. This binary is then parsed using a dual-mode approach of instruction flow traversal and CFG analysis. Five core semantic information categories—basic attributes, inputs / outputs, resource bindings, instruction logic, and constant data—are extracted according to the segment structure. A control flow graph is constructed, and control flow dependencies are extracted to generate a semantic intermediate representation. This intermediate representation is then standardized to generate a standard semantic intermediate representation. Simultaneously, based on the control flow graph, dead code in the SPIR-V binary is eliminated, and compressed SPIR-V is obtained through compression optimization.

[0034] The segment structure of SPIR-V binary includes a header segment, a type segment, a constant segment, an instruction segment, and a debug segment.

[0035] Step 4: Calculate the shader semantic fingerprint based on the standard semantic intermediate representation. The kernel module collects GPU intrinsic information and dynamic runtime status to calculate the GPU hardware context hash, collects the driver static version and dynamic compilation level to calculate the driver metadata hash, and calculates the DXVK semantic version hash for the core logic version of DXVK that is only related to shader processing. The shader semantic fingerprint, GPU hardware context hash, driver metadata hash, and DXVK semantic version hash are concatenated into a multidimensional identifier with a fixed bit width to bind hardware, driver, DXVK semantic version, and shader semantics. A change in any dimension will automatically trigger cache invalidation. The multidimensional identifier is associated with the compressed SPIR-V storage path, semantic intermediate representation, access statistics, etc., as metadata. The multidimensional identifier and compressed SPIR-V are persistently stored in the L3 index area and data area, respectively. The multidimensional identifier serves as an index pointing to the storage location of the compressed SPIR-V.

[0036] Furthermore, when the semantics are slightly modified, incremental updates are achieved by superimposing the offset mask with the difference bit marker, without having to recalculate the complete hash; multidimensional identifiers are conflict detected by the kernel-mode dual index table, and when a conflict exists, a conflict sequence number is appended to the least significant bit to ensure uniqueness.

[0037] Step 5: When the D3D application creates the D3D rendering pipeline, DXVK intercepts the interface call to trigger runtime rendering pipeline creation. The pipeline proxy module extracts the multidimensional identifier corresponding to the shader bound to the current pipeline and uses this identifier as the primary key to search the heterogeneous three-level cache pool. It sequentially searches the L1 hash table, L2 kernel memory cache, and L3 disk persistent cache. If a valid matching pipeline binary exists in the three-level cache pool, the compiled binary in the cache is directly mapped to the current process address space using a zero-copy method. The Vulkan pipeline object is reconstructed based on this binary without recompiling the shader. If no valid matching pipeline binary exists in the three-level cache pool, the compressed SPIR-V binary corresponding to the shader is retrieved from the L3 cache, decompressed, and submitted to the Vulkan driver kernel-mode compiler to execute pipeline compilation and generate the Vulkan pipeline object. After compilation, the generated kernel-mode shader module handle, pipeline state object, driver native format compiled binary, dependency resource list, and CRC64 checksum are written back to the heterogeneous three-level cache pool.

[0038] Furthermore, when a new shader enters the compilation process, a multi-layer feature extraction strategy is first used to construct a semantic feature vector. The bottom layer features are instruction sequence statistics and resource binding type distribution; the middle layer features are control flow graph structure and input / output layout dimensions; and the high layer features are shader functional semantic identifiers. The features of each layer are normalized and then weighted and fused to generate a semantic feature vector. Then, a hierarchical screening strategy is used to retrieve candidate shaders from the cache. First, obviously dissimilar candidates are quickly eliminated by Euclidean distance of the bottom layer features. Then, the cosine similarity of the middle layer features is calculated. Finally, the Jaccard similarity of the high layer features is calculated. Finally, candidates with a comprehensive similarity greater than a threshold are selected. When the number of candidates is not less than the upper limit threshold, the feature vector is transmitted to the GPU for parallel computation accelerated by the OpenCL kernel. If a matching candidate shader is found, it is processed according to variables, instructions, and resource bindings. Semantic units such as control flow are classified and compared to extract differences and generate a difference tree. Incremental compilation instruction sets are generated according to the difference type, such as variable redefinition, instruction replacement, insertion and deletion, binding slot remapping, and branch condition modification. After the compatibility of the compilation products with the candidate compilation products is verified by the compatibility checker, incremental compilation is performed. After the compilation products pass the compatibility test of key rendering test cases, they are written to the three-level cache pool. At the same time, the multidimensional identifier, similarity value and difference tree summary of the reuse candidate shader are recorded in the metadata and a reuse index is established. If no matching candidate is found, a full compilation is triggered. When a candidate cache item becomes invalid due to driver update or semantic change, all related target shaders are notified through the reuse index. When the target shader accesses the target shader again, the similarity is recalculated. If it still meets the threshold, incremental compilation is performed based on the new candidate. If it is lower than the threshold, a full compilation is triggered.

[0039] Furthermore, when the D3D application starts, DXVK scans the shader files in the application's installation directory, calculates the file's SHA-256 checksum, and compares it with the checksum stored from the last run. Incremental update detection is achieved by filtering through file modification timestamps. If the checksum is inconsistent, it is determined that the shader has been updated. Then, semantic normalization is performed on the updated shader to generate a standard semantic intermediate representation and a temporary multidimensional identifier. Semantic similarity is calculated to match the source cache item before the update from the metadata storage. If the match is successful, the semantic differences between the updated shader and the source cache item are extracted to generate an incremental compilation instruction set. Incremental compilation is performed based on the compiled pipeline binary of the source cache item to generate the compilation artifact of the updated shader. The updated source multidimensional identifier is recorded in the metadata of the new multidimensional identifier to establish an update association, and the source cache item is marked as a historical version so that it can be quickly rolled back when compatibility issues occur with the new cache item. If no source cache item is matched, a full compilation is performed. Furthermore, when multiple shaders are updated simultaneously, batch difference extraction is used to group them by difference type. Half the number of background compilation threads are started to process the incremental compilation tasks of different groups in parallel, and a shader update report is generated to record the number of updates, the number of reused source cache items, the incremental compilation time and storage space saved, and stored in the update log.

[0040] Furthermore, when hardware events, driver events, or system events occur, the cache invalidation callback function is filtered by event handling and only processes critical events related to cache compatibility. These events are then scheduled according to priority: hardware failure events are processed in real-time, driver configuration updates are of medium priority, and system kernel updates are delayed until after application exit. Hardware events, based on changes in hardware context hashes, only evict cache entries bound to the old hardware state. Driver events, if only modifying the compilation logic of a specific shader stage, only evict cache entries for that stage. In system events, Vulkan runtime library updates, based on a version compatibility matrix, only evict cache entries using incompatible API features. When an event is triggered, the invalidated cache entry is only marked as invalid without immediate data cleanup. Data is batch cleaned up and released by a background thread when the application exits, the system is idle, or the cache capacity is insufficient. Simultaneously, all running DXVK instances are not notified. The process sends a cache expiration notification carrying a digest of the list of expiration multidimensional identifiers. Upon receiving the notification, the process quickly compares the digest with the local L1 cache and clears the corresponding entries. When restoring expired cache entries, they are sorted by priority. High-frequency access items and items currently being used in the application scenario are restored first, while low-frequency items are restored later or on demand. The restoration compilation reuses the standard semantic intermediate representation and preprocessing results of the original cached items, skipping the semantic normalization and preprocessing steps. If the restoration compilation fails, the semantic adaptation conversion is automatically performed to convert the old intermediate representation to a version compatible with the new driver before recompiling.

[0041] Furthermore, in cross-process cache sharing, virtualization environments, and remote cache sharing scenarios, cross-process cache sharing permission control is first implemented, defining three levels of access permissions: read permission, read-write permission, and management permission. Permissions are assigned based on the process owner and process signature upon process startup. Ordinary user application processes have default read permissions, trusted application processes are assigned read-write permissions, and only the root process is assigned management permissions. The kernel cache lock manager verifies process permissions when processing cache access requests; if permissions are insufficient, the request is rejected and a security log is recorded. When frequent invalid accesses, such as unauthorized write requests exceeding a set threshold within a set time period, are detected, the process is added to the cache access blacklist and saved for a set time. Write operations that modify cache data record the process ID, operation time, and a digest of the data before modification, supporting tamper traceability. In a virtualization environment, each virtual machine in a fully virtualized environment is allocated an independent L2 cache partition, and L3 is partitioned according to the virtual machine ID and GPU passthrough identifier, prohibiting cross-virtual machine sharing by default. In a containerized environment, containers on the same host can share L2 cache and L3 cache after being configured to enable cache sharing permissions, with the container ID distinguishing the cache item owner. In virtual machine GPU passthrough scenarios, the kernel directly accesses the physical cache. GPU registers obtain real hardware information to avoid distortion of virtualization layer information. Container-shared L2 uses memory isolation mapping to ensure that each container can only access cached items within its access scope. A dynamic adaptive preloading strategy based on an LSTM time-series prediction model is adopted, introducing the current application scenario type and user behavior patterns as input to improve prediction accuracy to above a threshold. The model uses incremental training data added weekly using shader access logs to adapt to the access patterns after application updates. Preloaded data prioritizes the use of idle memory bandwidth to avoid competing with rendering for resources and is paused in high-load scenarios where the application frame rate is not higher than a set value. If a preloaded cached item is not accessed for a set period of time, its validity with the current hardware driver status is automatically re-verified. During cross-process hot updates, the transmitted cached data is accompanied by a digital signature based on the DXVK official key and is transmitted using AES-128 encryption. The key is negotiated through an inter-process secure channel. The remote cache server stores L3 cached items of popular applications and includes a hardware driver compatibility list. When users download, they only obtain cached items compatible with their own environment. After downloading, the integrity is ensured by dual verification of the server's digital signature and local CRC64. Incremental synchronization of only locally missing or updated cached items is supported to reduce network transmission volume.

[0042] Example:

[0043] This embodiment employs the shader cache optimization method based on semantic normalization and multi-dimensional dynamic adaptation provided by this invention. By targeting the Direct3D to Vulkan translation layer DXVK, when the GPU does not support the VK_EXT_shader_module_identifier extension, it achieves high-performance simulation of this feature through innovative mechanisms such as semantic normalization, hierarchical caching, and event-driven mechanisms. This method is suitable for game rendering, professional graphics processing, and other scenarios on the Linux platform. The specific implementation process includes:

[0044] S1, SPIR-V semantic normalization and preprocessing optimization, strips away non-core semantic information from the SPIR-V binary, generates a standardized semantic intermediate representation, and reduces subsequent compilation and transmission overhead through preprocessing optimization.

[0045] S1.1, SPIR-V module parsing and semantic extraction.

[0046] After converting Direct3D shader bytecode such as DXBC and DXSO into SPIR-V binary code, DXVK starts the SPIRV_SemanticParser module built in this embodiment. It employs a dual-mode parsing approach: instruction flow traversal and control flow graph analysis. Specifically, instruction flow traversal involves sequentially traversing the SPIR-V binary segment structure, such as header segment, type segment, constant segment, instruction segment, and debug segment, extracting the core data of each segment, and ignoring non-functional information in the debug segment, such as variable name strings, file paths, and line number mapping tables. CFG analysis involves constructing the shader's control flow graph, identifying the main function entry point, branch nodes, and loop structures, extracting control flow dependencies, and ensuring semantic clarity. Extract the completeness of the execution logic; extract the core semantic information list, including basic attributes, inputs and outputs, resource bindings, instruction logic, and constant data. Among them, basic attributes include shader stage, shader model version, and global configuration of precision qualifiers. Shader stages include vertices, fragments, geometry, tessellation, and computation. Inputs and outputs include variable names, data types, layout modifiers, and interpolation modes. Resource bindings include resource types, binding slots, descriptor set indexes, and memory access modes. Resource types include samplers, textures, UBOs, SSBOs, and stored images. Instruction logic includes arithmetic instructions, logical instructions, control flow instructions, operands and dependencies of built-in functions. Constant data includes the values ​​and types of global constants and specialization constants, excluding default constants automatically filled at compile time.

[0047] Based on this, a semantic intermediate representation SPIRV_SemanticIR is generated, serialized using protobuf format, and a strict field structure is defined to ensure cross-platform and cross-version compatibility. The field structure is shown in the table below.

[0048] Table 1. Field Structure Table for Semantic Intermediate Representation

[0049] S1.2, SPIR-V semantic standardization processing.

[0050] All user-defined variables are renamed based on type-index rules to standardize variable naming. For example, the original variable name diffuseTex, whose type is sampler2D, is standardized to sampler2D_0; the original variable name modelMatrix, whose type is mat4, is standardized to mat4_1; built-in variables such as gl_Position and gl_FragColor retain their original names to avoid semantic conflicts.

[0051] Instruction order normalization involves sorting arithmetic instructions without data dependencies by operator priority and instruction length, with operator priority decreasing in the order of multiplication and division, addition and subtraction, and logical operations, and instruction length starting with the shortest instruction; for independent instructions within a loop, the original execution order is maintained to avoid disrupting the loop logic; for function call instructions, they are sorted according to the order of function definitions, and the parameter list is sorted lexicographically by type.

[0052] Resource binding slots are remapped, sorted by resource type priority, i.e., UBO, SSBO, texture, sampler, and stored image have decreasing priority in that order, and within the same type, they are arranged in ascending order of the original binding slots; after remapping, a new binding slot table is generated and stored in the extended field Standardized_SemanticIR in this embodiment, so that it can be mapped back to the original slots when subsequent pipelines are created.

[0053] The precision qualifier is unified, and the maximum precision capability supported by the GPU hardware is read, such as by obtaining it through the kernel vk_hw_context_collector module added in this embodiment; medium and low precision instructions are uniformly promoted to the maximum precision supported by the hardware. If the hardware supports high precision, the original precision is retained. If the hardware only supports medium and low precision, the precision conversion log is recorded in Standardized_SemanticIR for adaptation during subsequent compilation.

[0054] Standardized_SemanticIR is generated after standardization, ensuring that the semantic intermediate representation of shaders with the same functionality is completely consistent regardless of the original compilation options and debugging information.

[0055] S1.3, SPIR-V binary compression and optimization.

[0056] Dead code elimination optimization is performed based on reachability analysis of the control flow graph: all instructions and variables reachable from the main function entry point are marked, and unmarked items are judged as dead code; unreferenced global constants, empty instructions, and duplicate resource binding declarations are removed; for conditional judgment instructions that are always true or always false, branches are directly expanded or removed.

[0057] Binary compression optimization employs the LZ4HC high compression ratio algorithm. To address the opcode repetition of SPIR-V instructions, a dedicated dictionary is constructed, including binary templates containing the first 1000 high-frequency instructions. The SPIR-V binary is first divided into 4KB blocks, then high-frequency instructions are replaced using dictionary encoding, and finally LZ4HC compression is performed. The optimized SPIR-V binary, Optimized_SPIRV_Binary and Standardized_SemanticIR, is output, proceeding to the next step of identifier generation.

[0058] S2, the multidimensional identifier GUID generation mechanism, aims to generate identifiers that are unique, consistent, and dynamically adaptable. It can perceive changes in multiple dimensions such as hardware, drivers, DXVK, and shader semantics, providing a foundation for cache reuse and automatic invalidation.

[0059] S2.1, Basic Dimension Hash Calculation.

[0060] Dimension 1: Semantic Fingerprint Hash. Perform SHA-3-256 hash calculation on the protobuf serialized data of Standardized_SemanticIR. During the calculation, the default fields of protobuf, such as optional fields that are not set, are excluded. Only the valid data segments are hashed to obtain a 256-bit Semantic_Fingerprint.

[0061] Dimension 2: Hardware Context Hash. The kernel vk_hw_context_collector module built in this embodiment obtains and hashes hardware information in the following ways: For intrinsic information, it reads the device ID, GPU model, memory capacity register, and core count register from the PCIe configuration space, converts them to strings, and then concatenates them; for dynamic status, it reads the current operating frequency and temperature threshold of the GPU core, concatenates them in the format of frequency_temperature; and uses the XXH3_128 hash algorithm to generate a 128-bit HW_Context_Hash, updating the dynamic status portion every 10 seconds.

[0062] Dimension 3: Driver Metadata Hash. The vk_hw_context_collector module reads the following driver information, including driver version, compilation timestamp, list of supported Vulkan extensions (static information), and current pipeline compilation optimization level (dynamic information), and generates a 128-bit Driver_Meta_Hash, which is updated in real time when the driver is updated or the optimization level changes.

[0063] Dimension 4: DXVK Semantic Version Hash. DXVK maintains a Semantic_Version structure, which contains only the core logic version related to shader processing.

[0064] typedef struct {

[0065] uint8_t shader_convert_version; / / Shader conversion logic version

[0066] uint8_t semantic_normalize_version; / / Semantic normalization logical version

[0067] uint8_t pipeline_proxy_version; / / Logical version for pipeline proxy creation

[0068] uint8_t cache_manage_version; / / Cache management logic version

[0069] } DXVK_Semantic_Version;

[0070] When any of the above core logic is modified, the corresponding version field is incremented, and a 32-bit DXVK_Semantic_Version_Hash is generated through CRC32 hashing to avoid cache invalidation caused by updates to unrelated functions.

[0071] S2.2 Incremental identifier concatenation and verification.

[0072] GUID structure definition: The high 64 bits are the hardware context core identifier HW_Context_Hash[0:63], the middle 64 bits are the driver metadata core identifier Driver_Meta_Hash[0:63], the low 32 bits are the semantic version identifier DXVK_Semantic_Version_Hash[0:31]DXVK, and the lowest 32 bits are the shader semantic fingerprint core segment Semantic_Fingerprint[0:31].

[0073] Incremental offset mechanism: A semantic difference bit marking scheme is adopted to classify the modification type of Standardized_SemanticIR, including instruction modification, resource binding modification and input / output modification. Each modification type corresponds to an 8-bit offset mask. When Standardized_SemanticIR undergoes a small change, the offset mask corresponding to the modification type is calculated and superimposed on the lowest 32 bits of the GUID, such as the Semantic_Fingerprint segment, without recalculating the complete hash.

[0074] Identifier conflict detection and resolution: The kernel-mode GUID_Conflict_Table uses a dual index of red-black tree and hash bucket. The red-black tree stores the GUID in order, and the hash bucket is grouped according to the high 64 bits of the GUID. The query time complexity is optimized to O(1). If a GUID conflict is detected, the complete semantic fingerprint of Standardized_SemanticIR of both conflicting parties is extracted. After comparison, the conflict sequence number is appended to the lowest 8 bits of the conflicting GUID and the index is re-inserted to ensure the uniqueness of the GUID after the conflict is resolved.

[0075] S2.3 Identifier metadata association and storage.

[0076] Extended definition of GUID_MetaData structure:

[0077] typedef struct {

[0078] uint8_t guid

[24] ; / / 192-bit GUID

[0079] char spirv_storage_path

[256] ; / / Optimized_SPIRV_Binary storage path

[0080] uint64_t spirv_size; / / Compressed SPIR-V size

[0081] uint8_t* semantic_ir_data; / / Standardized_SemanticIR serialization data

[0082] uint32_t semantic_ir_len; / / Length of serialized data

[0083] uint64_t create_timestamp; / / First generation of timestamp

[0084] uint32_t access_count; / / Total number of visits

[0085] uint64_t last_access_timestamp; / / Recent access timestamp

[0086] uint8_t cache_level; / / Current cache level, 1 represents L1, 2 represents L2, 3 represents L3

[0087] uint8_t status; / / Cache status, 0 represents valid, 1 represents invalid, 2 represents pending update

[0088] uint32_t crc64; / / Metadata CRC64 checksum

[0089] uint8_t conflict_seq; / / Conflict sequence number, 0 represents no conflict

[0090] } GUID_MetaData;

[0091] Storage optimization: GUID_MetaStore uses a B+ tree index with GUID as the primary key and shader stage and access timestamp as the secondary index, supporting multi-condition queries; metadata is stored in partitions according to GPU model and driver version, with each partition maintaining an independent B+ tree to improve query efficiency; GUID_MetaStore is regularly defragmented to merge free storage blocks and reduce memory usage.

[0092] S3, Heterogeneous Three-Tier Layered Cache Pool Design and Intelligent Management.

[0093] S3.1, enhanced design of a three-level cache pool architecture.

[0094] The in-process cache, L1 cache, is stored in cache pages dedicated to the DXVK process and bound to the CPU core local cache to avoid data migration between NUMA nodes. The capacity is dynamically adjusted adaptively based on the current number of shaders in the game, with a minimum of 32MB, a maximum of 128MB, and a step size of 16MB. The LRU-K eviction policy is implemented using a hash table and a doubly linked list. The hash table is used for fast lookups, and the doubly linked list maintains the access order. For frequently accessed cache items, the prefetch operation is performed on the CPU L1 cache after at least 10 accesses.

[0095] A cross-process shared memory cache, L2 cache, is stored in contiguous physical memory reserved in kernel mode and allocated via vmalloc, avoiding page table switching overhead. Each group has 32-way associations, employing a pseudo-LRU eviction algorithm that uses bitmasks to record the access order. Read and write are separated, with 8 parallel read ports supporting multiple processes reading the same cache entry simultaneously, and 4 parallel write ports employing a write-back and write allocation strategy. When writing, a cache line is allocated first, and then the data is written asynchronously. The MESI protocol is used to maintain cache consistency among multiple processes. When a process modifies a cache entry, it is marked as modified, and other processes trigger cache synchronization when reading it.

[0096] Persistent disk caching, L3 caching, is implemented using a primary partitioning system based on GPU model (16-bit), major driver version, and minor driver version. Each primary partition is further divided into secondary partitions based on game IDs to avoid mixed storage of cached items across hardware or drivers. A separate index and data area design is employed. The index area stores a B+ tree index mapping GUIDs to data area offsets, while the data area stores cached data in 4MB blocks, supporting parallel I / O. Each data block is stored in three copies across different physical blocks on the SSD, employing a RAID-1-like strategy. If one copy fails, it is automatically recovered from the others, ensuring data integrity. Cached items are retained for 90 days by default and are automatically cleaned up if there is no access within 90 days. The cached items for the top 100 most accessed games are permanently stored and only become invalid in cases of driver or hardware incompatibility.

[0097] S3.2, Refinement of cached data migration and synchronization mechanisms.

[0098] If a cached item is accessed 5 times consecutively with an interval of no more than 3 minutes, or if a single access takes no less than 500μs, it is considered a high-frequency access and is automatically promoted from L2 to L1. If a cached item has been accessed a total of 5 times, or if it is a cached item in the preload list at game startup, it is automatically loaded from L3 to L2. The promotion operation is performed in a manner that follows the priority decreases step by step, from high-frequency pipeline segments such as vertex shaders, to mid-frequency complete pipelines, and then to low-frequency shader modules.

[0099] If a cached item is not accessed for 15 consecutive minutes, or if the L1 cache capacity reaches its limit, it will be downgraded from L1 to L2 according to the LRU-K priority. If a cached item is not accessed for 14 consecutive days, or if the system memory utilization rate is not less than 85%, it will be asynchronously written to L3 and evicted. Before downgrading, the cached item will be compressed and re-optimized using the highest ZSTD compression level to reduce L3 storage overhead.

[0100] This embodiment adds a new dxvk_cache_sync_worker kernel thread pool, with a default value of 4 threads, responsible for asynchronous synchronization of L1, L2, and L3. The thread priority is set to SCHED_IDLE, so it does not occupy game runtime resources. During synchronization, it carries the synchronization version number to ensure that the versions of cached items in L1, L2, and L3 are consistent and to avoid synchronization conflicts. When an L3 cached item is updated, it notifies all corresponding items in the L2 cache through a reverse synchronization mechanism, triggering automatic updates, and then synchronizes from L2 to L1 to achieve cross-level synchronization.

[0101] Verification mechanism: When storing cached items, a CRC64 checksum is calculated for the SPIR-V binary and pipeline binary data portions and associated with the checksum in the metadata. When reading, the CRC64 checksum is checked first. If the checksum fails, the cached item is recovered from other cache levels. For example, if the L2 checksum fails, the cached item is read from L3. If all levels fail the checksum, the cached item is marked as corrupt and cached item reconstruction is triggered.

[0102] S3.3, Cache capacity dynamic adjustment strategy.

[0103] Memory usage control: The kernel monitors the system memory status every 500ms. When the memory usage is no more than 60%, the L2 cache capacity is set to 15% of the system memory; when the usage is less than 60% and no more than 75%, it is set to 10%; when the usage is less than 75% and no more than 85%, it is set to 5%; when it is no less than 85%, it is set to 2%, with a minimum of 1GB. A memory pressure prediction mechanism is adopted, which adjusts the cache capacity in advance based on the memory usage trend over the past 10 seconds. For example, if it is predicted that the memory usage will reach 85% in 5 seconds, the L2 cache will be reduced 1 second in advance.

[0104] SSD storage control: When the remaining space of the SSD is no more than 15%, the cold data cleanup process is started, prioritizing the elimination of cached items according to the earliest access time, the fewest cumulative access times, and the largest cached item size, until the remaining space is no less than 20%; for large cached items with a size of no less than 64MB, such as the complete pipeline cache of complex games, a strategy of block storage and on-demand loading is adopted to avoid occupying too much SSD space at once.

[0105] CPU load adaptation: When the CPU load is not less than 85%, pause cache promotion, demotion and synchronization threads, and only retain cache read function; when the CPU load is not greater than 70%, restore all cache management threads and start cache optimization background tasks such as defragmentation and compression re-optimization.

[0106] S4, pipeline fragment pre-compilation and zero-copy proxy creation mechanism.

[0107] S4.1, Pipeline Fragment Pre-compilation and Storage Enhancement.

[0108] High-frequency pipeline fragment identification: DXVK analyzes the Shader_Access_Log_DB from the last three game runs and uses a frequent itemset mining algorithm to identify pipeline state combinations with a support rate of no less than 60%, such as vertex input layout A, render target format B, and depth stencil state C, which are defined as pipeline fragment templates. Based on function, they are divided into fixed-state fragments and variable-state fragments. Fixed-state fragments are pre-compiled and permanently cached, while variable-state fragments are pre-compiled in combination. Fixed-state fragments include vertex input layout and render target format, while variable-state fragments include blending mode and depth offset.

[0109] Pre-compilation process optimization: Before the first launch after game installation, when the system is idle, and after driver update. When the system is idle, the system can determine the priority based on CPU load not exceeding 50% and memory usage not exceeding 60%. Pre-compilation is performed according to the priority of the top 100 most visited games, recently run games, and unrunn games, with the priority decreasing in descending order. The pre-compiled product Precompiled_Pipeline_Fragment contains kernel-mode shader module handles, KHR format pipeline state objects, driver native format compiled binary, dependency resource list, and CRC64 checksum.

[0110] Pipeline Fragment Index: Maintains a Pipeline_Fragment_Index hash table, with the key being the GUID and pipeline fragment template ID, and the value being the storage offset of the Precompiled_Pipeline_Fragment in the L2 cache; supports fragment combination queries, allowing users to quickly query whether a corresponding combined precompiled artifact exists by inputting multiple pipeline fragment template IDs.

[0111] S4.2, Enhanced design of the kernel-mode pipeline agent creation module.

[0112] The vk_pipeline_proxy module extension interface established in this embodiment includes: proxy_create_pipeline(GUID, Pipeline_Template_ID, Resource_Binding_Map), where the newly added Resource_Binding_Map parameter is used to map the standardized resource binding slots back to the original game slots; proxy_incremental_compile(GUID, Candidate_GUID, Incremental_Compile_Instructions), which supports incremental compilation proxies based on candidate cache items; proxy_query_pipeline_status(GUID), which is used to query the status of pipeline cache items, including valid, invalid, corrupted, and uncompiled; and proxy_destroy_pipeline(GUID), which is used to synchronously destroy pipeline cache items with a specified GUID across levels.

[0113] Maintain the driver interface adaptation table and provide dedicated interface calling logic for drivers from different GPU manufacturers to ensure compatibility.

[0114] Pipeline compilation optimization options: Use a performance-priority optimization level during pre-compilation, such as enabling full instruction reordering, constant folding, and loop unrolling. Use a fast compilation optimization level when the runtime compilation cache is missed. Automatically recompile to a performance-priority version and update the cache when the system is idle.

[0115] S4.3, Create a zero-copy pipeline.

[0116] L1 cache hit: DXVK queries the local user-space GUID metadata storage to obtain the corresponding GUID and pipeline fragment template identifier; based on the GUID, it reads the pre-stored pipeline binary data in the L1 cache. Using the Vulkan standard extension VK_KHR_pipeline_binary, the cached pipeline binary data is passed to vkCreateGraphicsPipelinesFromBinaryKHR to reconstruct the pipeline object; the restoration of resource binding slots is completed at the descriptor set layer, eliminating the need for repeated SPIR-V parsing and execution of vkCreateShaderModule.

[0117] L2 or L3 cache hit: If L1 misses, DXVK queries the L2 shared memory cache. If a hit occurs, it reads the pre-stored pipeline binary data in the cache and promotes a copy of the cache entry to the L1 process cache. If L2 misses, it accesses the L3 disk persistent cache. If a hit occurs, it loads the pipeline binary into the L2 shared cache via asynchronous I / O and then reads the data for pipeline reconstruction. The graphics pipeline is reconstructed using the VK_KHR_pipeline_binary extension interface.

[0118] Cache miss: DXVK reads Optimized_SPIRV_Binary from the L3 disk cache, performs decompression using the LZ4HC algorithm (decompression speed can reach over 2GB / s), calls the standard Vulkan interface vkCreateShaderModule, and passes in the decompressed SPIR-V binary data to create a shader module. It then assembles the pipeline state using pipeline fragment templates and calls vkCreateGraphicsPipelines to compile the graphics pipeline. After compilation, it exports the pipeline binary data via the VK_KHR_pipeline_binary extension. The exported pipeline binary is synchronously written to the L1 process cache, asynchronously written to the L2 shared cache and L3 persistent disk cache, and simultaneously updated to the user-space GUID metadata dataset and the pipeline fragment index table.

[0119] Exception handling mechanism: If a pipeline compilation fails due to SPIR-V compatibility issues, the GUID is marked as requiring compatibility handling, and SPIR-V compatibility conversion is performed before re-compiling. If the pipeline binary CRC64 check does not match, the cached item is determined to be corrupted, and secondary compilation is automatically started with conservative compilation mode enabled and aggressive compilation optimization disabled. If secondary compilation succeeds, the original cached entries are overwritten; if compilation fails, an error log is recorded, and the process reverts to the native DXVK compilation flow.

[0120] S4.4 Optimization of pipeline segment splicing.

[0121] Fragment dependency management: Maintain a list of dependent fragments for each pipeline fragment, recording other fragments required for the fragment to function properly, such as the output layout of the vertex shader fragment that the geometry shader fragment depends on; Before splicing, verify the completeness of dependencies through the built Dependency_Checker module. If a dependent fragment is missing, it is automatically queried from the cache and loaded. If it cannot be loaded, just-in-time compilation of the dependent fragment is triggered.

[0122] Kernel-mode fragment linking optimization: When calling the constructed kernel-mode vk_drv_link_pipeline_fragments interface, pass in fragment linking optimization options, such as enabling inter-fragment instruction reordering and constant merging; for complex pipelines containing multiple fragments, generate a link cache to store the complete pipeline binary after linking, and reuse the link cache directly for subsequent combinations of the same fragments to avoid duplicate linking overhead.

[0123] Fragment compatibility adaptation: Maintain a fragment compatibility matrix to record the compatibility relationships between fragments of different versions, such as the compatibility between old fixed-state fragments and new variable-state fragments after a driver update; if fragment incompatibility is detected during splicing, fragment adaptation compilation is automatically triggered to generate compatible fragments and update the cache.

[0124] S5, semantic similarity-driven cache reuse and incremental compilation.

[0125] S5.1 Optimization of semantic similarity calculation model.

[0126] Enhanced Feature Vector Construction: A multi-layer feature extraction strategy is adopted. The bottom layer features are the opcode statistical vector of the instruction sequence and the resource binding type distribution vector, where the opcode statistical vector includes the proportion of addition instructions and the proportion of texture sampling instructions. The middle layer features are the structural features of the control flow graph and the dimension vector of the input and output layout, where the structural features of the control flow graph include the number of branch nodes, the nesting depth of loops, and the number of paths. The high layer features are the semantic vector of shader functions, such as whether PBR lighting is supported and whether shadow calculation is included. Min-Max normalization is performed on each layer feature vector to map it to the [0,1] interval, and then weighted and fused according to weights, such as 0.3 for the bottom layer, 0.4 for the middle layer, and 0.3 for the high layer, to generate the final 1024-dimensional semantic feature vector.

[0127] Accelerated similarity calculation: A hierarchical screening strategy is adopted. The first layer quickly filters candidates based on the Euclidean distance of the bottom-level feature vectors, with a threshold of no more than 0.2, eliminating obviously dissimilar candidate shaders. The second layer calculates the cosine similarity of the mid-level feature vectors of the selected candidates, with a threshold of no less than 0.7. The third layer calculates the Jaccard similarity of the high-level feature vectors of the candidates that pass the mid-level screening, with a threshold of no less than 0.8. Finally, candidates with a comprehensive similarity of no less than 85% are selected.

[0128] Introducing GPU-accelerated computation: When the number of candidate shaders is not less than 1000, the feature vectors are transmitted to the GPU, and the similarity is calculated in parallel through the OpenCL kernel.

[0129] S5.2 Semantic Difference Extraction and Incremental Compilation.

[0130] Based on the structured comparison of Standardized_SemanticIR, differences are extracted according to semantic units such as variables, instructions, resource bindings, and control flow structures, and a difference tree is generated. The root node is the difference type and the child nodes are the specific difference content. For instruction differences, not only the changes of the instruction itself are recorded, but also the changes of the variables and constants it depends on are also recorded. For example, when the operands of an arithmetic instruction are modified, the changes of the constants corresponding to the operands are recorded simultaneously.

[0131] Generate an incremental compilation instruction set, generating targeted compilation instructions based on the type of difference. For variable differences, generate instructions for variable redefinition and variable type conversion; for instruction differences, generate instructions for instruction replacement, insertion, and deletion; for resource binding differences, generate instructions for binding slot remapping and resource type adaptation; for control flow differences, generate instructions for branch condition modification and loop structure reconstruction. The incremental compilation instruction set includes dependency verification information to ensure that instructions are executed in dependency order during compilation.

[0132] Before compilation, the compatibility of the incremental instruction set with the candidate shader compilation artifacts is verified by Compatibility_Checker. If there is a compatibility conflict, such as the absence of variables that the instruction depends on, the incremental instruction set is automatically expanded to supplement the necessary compatibility handling instructions. After compilation, a few key rendering test cases are run on the generated Compiled_Pipeline_Binary for compatibility testing. Only after the test passes is the data written to the cache to ensure the compatibility of incremental compilation.

[0133] S5.3, Reuse cache item update and association mechanism.

[0134] Persistence of Relationships: A new `reuse_relation` field is added to `GUID_MetaData` to store the reused candidate shader GUID, similarity value, and difference tree summary, using protobuf serialization for storage; a reuse index is created in `GUID_MetaStore` to support quick querying of all target shaders that reuse a candidate shader, and the reuse index is a mapping from candidate GUID to the list of target GUIDs.

[0135] Candidate cache item update: When a candidate shader cache item becomes invalid or is updated due to driver updates, semantic changes, or other reasons, all associated target shaders are notified by reusing the index; when the target shader is accessed for the next time, the similarity with the new candidate shader is automatically recalculated. If the similarity is still not less than 85%, incremental compilation is performed to update the cache based on the new candidate; if the similarity is lower than the threshold, full compilation is triggered.

[0136] S6, Shader update cache synchronization mechanism.

[0137] Shader update detection: When the game starts, DXVK scans the shader files in the game's installation directory, calculates the file checksum and compares it with the checksum stored from the last run; if the checksums are inconsistent, it is determined that the shader has been updated, the path of the updated shader file, the old and new checksums are recorded, and the shader update processing flow is triggered; incremental update detection is supported, that is, only files modified since the last run are scanned to reduce detection time.

[0138] Old cache association reuse: For the updated shader, semantic normalization is performed to generate Standardized_SemanticIR and temporary GUID. GUID_MetaStore is queried, and the old shader cache item before the update is found through semantic similarity calculation and used as the source cache item. The semantic differences between the updated shader and the source cache item are extracted to generate an incremental compilation instruction set. Incremental compilation is performed based on the Compiled_Pipeline_Binary of the source cache item to generate the compilation artifact of the updated shader, avoiding complete duplicate compilation. The updated source GUID, i.e., the source cache item GUID, is recorded in the GUID_MetaData of the new GUID to establish an update association. The source cache item is retained as a historical version. If the new cache item has compatibility issues, it can be quickly rolled back to the source cache item.

[0139] Batch update optimization: When multiple shaders are updated simultaneously, a strategy of batch difference extraction and parallel incremental compilation is adopted. The differences between all updated shaders and their corresponding source cache items are extracted in batches and grouped by difference type, such as variable modification group and instruction modification group. Multiple background compilation threads are started, with the number of threads being half the number of CPU cores, to process the incremental compilation tasks of different groups in parallel. Batch update logs are generated to produce shader update reports, recording information such as the number of updated shaders, the number of reused source cache items, incremental compilation time, and storage space saved.

[0140] S7, a real-time cache invalidation mechanism driven by events.

[0141] This embodiment adds the following event types: hardware events, driver events, and system events. Hardware events include GPU memory error recovery, PCIe link status changes, and hardware performance threshold adjustments. Driver events include driver configuration file updates, shader compilation backend switching, and driver security patch installation. System events include system kernel version updates, Vulkan runtime library version updates, and GPU power management mode switching.

[0142] Callback function optimization: This embodiment adds the on_cache_invalidate_event callback function, which supports event filtering and only processes critical events related to cache compatibility, such as driver core version updates, while ignoring irrelevant events, such as driver log level modifications. The callback function adopts priority scheduling, with hardware failure events having the highest priority and being processed in real time, driver configuration updates having a medium priority, and system kernel updates having the lowest priority, which is delayed until after the game exits.

[0143] Hardware events: Based on changes in HW_Context_Hash, only cached items bound to the old hardware state are evicted, not all cached items; Driver events: If a driver update only modifies the compilation logic of a specific shader stage, such as only optimizing the compilation of fragment shaders, then only cached items for that shader stage are evicted; System events: When the Vulkan runtime library is updated, it is determined by the version compatibility matrix, and only cached items using incompatible API features are evicted.

[0144] A mark-and-sweep separation mechanism is adopted: when an event is triggered, only invalid cache items are marked, i.e., GUID_MetaData.status=1 is set, and the data is not cleaned up immediately; the cleanup timing is when the game exits, when the system is idle, and when the cache capacity is insufficient. In this case, a background thread cleans up invalid cache items in batches to release storage resources; a cache invalidation notification is sent to all running DXVK processes. After receiving the notification, the process immediately cleans up the corresponding item in its L1 cache to avoid using invalid cache; the notification carries a summary of the invalid GUID list. The process can quickly compare the local L1 cache with the summary without transmitting the complete GUID list.

[0145] High-frequency accessed invalid cache items (access_count not less than 10) are restored first, while low-frequency items (access_count not greater than 2) are restored with a delay or on demand. Invalid cache items currently in use in the game scene are restored immediately, while other items are restored asynchronously in the background.

[0146] During recompiling, the original cached Standardized_SemanticIR and preprocessing results are reused, skipping the semantic normalization and preprocessing steps. If recompiling fails, such as when the new driver does not support the old shader semantics, semantic adaptation conversion is automatically performed to convert the old Standardized_SemanticIR to a version compatible with the new driver before recompiling.

[0147] S8, cross-scenario optimization and access control strategies.

[0148] This embodiment defines three types of access permissions: read permission, read-write permission, and management permission. Read permission only allows reading cached items, read-write permission allows reading and writing cached items, and management permission allows deleting and modifying cached item metadata. When each process starts, permissions are assigned based on the process owner and process signature. Game processes of ordinary users are assigned read permission by default, trusted game processes are assigned read-write permission, and only the root process is assigned management permission.

[0149] Permission verification mechanism: When the kernel Cache_Lock_Manager processes a process cache access request, it first verifies the process permissions. Read requests require read permissions or higher, write requests require read-write permissions or higher, and management requests are only allowed with management permissions. If the permissions are not met, the request is rejected and a security log is recorded.

[0150] Malicious process protection: If frequent invalid access requests are detected, such as no less than 100 unauthorized write requests within 1 second, the process will be automatically added to the cache access blacklist and all cache access will be denied for 5 minutes; For write operations that modify cache data, the operation log will record the process ID, operation time, and data summary before modification, and support the traceability of cache data tampering.

[0151] For fully virtualized environments, such as KVM, each virtual machine is allocated an independent L2 cache partition, and the L3 cache is partitioned according to the virtual machine ID and GPU passthrough identifier, and cross-virtual machine sharing is prohibited by default; for containerized environments, such as Docker, containers on the same host can share the L2 cache, and the L3 cache shares the same partition, and the owner of the cache item is distinguished by the container ID.

[0152] In virtual machine GPU passthrough scenarios, the built kernel vk_hw_context_collector module directly accesses the physical GPU registers to obtain real hardware information, avoiding information distortion caused by the virtualization layer and ensuring the accuracy of HW_Context_Hash; in container environments, the shared L2 cache adopts memory isolation mapping, and each container can only access cache items within its permission scope to avoid unauthorized access.

[0153] Based on the LSTM time series prediction model, scene features such as the current game scene type and player behavior patterns are introduced as input to improve prediction accuracy. The model is trained regularly with newly added data from Shader_Access_Log_DB to optimize prediction weights and adapt to the shader access patterns updated in the game.

[0154] Preloaded data prioritizes the use of available memory bandwidth to avoid competing with game rendering for bandwidth; when the game enters a high-load scene, such as when the frame rate is no more than 30fps, preloading is paused to prioritize the game's operation.

[0155] In addition, if a preloaded cached item is not accessed for more than 24 hours, its validity will be automatically revalidated, and if invalid, an update preload will be triggered.

[0156] When performing cross-process hot updates, the transmitted cached data is digitally signed, such as based on the official DXVK key. The receiving process verifies the signature before updating the cache, preventing malicious tampering. Hot update data is transmitted using AES-128 encryption, with the key negotiated through a secure inter-process channel, such as based on Linux AF_UNIX sockets and shared keys. The remote cache server stores L3 cache entries for popular games, with each cache entry accompanied by a hardware or driver compatibility list. Users only download cache entries compatible with their own environment. Downloaded cache entries undergo dual verification, including server digital signature verification and local CRC64 verification, to ensure data integrity. Incremental synchronization is supported, meaning only missing or updated cache entries are downloaded locally, reducing network transmission volume.

[0157] 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 shader cache optimization method based on semantic normalization and multi-dimensional dynamic adaptation, characterized in that, Specifically, the following steps are included: When the GPU does not support the VK_EXT_shader_module_identifier extension, a heterogeneous three-level hierarchical cache pool is constructed, including an in-process high-speed cache L1, a cross-process shared memory cache L2, and a persistent disk cache L3. Before the installed D3D application is started or when the system is idle after the Vulkan graphics driver is updated, each D3D application is divided into popular applications, recently run applications, and unrun applications based on historical running logs. For the D3D applications that have been run, their exclusive high-frequency pipeline fragment templates are mined, and for the D3D applications that have not been run, a general high-frequency pipeline fragment template is used. L3 is searched in the order of popular applications, recently run applications, and unrun applications. For entries that do not exist in the cache, pre-compilation is performed and the compiled products are stored in L3. When a D3D application creates a shader, the shader bytecode is converted into SPIR-V binary. The binary is parsed using a dual-mode approach of instruction flow traversal and CFG analysis. Core semantic information is extracted according to the segment structure, and a control flow graph is constructed. A standard semantic intermediate representation is generated and standardized. Dead code is eliminated and compressed to obtain compressed SPIR-V. Based on the standard semantic intermediate representation, the shader semantic fingerprint is calculated. The shader semantic fingerprint, GPU hardware context hash, driver metadata hash and DXVK semantic version hash are concatenated into a multidimensional identifier to realize the binding of hardware, driver, DXVK semantic version and shader semantics. The multidimensional identifier and compressed SPIR-V are persistently stored in the L3 index area and data area respectively. When a D3D application creates a D3D rendering pipeline, it sequentially searches the L1, L2, and L3 caches using the multidimensional identifier corresponding to the shader bound to the pipeline as the primary key. If a matching valid pipeline binary exists, the pipeline binary is read into the current process memory, and physical page reuse is achieved through shared memory to rebuild the Vulkan pipeline object. If it does not exist, it reads the compressed SPIR-V decompressed data from L3, calls the Vulkan driver interface in user space to complete the pipeline compilation, and writes the compiled artifacts back to the three-level cache pool, thus completing the creation of the D3D rendering pipeline into the Vulkan rendering pipeline.

2. The shader cache optimization method according to claim 1, characterized in that, Upgrading cached data from L2 to L1 requires the cached data to be accessed frequently multiple times or the time taken for a single access to exceed a threshold. Upgrading from L3 to L2 requires the cached data to be accessed a set number of times or to hit the application's preload list. During degradation, the degraded cached data is recompressed and optimized. After L3 is updated, L2 and L1 are notified of the update level by level through the reverse synchronization mechanism.

3. The shader cache optimization method according to claim 1, characterized in that, The GPU hardware context hash is calculated by collecting inherent GPU information and dynamic running status, the driver metadata hash is calculated by collecting static driver version and dynamic compilation level, and the DXVK semantic version hash is calculated for the core logic version of DXVK that is only related to shader processing.

4. The shader cache optimization method according to claim 1, characterized in that, When a new shader enters the compilation process, a semantic feature vector is constructed, including low-level features of instruction sequence statistics and resource binding type distribution, mid-level features of control flow graph structure and input / output layout dimensions, and high-level features of shader functional semantic identifiers. In the cache, candidate shaders are first excluded based on the Euclidean distance of the low-level features, then the cosine similarity of the mid-level features is calculated, and finally the Jaccard similarity of the high-level features is calculated. Candidate shaders with a comprehensive similarity greater than a set threshold are selected. If a matching candidate shader exists, differences are extracted according to semantic unit classification and comparison to generate a difference tree. An incremental compilation instruction set is generated according to the difference type and incremental compilation is performed. The compilation product is written to the cache pool, and a reuse index is established. If no matching candidate shader exists, a full compilation is triggered. When a candidate cached item becomes invalid due to driver updates or semantic changes, all associated target shaders are notified through index reuse. The target shader recalculates the similarity the next time it is accessed. If the similarity still meets the set threshold, incremental compilation and updates are performed based on the new candidate. If the similarity is lower than the set threshold, a full compilation is triggered.

5. The shader cache optimization method according to claim 1, characterized in that, When the D3D application starts, DXVK scans the shader files in the application's installation directory, calculates the file checksum and compares it with the checksum stored in the last run. If the checksum is inconsistent, semantic normalization is performed on the updated shader to generate a standard semantic intermediate representation and a temporary multidimensional identifier. The source cache item before the update is matched by semantic similarity calculation. If a match is found, the semantic differences between the updated shader and the source cache item are extracted to generate an incremental compilation instruction set. Based on the compiled pipeline binary of the source cache item, incremental compilation is performed to generate the compilation artifact of the updated shader, an update association is established, and the source cache item is marked as a historical version. If no source cache item is matched, a full compilation is performed.

6. The shader cache optimization method according to claim 5, characterized in that, When multiple shaders are updated simultaneously, batch difference extraction is used to group them by difference type. Half the number of background compilation threads are started to process the incremental compilation tasks of different groups in parallel. A shader update report is generated to record the number of updates, the number of reused source cache items, the incremental compilation time and storage space saved, and stored in the shader update log.

7. The shader cache optimization method according to claim 1, characterized in that, Perform status checks during program startup, frame idle intervals, and after GPU device reset and recovery to identify hardware events, driver events, or system events. Hardware failure events are handled with priority, driver configuration updates are processed with medium priority, and system kernel updates are delayed until after application exit. Hardware events evict cache entries bound to the old hardware state based on changes in hardware context hashes. If a driver event only modifies the compilation logic of a specific shader stage, only cache entries for that stage are evicted. In system events involving Vulkan runtime library updates, only cache entries using incompatible API features are evicted. When an event is detected, invalid cache entries are marked as invalid without immediate data cleanup. Storage resources are released in batches by a background thread when the application exits, the system is idle, or the cache capacity is insufficient. Simultaneously, a cache invalidation notification carrying a summary of the list of invalid multidimensional identifiers is sent to all running DXVK processes. Upon receiving the notification, the corresponding local cache entries are cleaned up. When restoring invalid cache entries, priority is given to high-frequency access items and items currently used by the application in the current scenario. Low-frequency items are restored with delay or on demand.

8. The shader cache optimization method according to claim 1, characterized in that, In cross-scenario reuse scenarios, three levels of access permissions are defined: read permission, read-write permission, and management permission. When a process starts, permissions are assigned based on the process owner and process signature. Ordinary user application processes are assigned read permission by default, trusted application processes are assigned read-write permission, and only the root process is assigned management permission. When processing cache access requests, process permissions are verified first. If permissions are insufficient, the request is rejected and a security log is recorded. When invalid accesses are detected for a number of times not less than a set threshold within a set time, the process is added to the cache access blacklist and saved for a set time. For write operations that modify cached data, the process ID, operation time, and a summary of the data before modification are recorded.

9. The shader cache optimization method according to claim 8, characterized in that, In a virtualization environment, each virtual machine is allocated an independent L2 cache partition, and the L3 cache is partitioned according to the virtual machine ID and GPU passthrough identifier. Cache sharing between virtual machines is prohibited by default. In the virtual machine GPU passthrough scenario, the physical GPU registers are read directly to obtain the real hardware information.

10. The shader cache optimization method according to claim 8, characterized in that, In a containerized environment, containers on the same host need to be configured and have cache sharing permissions enabled to share the L2 cache, and a memory isolation mapping mechanism is used to ensure that each container can only access cache items within its own permission scope; the L3 cache shares the same partition, and the owner of each cache item is distinguished by the container ID.

Images