An API-crossing and platform-crossing GPU resource life cycle management method and system

Abstract

The application relates to the technical field of GPU driving resource management, and discloses a GPU resource life cycle management method and system across APIs and platforms, which comprises the following steps: when a GPU resource is created, the resource category is determined according to a destruction dependency topological relation, and the determination of the resource category is irrelevant to API types, pipeline sources, application scenarios, operating systems and CPU architectures; a destruction control strategy bound to the resource category is acquired; when the acquired destruction control strategy is a delayed destruction strategy, a delayed destruction entry is generated and the entry is added to a slot corresponding to a current scheduling period sequence number in a ring buffer structure; in each scheduling period, each slot of the ring buffer structure is traversed, and the resources of a delayed destruction entry with a target scheduling period sequence number satisfying a preset expiration condition are destroyed; if it is another destruction control strategy, corresponding destruction processing is performed; and through the above method, differentiated automatic destruction management of GPU resources across APIs, pipelines, scenarios and platforms is realized.

Description

Technical Field

[0001] This invention relates to the field of GPU driver resource management technology, and in particular to a cross-API, cross-platform GPU resource lifecycle management method and system. Background Technology

[0002] In modern GPU (Graphics Processing Unit) programming, applications need to manage the entire lifecycle of GPU resources. As GPU programming interfaces have evolved from traditional implicit APIs (such as OpenGL and DirectX 11) to explicit APIs (such as Vulkan, DirectX 12, and Metal), the complexity and fine-grained requirements of resource management have increased significantly. Modern GPUs simultaneously support multiple command processing pipelines, including graphics rendering, general-purpose computing, ray tracing, media processing, and data transfer. Heterogeneous resources created by different pipelines face different synchronization constraints when destroyed. Furthermore, GPU applications need to run on multiple operating systems (Linux, Windows, Android, macOS, etc.) and multiple CPU instruction set architectures (RISC-V, x86, ARM, LoongArch, etc.).

[0003] Existing technical solutions typically design management strategies based on pipeline type or API type, which has the following shortcomings: In solutions that manage resources separately by pipeline type, the responsibilities for shared resources across pipelines are unclear, which can easily lead to premature release or memory leaks, and the system complexity increases linearly with the increase of pipeline type; unified delayed destruction queue solutions (such as the fixed frame number waiting used by Unreal Engine) do not distinguish the differences in the topology of resource destruction dependencies, and excessive waiting for lightweight resources can lead to memory waste, while complex cross-frame dependent resources may be destroyed incorrectly; reference counting solutions require manual calls to retain / release, which is highly intrusive and cannot automatically detect implicit references across pipelines; in GPGPU frameworks such as CUDA and OpenCL, manual management methods make it difficult to determine the safe destruction time of resources in multi-iteration asynchronous computation, and the ownership is also unclear in a cluster environment.

[0004] The fundamental flaw in the aforementioned solutions lies in the fact that while GPU resources across different pipelines, APIs, and scenarios differ significantly in functionality and interface, they exhibit deep isomorphism in their resource destruction dependencies, all facing three core issues: ownership, asynchronous reference state, and cross-frame / cross-step dependencies. Existing technologies fail to identify and utilize this cross-API, cross-pipeline, cross-scenario, and cross-platform isomorphism, leading to redundant, incomplete, or platform-bound management strategies. A unified, universal, and cross-platform deployable GPU resource lifecycle management solution is lacking. Summary of the Invention

[0005] The purpose of this invention is to solve the technical problems of redundant management strategies, difficulty in cross-scenario adaptation, and difficulty in unified deployment caused by the binding of GPU resource management schemes to specific API types, command processing pipeline types, application scenarios, or operating platforms in the prior art. The invention provides a cross-API and cross-platform GPU resource lifecycle management method and system that is independent of API, pipeline, OS, and ISA.

[0006] On the one hand, this invention provides a cross-API, cross-platform GPU resource lifecycle management method, including the following steps: S1: When creating GPU resources, the resource category is determined based on the destruction dependency topology of the GPU resource, and the data representing the resource category is stored in the corresponding resource object. The determination of the resource category is independent of the underlying GPU programming interface type, command processing pipeline type, application scenario type, operating system type, and central processing unit instruction set architecture type from which the GPU resource originates. S2: Obtain the destruction control policy bound to the resource category from the destruction control policy set, wherein the destruction control policy set includes at least a delayed destruction policy; S3: When the obtained destruction control strategy is a delayed destruction strategy, a delayed destruction entry is generated and added to the slot corresponding to the current scheduling cycle number in the circular buffer structure. The delayed destruction entry contains at least the identifier of the GPU resource and the target scheduling cycle number. In each scheduling cycle, each slot of the circular buffer structure is traversed, and resource destruction is performed on the delayed destruction entries whose target scheduling cycle number meets the preset expiration condition. If it is another destruction control strategy, the corresponding destruction process is performed.

[0007] Further, in step S1, the destruction dependency topology is determined by the ownership dimension, the asynchronous reference state dimension, and the sub-resource relationship dimension; the multiple resource categories include at least: The first category corresponds to resources that are asynchronously referenced by the GPU command queue; The second category corresponds to resources created and owned by external systems, which the application layer only has borrowing rights for. These external systems are window systems or exchange chains in real-time rendering scenarios, cluster schedulers in scientific computing scenarios, and file systems or distributed storage in offline rendering scenarios. The third category corresponds to proxy resources that have native objects outside the packaging but do not hold ownership of the underlying resources.

[0008] Further, in step S2, the destruction control strategy includes: The delayed destruction strategy corresponds to the first category; Corresponding to the second category of handle-only cancellation strategy, during execution, the handle of the resource is only cancelled from the unified handle manager, without calling the destruction function of the underlying GPU programming interface; Corresponding to the third category of unpacking strategies, the mapping relationship between proxy resources and native objects is released during execution without destroying the underlying native objects.

[0009] Furthermore, in step S2, before obtaining the destruction control policy bound to the resource category, the following is also included: During the construction of resource objects, a virtual function mechanism is used to bind a corresponding destruction control strategy to each resource category, so that GPU resources belonging to the same resource category can determine the same destruction control strategy at compile time.

[0010] Furthermore, the determination of the resource category and the acquisition of the destruction control strategy are implemented through the standard extension layer of the GPU programming interface, providing a unified resource lifecycle management API entry point for the application layer.

[0011] Further, in step S3, the target scheduling cycle number is calculated using the following formula: , in, The target scheduling cycle number indicates the scheduling cycle in which the delayed destruction entry can be safely destroyed; The current scheduling cycle number indicates the scheduling cycle when the delayed destruction entry is generated and added to the circular buffer structure; This is a safety delay value, a preset non-negative integer. Its value is configured based on the synchronization characteristics of the underlying GPU programming interface, the concurrency of the command processing pipeline, or the time characteristics of the application scenario.

[0012] Furthermore, in step S3, the ring buffer structure is a ring array with a fixed number of slots, which is equal to the maximum number of concurrent scheduling cycles allowed, so that when the current scheduling cycle number grows to cover the old slots that have been used, all delayed destruction entries in the old slots that meet the preset expiration conditions have been processed.

[0013] Furthermore, the method also includes using a templated handle manager to uniformly manage references to GPU resources and trigger destruction processes: The reference counting detection interface manages references to all types of GPU resources, maintains a bidirectional mapping between handle identifiers and smart pointers, and monitors reference counts. When a reference count is detected indicating that the GPU resource is held solely by the unified handle manager itself, meaning that all external references to the GPU resource have been released, the acquisition and execution of the control destruction policy are automatically triggered.

[0014] Furthermore, the method also includes: Verify at least one of the following during each scheduling cycle or in response to a resource state change: The destruction control policy currently assigned to a GPU resource is consistent with the resource category to which it belongs; Does the circular buffer structure contain expired entries whose target scheduling cycle number is less than the current scheduling cycle number but have not yet been processed? The correctness of the ownership of externally owned resources.

[0015] Furthermore, the scheduling cycle number is the frame number in real-time rendering applications, the rendering pass number in offline rendering applications, and the iteration step number in general computing applications.

[0016] On the other hand, this invention provides a cross-API, cross-platform GPU resource lifecycle management system, including: The resource classification module is used to determine the resource category of a GPU resource based on its destruction dependency topology when creating the GPU resource, and to store the data representing the resource category in the corresponding resource object. The determination of the resource category is independent of the underlying GPU programming interface type, command processing pipeline type, application scenario type, operating system type, and central processing unit instruction set architecture type from which the GPU resource originates. The strategy acquisition module is used to acquire the destruction control strategy bound to the resource category from the destruction control strategy set, wherein the destruction control strategy set includes at least a delayed destruction strategy. The circular buffer scheduling module is used to generate a delayed destruction entry and add the entry to the slot corresponding to the current scheduling cycle number in the circular buffer structure when the obtained destruction control policy is a delayed destruction policy. The delayed destruction entry contains at least the identifier of the GPU resource and the target scheduling cycle number. In each scheduling cycle, the module traverses each slot of the circular buffer structure and performs resource destruction on the delayed destruction entries whose target scheduling cycle number meets the preset expiration condition. If it is another destruction control policy, the module performs the corresponding destruction process.

[0017] Compared with the prior art, the beneficial effects of the present invention are: (1) The present invention classifies resources based on the topological relationship of destruction rather than the source of resources, so that the same set of resource classification and scheduling logic can be applied to any GPU programming interface, command processing pipeline, application scenario and running platform, significantly reducing the development and maintenance costs of cross-platform GPU applications; (2) The present invention binds different destruction strategies to different resource categories. Resources asynchronously referenced by the GPU are subject to delayed destruction to ensure safety. Lightweight or descriptive resources can be reclaimed immediately, avoiding memory waste caused by the traditional unified waiting scheme. (3) The present invention adopts a fixed-size ring buffer structure, and stores delayed destruction entries in slots according to the scheduling cycle. Only expired entries are processed in each cycle. The scheduling time is stable and the memory usage is controllable, which is suitable for various scenarios such as real-time rendering and offline rendering. (4) When adding new pipeline types or application scenarios, the present invention only needs to map the new resources to the existing categories according to the destruction dependency topology, without modifying the core scheduling logic, and the system complexity does not increase linearly with the number of pipelines or platforms. (5) The present invention standardizes the resource classification system and scheduling mechanism into the components of the GPU programming model to fill the standardization gap between command submission and resource safe reclamation in the explicit API. Attached Figure Description

[0018] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings: Figure 1 This is a flowchart of a cross-API, cross-platform GPU resource lifecycle management method according to the present invention; Figure 2 This invention provides a multi-layered architecture data flow diagram for a cross-API, cross-platform GPU resource lifecycle management system. Figure 3 This is a timing diagram of a circular frame / task queue according to the present invention. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0020] This invention proposes a GPU resource lifecycle management method that is independent of API (Application Programming Interface), pipeline, operating system (OS), and instruction set architecture (ISA). Regardless of the API, pipeline, application scenario, or platform from which a resource originates, it is categorized solely based on its dependency topology at the time of destruction. Resources are grouped into the same category and treated with the same destruction strategy if they occupy the same position in the destruction dependency topology (e.g., they may be asynchronously referenced by the GPU).

[0021] The specific embodiments of the present invention will be described below with reference to the accompanying drawings and examples.

[0022] Example 1

[0023] Please see Figure 1 The technical solution for a cross-API, cross-platform GPU resource lifecycle management method provided in this embodiment includes the following steps: S1: When creating GPU resources, the resource category is determined based on the destruction dependency topology of the GPU resource, and the data representing the resource category is stored in the corresponding resource object. The determination of the resource category is independent of the underlying GPU programming interface type, command processing pipeline type, application scenario type, operating system type, and central processing unit instruction set architecture type from which the GPU resource originates. S2: Obtain the destruction control policy bound to the resource category from the destruction control policy set, wherein the destruction control policy set includes at least a delayed destruction policy; S3: When the obtained destruction control strategy is a delayed destruction strategy, a delayed destruction entry is generated and added to the slot corresponding to the current scheduling cycle number in the circular buffer structure. The delayed destruction entry contains at least the identifier of the GPU resource and the target scheduling cycle number. In each scheduling cycle, each slot of the circular buffer structure is traversed, and resource destruction is performed on the delayed destruction entries whose target scheduling cycle number meets the preset expiration condition. If it is another destruction control strategy, the corresponding destruction process is performed.

[0024] In this embodiment, the above method is implemented by constructing a multi-layered architecture, which includes five layers: a resource classification system, a policy binding mechanism, a ring frame / task queue scheduler, a unified handle manager, and a runtime verifier. The following will combine... Figure 2 And a detailed explanation of the above architecture.

[0025] The first step, resource classification in step S1, is implemented within a first-level resource classification system. The destruction dependency topology is determined by the ownership dimension, the asynchronous reference state dimension, and the sub-resource relationship dimension; the multiple resource categories include at least: The first category corresponds to resources that are asynchronously referenced by the GPU command queue; The second category corresponds to resources created and owned by external systems, which the application layer only has borrowing rights for. These external systems are window systems or exchange chains in real-time rendering scenarios, cluster schedulers in scientific computing scenarios, and file systems or distributed storage in offline rendering scenarios. The third category corresponds to proxy resources that have native objects outside the packaging but do not hold ownership of the underlying resources.

[0026] As can be seen, the core basis for classification is not the API type of the resource (such as the object handle VkBuffer representing a linear data buffer in the Vulkan API, the unsigned integer identifier GLuint representing a Buffer object in the OpenGL API, the object MTLBuffer representing a GPU memory buffer in the AppleMetal API, or the pointer type CUDeviceptr representing a device-side memory address in the NVIDIA CUDA API), nor the pipeline source of the resource (graphics / computation / ray tracing), nor the application scenario (real-time / offline / scientific computing), but rather three core attributes of the resource when it is destroyed: ownership, asynchronous reference state, and sub-resource relationship. Ownership indicates who created and owns the resource; asynchronous reference state indicates whether the resource might be referenced by the GPU command queue; and sub-resource relationship indicates whether the resource contains other sub-resources that need to be released first. Based on these three dimensions, this embodiment classifies GPU resources into the following eight categories: Category 1: GPUData (1), classified based on the fact that it may be asynchronously referenced by the GPU command queue and needs to wait for the GPU to complete its use; Category 2: Descriptive (2), classified based on the metadata describing other resources, which is not directly and asynchronously referenced by the GPU; Category 3: Lightweight (3), classified based on no dependency relationship, not asynchronously referenced by the GPU, and no child resources; Category 4: Pool (4), classified based on the presence of allocable sub-resources, which must wait for all sub-resources to be released before they can be destroyed; Category 5: SyncObject(5), classified based on cross-queue / cross-pipeline synchronization primitives, requires checking whether the application layer holds ownership; Category 6: HybridDependency (15), classified based on cross-frame / cross-step dependency, containing references to "externally owned" resources; Category 7: SwapchainExclusive (20), classified based on being created and owned by an external system (window system / cluster scheduler / file system), with the application layer only having borrowing rights and not being allowed to destroy the underlying object; Category 8: SwapchainProxy (25) is classified based on wrapping external native resources, providing a unified interface but not holding ownership of the underlying resources.

[0027] For example, in real-time rendering scenarios, resources from three different APIs—Vulkan's VkBuffer, OpenGL's GLuint Buffer, and Metal's MTLBuffe—may all be asynchronously referenced by the GPU command queue. In this embodiment, they are uniformly categorized into Category 1, GPUData, and a delayed destruction strategy is adopted. Similarly, in offline rendering scenarios, the geometry cache of the render farm (which may be asynchronously referenced by multiple render passes) and the texture pyramid (referenced by different passes at different LOD levels) are also categorized into Category 1, GPUData, using the same delayed destruction logic; the only difference is that the frame number is replaced with the render pass number. Furthermore, in scientific computing scenarios, CUDA's Device Buffer (asynchronously referenced by the compute kernel) and deep learning inference's Tensors are also categorized into Category 1, GPUData; while GPU resources allocated by the cluster scheduler are categorized into Category 7, SwapchainExclusive, where compute nodes only unregister their local handles and do not release cluster resources.

[0028] Before obtaining the destruction control policy in step S2, the corresponding destruction control policy is bound to each resource category during resource object construction through the policy binding mechanism, including: During resource object construction, a virtual function mechanism is used to bind a corresponding destruction control strategy to each resource category, ensuring that GPU resources belonging to the same resource category have the same destruction control strategy determined at compile time. In this embodiment, the compile-time binding of the strategy and category specifically includes: In the constructors of resource subclasses, `getCategory()` and `getDestructionStrategy()` are virtual functions. For example: `BufferResource::getCategory()` always returns `ResourceCategory::GPUData`; `BufferResource::getDestructionStrategy()` always returns `DestructionStrategy::Deferred`; `SwapchainTextureResource::getCategory()` always returns `ResourceCategory::SwapchainProxy`; `SwapchainTextureResource::getDestructionStrategy()` always returns `DestructionStrategy::UnwrapOnly`. This binding is determined at compile time, and the correct destruction strategy can be obtained at runtime through the base class pointer call. There is no need to maintain an additional mapping table, nor is it necessary to perform branching based on API type, pipeline type, application scenario, operating system, or CPU architecture.

[0029] Based on this, step S2 involves obtaining the destruction control strategy, acquiring the corresponding bound destruction control strategy according to the resource category. The destruction control strategy includes: The delayed destruction strategy corresponds to the first category; Corresponding to the second category of handle-only cancellation strategy, during execution, the handle of the resource is only cancelled from the unified handle manager, without calling the destruction function of the underlying GPU programming interface; Corresponding to the third category of unpacking strategies, the mapping relationship between proxy resources and native objects is released during execution without destroying the underlying native objects.

[0030] It also includes at least one of the following: immediate destruction strategy, idle waiting destruction strategy, and ownership check destruction strategy.

[0031] In this embodiment, the destruction strategy is defined in an API-independent abstract form, and during execution, the actual destruction interface of the underlying API is called through a virtual function. The correspondence between resource types and destruction control strategies in this embodiment is as follows: Furthermore, the determination of the aforementioned resource categories and the acquisition of the destruction control strategy are implemented through the standard extension layer of the GPU programming interface, providing a unified resource lifecycle management API entry point for the application layer.

[0032] Next, the destruction scheduling process in step S3 is performed in the third-layer ring frame / task queue scheduler. In step S3, the target scheduling cycle number is calculated using the following formula: , in, The target scheduling cycle number indicates the scheduling cycle in which the delayed destruction entry can be safely destroyed; The current scheduling cycle number indicates the scheduling cycle when the delayed destruction entry is generated and added to the circular buffer structure; This is a safety delay value, a preset non-negative integer. Its value is configured based on the synchronization characteristics of the underlying GPU programming interface, the concurrency of the command processing pipeline, or the time characteristics of the application scenario.

[0033] The circular buffer structure is a circular array with a fixed number of slots, which is equal to the maximum number of concurrent scheduling cycles allowed. This ensures that when the current scheduling cycle number grows to cover an old slot that has already been used, all delayed destruction entries in the old slot that meet the preset expiration conditions have been processed.

[0034] The scheduling cycle number is the frame number in real-time rendering applications, the rendering pass number in offline rendering applications, and the iteration step number in general computing applications.

[0035] The data structure of the ring frame / task queue scheduler is shown below: / / FRAME_OVERLAP / STEP_OVERLAP is the maximum number of concurrent frames / steps allowed, set to 6 (configurable); A circular array [FRAME_OVERLAP] = each element is a queue of resources to be destroyed; Each slot corresponds to a resource to be destroyed generated in one frame / iteration step. The index of the current frame / step is calculated using the current frame number % FRAME_OVERLAP.

[0036] The following is an example of the delayed destruction entry structure (API-independent definition): DeferredDestructionEntry { type; / / Resource type (Buffer / Texture / Framebuffer / AS / Tensor / ...) nativeHandle; / / The native resource handle (opaque pointer / integer) of the underlying API. allocation; / / Associated memory allocation handle (optional) secondaryHandle; / / Secondary handle (e.g., ImageView, optional) targetFrame; / / Total target frame number / step number for safe destruction frameIndex; / / Frame / step index when enqueuing (used for verification) category; / / Resource category (used for runtime validation) name; / / Debug name }

[0037] Based on this, a scheduling algorithm (processDeferredDestruction) is implemented. In each scheduling cycle, all slots in the circular array are traversed, and each item to be destroyed stored in the queue of each slot is checked one by one: if the target frame number or target step number (targetFrame) of an item is less than or equal to the current total frame number or total step number, it indicates that the resource has met the safe destruction conditions. Then, the corresponding underlying API destruction function is selected according to the resource type (type) recorded in the item, the function is called to perform the actual GPU resource destruction operation, and the item is removed from the queue; if the target frame number or step number is greater than the current total frame number or step number, the item is kept in the queue for further checking and processing in subsequent scheduling cycles.

[0038] When the total number of frames / steps exceeds FRAME_OVERLAP, new frames / steps will cyclically overwrite the slots of old frames / steps. Since the queue of old slots has been cleared by the scheduling algorithm before overwriting (targetFrame has been reached), circular overwriting is safe.

[0039] The `targetFrame / step` is calculated as follows: `targetFrame = total frame number / step number at enqueue + SAFE_LATENCY`. `SAFE_LATENCY` can be configured based on the synchronization characteristics of the underlying API: explicit APIs (such as Vulkan) are typically set to 2-3 frames, implicit APIs (such as OpenGL) are typically set to 1-2 frames, and offline rendering can be set to 1 pass. Generally, in real-time rendering, `targetFrame` is the frame number; in offline rendering, `targetFrame` is the rendering pass number; and in scientific computing, `targetFrame` is the iteration step number. The core logic of the scheduler is completely consistent, only the time unit differs.

[0040] Secondly, nativeHandle is an opaque type (uint64_t or pointer in Vulkan, GLuint in OpenGL, and CUdeviceptr in CUDA). When destroyed, it calls the corresponding underlying API destruction function through a virtual function, and the scheduler itself is unaware of the specific API type.

[0041] Figure 3 This demonstrates the complete lifecycle of three GPU resources (Buffer A from the Vulkan graphics pipeline running on x86 / Linux for real-time rendering, Accelerated Structure B from the Metal ray tracing pipeline running on ARM / macOS for offline rendering, and Tensor C from the CUDA computing pipeline running on RISC-V / Linux for scientific computing) from different APIs, pipelines, application scenarios, operating systems, and CPU architectures, all within the same circular queue. All three are scheduled uniformly within the same circular queue, with completely consistent scheduling logic. Upon creation, each resource's targetFrame / Step is calculated as: targetFrame / Step = current sequence number at enqueue + SAFE_LATENCY, and it is pushed into the slot corresponding to the current sequence number % 6. Each frame / step / Pass calls processDeferredDestruction() to traverse all slots, calling the corresponding underlying API destruction function and removing the resource that has reached the target sequence number. The entire process is consistent regardless of API type, pipeline origin, application scenario, operating system, or CPU architecture.

[0042] Building upon the methods described above, the method further includes a fourth layer: a unified handle manager, which uses a templated handle manager to uniformly manage the references to GPU resources and trigger the destruction process. The reference counting detection interface manages references to all types of GPU resources, maintains a bidirectional mapping between handle identifiers and smart pointers, and monitors reference counts. When a reference count is detected indicating that the GPU resource is held solely by the unified handle manager itself, meaning that all external references to the GPU resource have been released, the acquisition and execution of the control destruction policy are automatically triggered.

[0043] Specifically, to uniformly manage GPU resources of different APIs and types, this invention provides a templated unified handle manager, with the following structural example: HandleManager<HandleType, ResourceType> { / / Bidirectional mapping: handle ID ↔ shared_ptr <resourcetype> Handle to resource mapping table; Native handle to resource mapping table; / / Register resources registerResource(shared_ptr <resourcetype>resource) → HandleType / / Obtain resources via handle getResource(HandleType handle) → shared_ptr <resourcetype> / / Automatic cleanup: Check if the shared_ptr is held only by the manager cleanup() { For each resource in the mapping table: If resource.use_count() == 1: / / Only the manager holds it Mark as destructible and trigger the corresponding destruction policy. } }

[0044] This embodiment implements non-intrusive reference counting detection using `std::shared_ptr::use_count()==1` (or `unique()`). The application layer can freely hold the `shared_ptr` of the resource. When the application layer releases the reference, the manager automatically detects and triggers the destruction process. This mechanism is completely independent of the underlying API type, pipeline type, application scenario, operating system, and CPU architecture, making it rely solely on the smart pointer semantics of the C++ standard library.

[0045] The method also includes a fifth-layer resource validation subsystem (ResourceValidator): Verify at least one of the following during each scheduling cycle or in response to a resource state change: The destruction control policy currently assigned to a GPU resource is consistent with the resource category to which it belongs; Does the circular buffer structure contain expired entries whose target scheduling cycle number is less than the current scheduling cycle number but have not yet been processed? The correctness of the ownership of externally owned resources.

[0046] In this embodiment, the fifth-layer resource validation subsystem (ResourceValidator) includes a set of runtime resource validators that can automatically detect resources in debug mode, including: Category consistency verifies whether the actual category and policy binding of each resource match its type (e.g., Buffer must be GPUData+Deferred, Swapchain texture must be SwapchainProxy+UnwrapOnly). Cross-reference integrity: Verify the integrity of the two-way mapping between ImageView and Texture; Queue health status: Detects whether there are expired and unprocessed entries in the circular queue (targetFrame is less than the current total number of frames / steps but is still in the queue). Verify the correctness of ownership attribution, ensuring that externally owned resources are only deregistered / unpacked and not incorrectly passed to the underlying destruction API; Resource leak detection monitors the total size of the delayed destruction queue and detects whether there is a continuous growth trend.

[0047] comprehensive Figure 2 The multi-layered architecture described above demonstrates that, regardless of whether GPU resources originate from Vulkan or CUDA, from the graphics pipeline or the compute pipeline, are used for game rendering or scientific computing, or run on Linux / x86 or Android / ARM, all converge to the first-layer classification system. Classification considers only three dimensions: ownership, asynchronous reference state, and sub-resource relationships. This is followed by a strategy binding layer, a circular queue scheduling layer, and a unified handle manager layer, ultimately calling the underlying destruction function through an API-independent abstract interface. A runtime verification layer provides end-to-end health checks. The entire system relies solely on the C++ standard library and is completely decoupled from the operating system, CPU architecture, and GPU driver.

[0048] Based on all the methods described above, this embodiment also provides a cross-API, cross-platform GPU resource lifecycle management system, including: The resource classification module is used to determine the resource category of a GPU resource based on its destruction dependency topology when creating the GPU resource, and to store the data representing the resource category in the corresponding resource object. The determination of the resource category is independent of the underlying GPU programming interface type, command processing pipeline type, application scenario type, operating system type, and central processing unit instruction set architecture type from which the GPU resource originates. The strategy acquisition module is used to acquire the destruction control strategy bound to the resource category from the destruction control strategy set, wherein the destruction control strategy set includes at least a delayed destruction strategy. The circular buffer scheduling module is used to generate a delayed destruction entry and add the entry to the slot corresponding to the current scheduling cycle number in the circular buffer structure when the obtained destruction control policy is a delayed destruction policy. The delayed destruction entry contains at least the identifier of the GPU resource and the target scheduling cycle number. In each scheduling cycle, the module traverses each slot of the circular buffer structure and performs resource destruction on the delayed destruction entries whose target scheduling cycle number meets the preset expiration condition. If it is another destruction control policy, the module performs the corresponding destruction process.

[0049] Example 2

[0050] In a real-time rendering application using the Vulkan API, both a graphics rendering pipeline and a ray tracing pipeline exist, running on an x86 / Linux platform. The graphics pipeline creates texture resources (Texture A) and framebuffers (Framebuffer B), while the ray tracing pipeline creates acceleration structures (Acceleration Structure C) and ray tracing pipeline state objects (RT Pipeline D). The resource manager of this invention provides a unified classification of these resources: Texture A: is asynchronously referenced by the graphics pipeline, classified as being included in GPUData, and its bound destruction control policy, Deferred policy, is obtained; Framebuffer B: Contains MSAA attachments, has cross-frame dependencies, is classified as HybridDependency, and obtains its bound destruction control policy, Deferred policy; Acceleration Structure C: Asynchronously referenced by the ray tracing pipeline, classified as being included in GPUData, and its bound destruction control policy, Deferred policy, is obtained; RT Pipeline D: Not directly referenced asynchronously by the GPU, has no child resources, is classified as Descriptive, and obtains its bound destruction control policy, Immediate policy.

[0051] When the application layer releases its reference to Acceleration Structure C, HandleManager detects that use_count() == 1, triggering the delayed destruction process: a DeferredDestructionEntry is constructed, targetFrame is set to the current frame + 6, and it is pushed into the circular queue slot. After 6 frames, the scheduler calls Vulkan's vkDestroyAccelerationStructureKHR to complete the actual destruction. RT Pipeline D, because it is bound to the Immediate strategy, directly calls vkDestroyPipeline for immediate destruction when the reference count reaches zero, without entering the circular queue.

[0052] In this embodiment, all resource management logic uses only C++ standard library features and does not rely on any Linux-specific system calls or x86-specific CPU instructions.

[0053] In this embodiment, the application instance is tested and verified within the graphics rendering pipeline resource management scenario: The test consisted of 30 frames, covering all 8 resource categories and 6 destruction strategies. During initialization, the system automatically created 18 HandleManager instances to manage different types of GPU resources. During Swapchain initialization (the core technology mechanism for managing frame buffers), the system correctly distinguished between externally owned resources and self-owned resources: Swapchain ImageView: marked with owns=false, swapchain=true, classified as SwapchainExclusive; Swapchain Semaphore / Fence: marked with owns=false, classified as SwapchainExclusive; Swapchain Proxy Texture: created with view=0 (no independent view), classified as SwapchainProxy; Depth Texture: marked with owns=true, swapchain=false, classified as GPUData.

[0054] The system performed a complete lifecycle test on 8 resource types, covering creation, classification, and destruction. Sixteen Buffer resources asynchronously referenced by the GPU command queue were created, categorized into Category 1 (GPUData), and bound to a delayed destruction strategy; all 16 were safely destroyed. Five Texture resources were created, also categorized into Category 1, and all five were safely destroyed. One Sampler resource with no dependencies was created, categorized into Category 3 (Lightweight), and bound to an immediate destruction strategy; this one was immediately reclaimed. One Semaphore and one Fence, both synchronization primitives, were created, categorized into Category 5 (SyncObject), and bound to an ownership check strategy; both were correctly destroyed after confirming ownership at the application layer. One RenderPass and one PipelineLayout descriptive resource were created, categorized into Category 2 (Descriptive), and bound to an immediate destruction strategy; both were immediately reclaimed. One CommandPool containing allocable sub-resources and two DescriptorPools were created, categorized into Category 4 (Pool), and bound to a wait-for-idle strategy; both were destroyed after GPU global synchronization and confirmation that all sub-resources had been released. The classification, policy binding, and destruction results of all 8 categories and a total of 29 GPU resources were consistent, the number of leaks was zero, and all test items passed.

[0055] In the tests, the Deferred strategy was precisely timed verified. The test logs showed that a buffer was created and requested to be destroyed in frame 80, and the system accurately predicted that its actual destruction command would be executed in frame 87 (80 + 6 + 1), demonstrating the accuracy and predictability of the circular queue scheduler.

[0056] In addition, the system underwent security handling capability tests for four typical abnormal scenarios. In the double destruction protection test, the system handled two consecutive calls to the destruction operation for the same resource securely, without duplicate release or program crash. In the invalid handle security test, the system ignored the invalid request when an invalid or uninitialized handle was called to the destruction interface, without generating any exceptions. In the cross-type handle security test, a buffer handle was intentionally passed to the texture destruction interface; the system intercepted the type at compile time, eliminating runtime risks caused by type errors. In the post-destruction handle reuse test, a new resource was created and a handle was allocated immediately after the resource was destroyed; the system ensured that the newly allocated handle was inconsistent with the reclaimed old handle, avoiding dangling pointers and handle conflicts. All four negative tests passed with zero errors and zero crashes, verifying the system's good robustness and security under abnormal conditions.

[0057] Example 3

[0058] In a certain cross-platform 3D engine, Vulkan is used on Windows / x86, Metal on macOS / ARM, OpenGL ES on Android / ARM, and Vulkan on RISC-V / Linux. The engine uses the unified resource manager of this invention.

[0059] Specifically, on the Vulkan side (Windows / x86): a VkBuffer is created, classified as GPUData according to the resource classification system, its bound destruction control policy is obtained as the Deferred policy, it enters the circular queue scheduling, and finally calls vkDestroyBuffer; on the Meta side (macOS / ARM): an MTLBuffer is created, classified as GPUData according to the resource classification system, its bound destruction control policy is obtained as the Deferred policy, it enters the circular queue scheduling, and finally calls [buffer release]; on the OpenGL ES side (Android / ARM): a GLuint Buffer is created, classified as GPUData according to the resource classification system, its bound destruction control policy is obtained as the Deferred policy, it enters the circular queue scheduling, and finally calls glDeleteBuffers; on the Vulkan side (RISC-V / Linux): a VkBuffer is created, classified as GPUData according to the resource classification system, its bound destruction control policy is obtained as the Deferred policy, it enters the circular queue scheduling, and finally calls vkDestroyBuffer.

[0060] The four platforms use the exact same classification logic and scheduling algorithm, differing only in the underlying destruction function and compilation target. The core code of the resource manager is shared across APIs, OSes, and ISAs, eliminating the need for separate implementations for each platform.

[0061] Example 4

[0062] In a cinematic offline rendering system, rendering tasks are distributed across multiple compute nodes (a hybrid cluster of x86 / Linux and ARM / macOS). Each rendering pass can last for several hours, involving the creation and destruction of thousands of GPU resources, specifically including: Geometry cache: May be asynchronously referenced by multiple Passes, categorized as GPUData, obtain the Deferred policy bound to this category, targetPass = current Pass + SAFE_LATENCY; Texture pyramid: Different LOD levels are referenced by different Passes, classified as GPUData, and the Deferred strategy bound to this classification is obtained; Render output buffer: owned by the distributed file system, borrowed only by local nodes, classified as an externally owned proxy class, obtains the UnwrapOnly policy bound to this class, only unpacks without destroying file system resources; Shader module: Used once after loading and no longer needed, categorized as Lightweight, and obtains the Immediate strategy bound to this category; The circular queue scheduler replaces the frame number with the pass number, while the core scheduling logic remains unchanged. SAFE_LATENCY can be configured to 1 (there is usually no concurrency between passes in offline rendering), and resources are safely destroyed before the next pass begins.

[0063] In this embodiment, the resource manager runs the same code on both x86 and ARM nodes, without any platform adaptation required.

[0064] Example 5

[0065] In a molecular dynamics simulation framework, GPU-accelerated computation is performed using the CUDA API, running on a RISC-V / Linux cluster environment. Temporary storage buffers and tensor resources are created for each simulation iteration step.

[0066] In this scenario, Storage Buffer: is asynchronously referenced by the computation pipeline, classified as GPUData, and its Deferred policy is obtained. It is destroyed in the safe window after the iteration step is completed; Model Weight Tensor: is shared by multiple iteration steps and has cross-step dependencies, classified as HybridDependency, and its Deferred policy is obtained; Temporary Working Buffer: is used only in the current iteration step, classified as Lightweight, and its Immediate policy is obtained.

[0067] In a clustered environment, GPU resources are allocated by the scheduler. Compute nodes only have borrowing rights to GPU resources, and when destroyed, they use an externally owned exclusive unregisterOnly strategy, meaning they are only deregistered from the local handle manager and the cluster-allocated resources are not released.

[0068] Example 6

[0069] In an application that performs real-time rendering and deep learning inference simultaneously, the GPU runs both the graphics pipeline and the compute pipeline on an ARM / Android mobile platform.

[0070] In this scenario, textures created by the rendering pipeline are categorized as GPUData, and their destruction control policy is Deferred; inference buffers created by the computation pipeline are categorized as GPUData, and their destruction control policy is Deferred; buffers shared by both pipelines are categorized as GPUData, and their destruction control policy is Deferred (a unified policy, regardless of pipeline origin); inference model weights are "owned" by the model manager, only borrowed by the rendering module, categorized as SwapchainProxy, and their destruction control policy is UnwrapOnly.

[0071] As can be seen, the resources of both pipelines are scheduled uniformly within the same circular queue, eliminating the need for two separate sets of management logic. The runtime code on the ARM mobile platform is exactly the same as that on the x86 desktop platform, only the compilation target differs.

[0072] Example 7

[0073] In a general matrix multiplication (GEMM) computation application using the Vulkan API, the system runs on a RISC-V / Linux platform and utilizes the GPU's computation pipeline to perform large-scale matrix operations. The matrix size is 512×512×512, and the block size is 256×256.

[0074] The resource manager of this invention enables unified classification and management of computing pipeline resources: Input matrix buffers A / B (TileGpuA, TileGpuB, each 524288 bytes): are asynchronously referenced by the computation pipeline, classified as GPUData(1), and their bound destruction control policy is the Deferred policy, which delays destruction after computation. Output matrix buffer C (TileGpuC, 262144 bytes): is asynchronously referenced by the compute pipeline, classified as GPUData(1), and its bound destruction control policy is the Deferred policy; Compute pipeline objects (GEMMPass_Pipeline, TiledGEMM_Pipeline): Metadata describing other resources, classified as Descriptive(2), and the destruction control policy bound to them is obtained as Immediate policy; Shader module (GEMMPass_CS, TiledGEMM_CS, 21232 bytes): No dependency, classified as Lightweight(3), and its bound destruction control policy is Immediate policy; Descriptor set layout (GEMMPass_Layout, TiledGEMM_Layout): No dependency relationship, classified as Lightweight(3), and its bound destruction control strategy is the Immediate strategy; Command buffer (GEMM_Warmup, TileCmd): Managed by the command pool, classified as Pool(4), and its bound destruction control policy is WaitIdle policy; Synchronization object (TileFence): Cross-queue synchronization, classified as SyncObject(5), and its bound destruction control strategy is the CheckOwnership strategy.

[0075] In this embodiment, GPGPU general-purpose computing pipeline resource management is tested. General Matrix Multiplication (GEMM) is performed using the Vulkan computing pipeline, with a matrix size of 512×512×512 and a block size of 256×256. The system automatically and correctly categorizes all resources in the GEMM computing scenario as follows: The system automatically detects hardware queue capabilities and adopts the optimal parallel strategy. Independent resource sets are created for each of the four pipeline stages, and all resources are handled and managed for lifecycle by a unified HandleManager. The Tiled GEMM operation on a 512×512×512 matrix is ​​completed within 124.577 milliseconds, with a maximum numerical error of only 6.675720e-06, meeting the precision requirements of scientific computing. After testing, the system executed a 14-step ordered destruction process. Logs show that all computing resources were safely destroyed in the correct order, including: 4 Buffers (GPUData, delayed destruction), 4 DescriptorSets (Pool, destroyed after awaiting reclamation), 4 Command Buffers (Pool, destroyed after awaiting reclamation), 4 Fences (SyncObject, destroyed after checking ownership), and lightweight / descriptive resources such as Pipeline and ShaderModule (immediately destroyed). The entire destruction process was error-free and leak-free.

[0076] Although this test was conducted in a pure GPGPU computing scenario (without any rendering operations), the system reused the exact same 18 HandleManager instances, Device initialization process, and circular queue scheduler used for graphics rendering. Computational pipeline resources and graphics pipeline resources used the exact same classification criteria and scheduling algorithms. Therefore, it is demonstrated that the classification system of this invention is equally effective in a pure GPGPU scenario with no graphics pipeline, can run directly on the RISC-V architecture without adaptation, and the ownership model of cluster resources is isomorphic to the ownership model of Swapchain, verifying the core claims of this invention: API independence, pipeline independence, OS independence, and ISA independence.

[0077] It should be noted that the steps in the cross-API, cross-platform GPU resource lifecycle management method provided in this embodiment can be implemented based on the corresponding modules in the cross-API, cross-platform GPU resource lifecycle management system. Those skilled in the art can refer to the technical solution of the system to implement the steps of the method. That is, the embodiments in the system can be understood as preferred examples of implementing the method, and will not be elaborated here.

[0078] Besides implementing the system and its various devices provided by this invention in purely computer-readable program code, the same functions can be achieved by logically programming the method steps, making the system and its various devices of this invention appear as logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, the system and its various devices provided by this invention can be considered as a hardware component, and the devices included therein for implementing various functions can also be considered as structures within the hardware component; alternatively, the devices for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0079] Finally, it should be noted that the above description is only a preferred embodiment of the present invention, and the scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be pointed out that for those skilled in the art, any improvements and modifications made without departing from the principle of the present invention should also be considered within the scope of protection of the present invention.

[0080] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.< / resourcetype> < / resourcetype> < / resourcetype>

Claims

1. A cross-API, cross-platform GPU resource lifecycle management method, characterized in that, Includes the following steps: S1: When creating GPU resources, the resource category is determined based on the destruction dependency topology of the GPU resource, and the data representing the resource category is stored in the corresponding resource object. The determination of the resource category is independent of the underlying GPU programming interface type, command processing pipeline type, application scenario type, operating system type, and central processing unit instruction set architecture type from which the GPU resource originates. S2: Obtain the destruction control policy bound to the resource category from the destruction control policy set, wherein the destruction control policy set includes at least a delayed destruction policy; S3: When the obtained destruction control strategy is a delayed destruction strategy, a delayed destruction entry is generated and added to the slot corresponding to the current scheduling cycle number in the circular buffer structure. The delayed destruction entry contains at least the identifier of the GPU resource and the target scheduling cycle number. In each scheduling cycle, each slot of the circular buffer structure is traversed, and resource destruction is performed on the delayed destruction entries whose target scheduling cycle number meets the preset expiration condition. If it is another destruction control strategy, the corresponding destruction process is performed.

2. The cross-API, cross-platform GPU resource lifecycle management method according to claim 1, characterized in that, In step S1, the destruction dependency topology is determined by the ownership dimension, the asynchronous reference state dimension, and the sub-resource relationship dimension; the multiple resource categories include at least: The first category corresponds to resources that are asynchronously referenced by the GPU command queue; The second category corresponds to resources created and owned by external systems, which the application layer only has borrowing rights for. These external systems are window systems or exchange chains in real-time rendering scenarios, cluster schedulers in scientific computing scenarios, and file systems or distributed storage in offline rendering scenarios. The third category corresponds to proxy resources that have native objects outside the packaging but do not hold ownership of the underlying resources.

3. The cross-API, cross-platform GPU resource lifecycle management method according to claim 2, characterized in that, In step S2, the destruction control strategy includes: The delayed destruction strategy corresponds to the first category; Corresponding to the second category of handle-only cancellation strategy, during execution, the handle of the resource is only cancelled from the unified handle manager, without calling the destruction function of the underlying GPU programming interface; Corresponding to the third category of unpacking strategies, the mapping relationship between proxy resources and native objects is released during execution without destroying the underlying native objects.

4. It also includes at least one of the following: immediate destruction strategy, idle waiting destruction strategy, and ownership check destruction strategy.

5. The cross-API, cross-platform GPU resource lifecycle management method according to claim 1, characterized in that, In step S2, before obtaining the destruction control policy bound to the resource category, the following is also included: During the construction of resource objects, a virtual function mechanism is used to bind a corresponding destruction control strategy to each resource category, so that GPU resources belonging to the same resource category can determine the same destruction control strategy at compile time.

6. The cross-API, cross-platform GPU resource lifecycle management method according to claim 1, characterized in that, The determination of the resource category and the acquisition of the destruction control strategy are implemented through the standard extension layer of the GPU programming interface, providing a unified resource lifecycle management API entry point for the application layer.

7. The cross-API, cross-platform GPU resource lifecycle management method according to claim 1, characterized in that, In step S3, the target scheduling cycle number is calculated using the following formula: ， in, The target scheduling cycle number indicates the scheduling cycle in which the delayed destruction entry can be safely destroyed; The current scheduling cycle number indicates the scheduling cycle when the delayed destruction entry is generated and added to the circular buffer structure; This is a safety delay value, a preset non-negative integer. Its value is configured based on the synchronization characteristics of the underlying GPU programming interface, the concurrency of the command processing pipeline, or the time characteristics of the application scenario.

8. The cross-API, cross-platform GPU resource lifecycle management method according to claim 1, characterized in that, In step S3, the ring buffer structure is a ring array with a fixed number of slots, which is equal to the maximum number of concurrent scheduling cycles allowed, so that when the current scheduling cycle number grows to cover the old slots that have been used, all delayed destruction entries in the old slots that meet the preset expiration conditions have been processed.

9. The cross-API, cross-platform GPU resource lifecycle management method according to claim 1, characterized in that, The method also includes using a templated handle manager to uniformly manage the references to GPU resources and trigger the destruction process: The reference counting detection interface manages references to all types of GPU resources, maintains a bidirectional mapping between handle identifiers and smart pointers, and monitors reference counts. When a reference count is detected indicating that the GPU resource is held solely by the unified handle manager itself, meaning that all external references to the GPU resource have been released, the acquisition and execution of the control destruction policy are automatically triggered.

10. The cross-API, cross-platform GPU resource lifecycle management method according to claim 1, characterized in that, The method further includes: Verify at least one of the following during each scheduling cycle or in response to a resource state change: The destruction control policy currently assigned to a GPU resource is consistent with the resource category to which it belongs; Does the circular buffer structure contain expired entries whose target scheduling cycle number is less than the current scheduling cycle number but have not yet been processed? The correctness of the ownership of externally owned resources.

11. The cross-API, cross-platform GPU resource lifecycle management method according to claim 1, characterized in that, The scheduling cycle number is the frame number in real-time rendering applications, the rendering pass number in offline rendering applications, and the iteration step number in general computing applications.

12. A cross-API, cross-platform GPU resource lifecycle management system, characterized in that, include: The resource classification module is used to determine the resource category of a GPU resource based on its destruction dependency topology when creating the GPU resource, and to store the data representing the resource category in the corresponding resource object. The determination of the resource category is independent of the underlying GPU programming interface type, command processing pipeline type, application scenario type, operating system type, and central processing unit instruction set architecture type from which the GPU resource originates. The strategy acquisition module is used to acquire the destruction control strategy bound to the resource category from the destruction control strategy set, wherein the destruction control strategy set includes at least a delayed destruction strategy. The circular buffer scheduling module is used to generate a delayed destruction entry and add the entry to the slot corresponding to the current scheduling cycle number in the circular buffer structure when the obtained destruction control policy is a delayed destruction policy. The delayed destruction entry contains at least the identifier of the GPU resource and the target scheduling cycle number. In each scheduling cycle, the module traverses each slot of the circular buffer structure and performs resource destruction on the delayed destruction entries whose target scheduling cycle number meets the preset expiration condition. If it is another destruction control policy, the module performs the corresponding destruction process.

Images