Cloud mobile phone GPU virtualization time division multiplexing method and related equipment

Abstract

The invention discloses a cloud mobile phone GPU virtualization time division multiplexing method and related equipment, and relates to the technical field of cloud mobile phones, and the method comprises the steps: obtaining a plurality of concurrent tasks submitted by a cloud mobile phone platform; performing feature analysis on the concurrent tasks to obtain task types and real-time requirements of the concurrent tasks; dividing the physical GPU into a plurality of virtual GPU units based on task types and real-time requirements; based on the task type, allocating a time slice and a computing resource for each virtual GPU unit; and under a hardware-level video memory isolation mechanism, alternately executing a plurality of concurrent tasks through the virtual GPU unit. Through GPU virtualization and time division multiplexing, dynamic splitting and scheduling of resources can be realized, and efficient concurrency of heterogeneous tasks and security isolation of data are considered.

Description

Technical Field

[0001] This application relates to the field of cloud phone technology, and more specifically, to a cloud phone GPU virtualization time-sharing multiplexing method and related equipment. Background Technology

[0002] With the continuous development of cloud computing and mobile terminal virtualization technologies, cloud phones, as an innovative form that integrates mobile computing and remote services, are being widely used in various fields such as application testing, mobile office, cloud gaming, and centralized management of smart terminals. In cloud phone systems, the GPU (Graphics Processing Unit) is a key computing resource, undertaking high-load tasks such as graphics rendering, image processing, and AI computing. Its performance and scheduling strategies directly affect the user experience and overall system performance.

[0003] However, existing cloud phone GPU resource management methods mostly adopt traditional solutions of static partitioning or block allocation, meaning each task or user has exclusive access to a physical GPU resource. This approach easily leads to low GPU resource utilization when task loads are light or operational requirements vary significantly, resulting in a contradiction between idle resources and request congestion. Simultaneously, the lack of a dynamic scheduling mechanism makes it difficult for the system to flexibly allocate resources under conditions of multiple concurrent tasks and significant differences in task types. Furthermore, in scenarios with multiple users running simultaneously, inadequate resource isolation mechanisms can easily lead to data interference between tasks, performance conflicts, and even security vulnerabilities. Especially in high-concurrency, heterogeneous task-intensive cloud phone application scenarios, traditional resource management strategies often fail to meet the simultaneous operational requirements of "high utilization, high real-time performance, and high security." In other words, related technologies suffer from technical problems such as low GPU resource utilization, lack of dynamic task scheduling, and poor data isolation during concurrent operation. Summary of the Invention

[0004] The summary section of this application introduces a series of simplified concepts, which will be further explained in detail in the detailed description section. The summary section of this application is not intended to limit the key features and essential technical features of the claimed technical solution, nor is it intended to determine the scope of protection of the claimed technical solution.

[0005] The cloud phone GPU virtualization time-sharing multiplexing method and related equipment provided in this application can realize dynamic resource splitting and scheduling through GPU virtualization and time-sharing multiplexing, taking into account both efficient concurrency of heterogeneous tasks and data security isolation.

[0006] In a first aspect, this application provides a time-sharing multiplexing method for GPU virtualization in cloud mobile phones, comprising: acquiring multiple concurrent tasks submitted by a cloud mobile phone platform; performing feature analysis on the concurrent tasks to obtain the task type and real-time requirements of the concurrent tasks; dividing the physical GPU into multiple virtual GPU units based on the task type and the real-time requirements; allocating time slices and computing resources to each virtual GPU unit based on the task type; and, under a hardware-level memory isolation mechanism, alternately executing the multiple concurrent tasks through the virtual GPU units.

[0007] In some implementations, the step of performing feature parsing on the concurrent task to obtain the task type and real-time requirements of the concurrent task includes: determining the task type based on the task identifier of the concurrent task, wherein the task type is a rendering task or a computation task; parsing the concurrent task to obtain the frame rate threshold and latency tolerance of the concurrent task; and determining the real-time requirements based on the frame rate threshold and the latency tolerance.

[0008] In some implementations, dividing the physical GPU into multiple virtual GPU units based on the task type and the real-time requirements includes: calculating a partitioning coefficient for the virtual GPU units based on the task type and the real-time requirements; dividing the physical GPU into multiple logical unit groups according to the partitioning coefficient, wherein rendering tasks are bound to low-latency logical unit groups, and computing tasks are bound to high-throughput logical unit groups; allocating independent video memory blocks to each logical unit group through a GPU memory management unit and setting a preset address offset to implement the hardware-level video memory isolation mechanism; and combining the logical unit groups with their corresponding independent video memory blocks to obtain the multiple virtual GPU units.

[0009] In some implementations, allocating time slices and computing resources to each virtual GPU unit based on the task type includes: when the target type feature is a rendering task, allocating a time slice of a first duration threshold and a preset memory weight coefficient to the corresponding virtual GPU unit; when the target type feature is a computing task, allocating a time slice of a second duration threshold and a preset computing unit weight coefficient to the corresponding virtual GPU unit; wherein the first duration threshold is less than the second duration threshold, and the preset memory weight coefficient is greater than the preset computing unit weight coefficient; and allocating computing resources based on the preset memory weight coefficient and the preset computing unit weight coefficient.

[0010] In some implementations, the step of alternately executing the multiple concurrent tasks through the virtual GPU unit includes: allocating an execution period of the corresponding virtual GPU unit to each concurrent task in sequence according to the time slice; within each execution period, scheduling the virtual GPU unit corresponding to the current concurrent task to load and run the corresponding computing instructions and graphics rendering operations; after the current concurrent task is completed or the time slice is exhausted, saving the current task context state and switching to the virtual GPU unit corresponding to the next concurrent task to continue execution.

[0011] In some implementations, the method further includes: in response to a task completion signal, releasing the mapping relationship between the virtual GPU unit and the physical GPU; clearing the video memory area allocated to the virtual GPU unit and releasing the occupied bandwidth resource channel.

[0012] Secondly, this application also provides a cloud phone GPU virtualization time-sharing multiplexing device, comprising: a task acquisition unit, used to acquire multiple concurrent tasks submitted by a cloud phone platform; a task parsing unit, used to perform feature parsing on the concurrent tasks to obtain the task type and real-time requirements of the concurrent tasks; a virtual partitioning unit, used to partition the physical GPU into multiple virtual GPU units based on the task type and the real-time requirements; a resource allocation unit, used to allocate time slices and computing resources to each virtual GPU unit based on the task type; and a task execution unit, used to alternately execute the multiple concurrent tasks through the virtual GPU units under a hardware-level memory isolation mechanism.

[0013] Thirdly, this application also provides an electronic device, including: a memory and a processor, wherein the processor is configured to execute a computer program stored in the memory to implement the steps of the cloud phone GPU virtualization time-sharing multiplexing method described in the first aspect.

[0014] Fourthly, this application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the cloud phone GPU virtualization time-sharing multiplexing method described in the first aspect.

[0015] Fifthly, this application also provides a computer program product, including a computer program or computer executable instructions, which, when executed by a processor, implements the cloud phone GPU virtualization time-sharing multiplexing method provided in the embodiments of this application.

[0016] In summary, this application achieves dynamic partitioning and efficient utilization of physical GPU resources through GPU virtualization and time-sharing multiplexing technologies, thereby improving resource utilization. By dividing virtual GPU units and scheduling them with time slices according to task type and real-time requirements, it can adapt to the performance needs of different task types. Through dynamic allocation of computing resources and time slices, it can achieve efficient concurrent support for heterogeneous tasks such as game rendering and AI inference. The adoption of a hardware-level memory isolation mechanism ensures data security and user privacy protection during multi-task operation. In conclusion, the cloud phone GPU virtualization time-sharing multiplexing method provided in this application achieves dynamic resource partitioning and scheduling through GPU virtualization and time-sharing multiplexing, balancing efficient concurrency of heterogeneous tasks with secure data isolation. Attached Figure Description

[0017] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit this specification. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:

[0018] Figure 1 A flowchart illustrating a cloud phone GPU virtualization time-sharing multiplexing method provided in this application embodiment;

[0019] Figure 2 This application provides a schematic diagram of the composition structure of a cloud phone GPU virtualization time-sharing multiplexing device according to an embodiment of the present application.

[0020] Figure 3 This is a schematic diagram of the composition structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0021] The terms used in the specification, claims, and drawings of this application, such as "first," "second," "third," "fourth," etc. (if any), are used to distinguish similar objects and not to describe a specific order or sequence. Therefore, it is to be understood that these terms can be used interchangeably where appropriate, allowing the described embodiments to be used in different orders, unless specifically required by the illustrations or description. Furthermore, the terms "is" and "has," and any variations thereof, are intended to cover, non-exclusively, all possible constituent elements. For example, a process, method, system, product, or apparatus comprising several steps or units is not necessarily limited to the steps or units explicitly listed, but may also include other steps or units not explicitly listed, or steps or units inherent to the process, method, product, or apparatus.

[0022] In this application, a "module" or "unit" refers to a computer program or part of a computer program that has a specific function and works in conjunction with other related parts to achieve a predetermined goal. These modules or units can be implemented by software, hardware (e.g., processing circuitry or memory), or a combination of both. One or more processors or memories can implement one or more modules or units. Furthermore, each module or unit can also be part of a larger module or unit.

[0023] The technical solutions of this application will be described in detail below with reference to the accompanying drawings of the embodiments. It should be noted that the described embodiments are only a part of this application, and not all embodiments. In the following description, the "some embodiments" mentioned are only a subset of all possible embodiments, which may be the same or different subsets, and different embodiments can be combined with each other without conflict.

[0024] Figure 1 This is a flowchart illustrating a cloud phone GPU virtualization time-sharing multiplexing method provided in an embodiment of this application. For example, see [link to example]. Figure 1 The cloud phone GPU virtualization time-sharing multiplexing method provided in this application embodiment may include the following steps 101 to 104:

[0025] Step 101: Obtain multiple concurrent tasks submitted by the cloud phone platform;

[0026] In some examples, a cloud phone platform refers to a virtual phone service platform built on cloud computing technology. Users can remotely access the platform through local terminals, such as computers, tablets, and mobile phones, to use the virtual phone's computing, storage, and graphics rendering functions. Its core is to provide users with an operating experience consistent with a physical mobile phone through the physical resources of a server cluster, such as GPUs, CPUs, and memory. Multiple concurrent tasks are a set of tasks initiated by different users or the same user and needing to be executed simultaneously within the same time period. These tasks may include various types, such as a game rendering task initiated by user A, an AI inference task initiated by user B, and a video editing task initiated by user C. "Concurrency" emphasizes the overlap of tasks in time, meaning that the execution cycles of multiple tasks overlap and they need to share physical GPU resources. Specifically, this can be achieved through the task receiving interface of the cloud phone platform. This interface listens for user operation requests in real time, such as clicking application icons or triggering calculation instructions, and converts these requests into structured task data. Task data must include at least the following information: a unique task identifier (to distinguish different tasks), the submitting user's identifier (to associate user permissions and service levels), the task initiation time (to record the task sequence), and the original task operation instructions, such as graphics API calls for game rendering or model input data for AI inference. The task acquisition process must meet high real-time requirements, ensuring that user-initiated tasks are captured and recorded by the platform within 10ms to avoid user lag due to delays. Simultaneously, concurrent tasks are temporarily stored through a task buffer queue. The queue length can be dynamically adjusted according to the platform's maximum concurrency support. For example, when supporting 1000 concurrent tasks, the queue capacity is set to 1200 to reserve buffer space and prevent task overflow.

[0027] Implementing step 101 enables real-time detection of task requests from multiple cloud phone users or instances, a prerequisite for supporting unified management and centralized scheduling of GPU resources. By centrally receiving concurrent tasks, the system can perform unified scheduling and load analysis, laying the foundation for subsequent task classification and resource allocation. This ensures the platform has the capability to handle large-scale, high-concurrency tasks, adapting to the diverse needs of cloud phones in applications such as gaming, multimedia, and AI.

[0028] Step 102: Perform feature analysis on concurrent tasks to obtain the task type and real-time requirements of concurrent tasks;

[0029] In some examples, the feature analysis process for concurrent tasks can be divided into two levels: task type identification and real-time requirement quantification. Regarding task type identification, classification can be achieved by analyzing the operation instruction set and data characteristics carried by the task: tasks containing graphics rendering instructions (such as DirectX, Vulkan, and other API calls), frame buffer data, or texture processing requests are classified as rendering tasks. Typical examples of these tasks include 3D games running on cloud phones and live video streaming, whose core requirements are efficient graphics pixel processing and image output. Tasks containing matrix operations, model inference instructions (such as TensorRT engine calls), or batch data processing requests are classified as computation tasks, such as user-initiated AI image recognition and real-time speech transcription, whose core requirements are powerful parallel computing capabilities and data processing throughput. Task type identification is achieved through matching with a pre-defined instruction feature library, which contains typical instruction fingerprints for various tasks. For example, the "DrawCall" instruction frequency for rendering tasks is usually higher than 100 times / frame, while the "GEMM" matrix operation instructions for computation tasks often account for more than 60%. At the level of quantifying real-time requirements, the system extracts key performance indicators to determine the real-time level by analyzing the task's configuration parameters and historical execution data. Frame rate threshold is one important parameter; for example, game task configuration files typically include target frame rates such as "60fps" or "120fps." A higher frame rate threshold indicates a more stringent real-time requirement for screen updates. Latency tolerance is determined by the task's response time limit. For instance, competitive games typically require a latency of no more than 50ms from the issuance of commands to screen feedback, while offline AI inference tasks can tolerate latency exceeding 1000ms. A weighted calculation of frame rate threshold and latency tolerance yields a real-time requirement score (ranging from 0-10, with higher scores indicating a more urgent real-time requirement). For example, a task with a frame rate of 60fps and a latency tolerance of 50ms typically scores 8-9 points, while a task with a frame rate of 30fps and a latency tolerance of 500ms might score 3-4 points. During the parsing process, task feature data needs to be processed in real time to ensure that the time from task reception to parsing completion does not exceed 5ms, so as to avoid affecting the overall process efficiency. The task type (rendering or computation) and real-time requirement score obtained from the parsing will serve as the core input parameters for virtual GPU unit partitioning and resource allocation in step 103, directly affecting the subsequent selection of virtual GPU unit function adaptation and scheduling strategy.

[0030] By implementing step 102, parameters such as task identifier, frame rate threshold, and latency tolerance are analyzed to identify the type and real-time performance of concurrent tasks. This allows for accurate classification based on task characteristics (such as low latency for game rendering and high throughput for AI inference), thereby allocating the most suitable resource scheduling strategy to tasks and improving the targeting of resource allocation and the scheduling efficiency of system operation.

[0031] Step 103: Based on task type and real-time requirements, divide the physical GPU into multiple virtual GPU units;

[0032] In some examples, a physical GPU refers to an actual deployed graphics processing hardware device whose core resources include computing units, video memory, and data transfer bandwidth. These resources are managed uniformly through a hardware interface. For example, a physical GPU with 4096 CUDA cores and 16GB of video memory provides the basic support for all virtual GPU units to be partitioned. The partitioning process based on task type and real-time requirements requires multi-dimensional adaptation. Specifically, for rendering tasks (such as games), due to their high real-time requirements (e.g., a real-time score of 8-10), low latency and frame rate stability must be prioritized. Therefore, during partitioning, faster-responding computing units in the physical GPU (such as SM groups near the memory controller) are split into independent logical unit groups, and the scheduling latency of these logical unit groups is optimized to within 10ms. For computational tasks (such as AI inference), which focus more on computational throughput (a real-time score of typically 3-6), computing units with stronger parallel processing capabilities in the physical GPU (such as SM groups supporting tensor cores) are partitioned into another type of logical unit group. The proportion of computing units in this group can be increased to 60%-80% of the total computing units in the physical GPU, depending on the task requirements. In terms of hardware-level isolation, the partitioning process relies on the GPU's Memory Management Unit (MMU) to achieve memory isolation. Based on the number of virtual GPU units and the memory requirements of the corresponding tasks, independent memory blocks are allocated to each logical unit group. For example, 2GB-4GB of memory is allocated to virtual GPU units for rendering tasks (matching 1080P / 4K rendering requirements), and 1GB-2GB of memory is allocated to virtual GPU units for computational tasks (meeting batch inference data caching needs). Simultaneously, by setting memory address offsets, such as a preset value for the starting address interval of each virtual GPU unit (the offset is typically an integer multiple of 2GB), complete isolation of the memory address spaces of different virtual GPU units is ensured, preventing data leakage or interference caused by address overlap during task execution. The number of virtual GPU units is not fixed but dynamically calculated based on real-time requirement scores and the number of tasks. Assuming there are N concurrent tasks, each task has a real-time score of S1, S2…S… nThe number of partitions, K, must satisfy K≥N, and the sum of the real-time scores corresponding to each virtual GPU unit must not exceed the resource carrying capacity threshold of the physical GPU (e.g., if the threshold of a physical GPU is set to 100, and the scores of three high real-time tasks are 30, 30, and 25 respectively, then K must be at least 3, and the total score must be 85≤100). During the partitioning process, the resource proportion of logical unit groups can also be dynamically adjusted through the virtualization layer (Hypervisor). For example, when the real-time score of a rendering task increases from 8 to 9, the proportion of its corresponding virtual GPU units will increase from 20% to 25% to adapt to higher real-time requirements.

[0033] By implementing step 103, and combining task characteristics to perform virtualization partitioning of GPU resources, a single physical GPU can be dynamically divided into multiple virtual GPU units, achieving fine-grained resource allocation. This step effectively improves the reuse rate of GPU resources, enabling different tasks to run simultaneously on the same GPU. It avoids the resource waste problem caused by traditional block allocation and improves the system's resource utilization and multi-tasking support capabilities through differentiated partitioning strategies.

[0034] Step 104: Allocate time slices and computing resources to each virtual GPU unit based on task type;

[0035] In some examples, a time slice refers to a continuous period of time during which a single virtual GPU unit exclusively occupies physical GPU resources. Its length directly affects the real-time performance and computational efficiency of the task. For rendering tasks (such as games and real-time video rendering), which require high-frequency updates to ensure smoothness (e.g., an update window of approximately 16.7ms per frame for 60fps), shorter but more frequent time slices, such as 10ms-20ms, can be allocated to ensure that the screen response latency is controlled within 50ms through high-frequency switching. For computational tasks (such as AI inference and batch data processing), which rely more on continuous computation to improve throughput (e.g., processing 1024 images in a single inference), longer time slices, such as 100ms-200ms, are allocated to reduce the context saving / restoration overhead caused by task switching (each switch consumes approximately 1-2ms). The specific value of the time slice is determined by a dynamic calculation formula: TimeSlice = Priority × Complexity × LoadFactor. The priority is set to 1.2-1.5 for rendering tasks (0.8-1.0 higher than that for computation tasks). The complexity is dynamically determined based on the instruction density of the task (such as the number of DrawCalls per frame for rendering tasks and the matrix operation scale for computation tasks) (range 1.0-3.0). The load factor is adjusted in real time based on the overall load of the physical GPU (such as 0.8 when the load is 80%) to ensure that the time slice allocation can meet the needs of a single task without causing resource overload. Computational resources encompass the physical GPU core resources that virtual GPU units can access, specifically including compute units (such as streaming multiprocessors, SMs), video memory (used to store textures, model parameters, and other data), and data transfer bandwidth (affecting the data exchange speed between video memory and compute units). The allocation of these three components employs a weighted strategy, with weight coefficients (w1, w2, w3) dynamically set according to the task type: For rendering tasks, since video memory needs to read and write texture data frequently (e.g., approximately 200MB of video memory bandwidth per frame for a 1080P image), the video memory weight w2 is set to 0.4-0.5, the compute unit weight w1 to 0.3-0.35, and the bandwidth weight w3 to 0.2-0.25, prioritizing video memory supply; for computational tasks, which rely heavily on parallel computing, such as tensor core operations in AI inference, the compute unit weight w1 is set to 0.5-0.6, the video memory weight w2 to 0.2-0.3 (sufficient for model parameter storage), and the bandwidth weight w3 to 0.2-0.25, focusing on improving computational throughput.For example, a physical GPU with 4096 CUDA cores, 16GB of video memory, and 200GB / s bandwidth might correspond to 1024 CUDA cores (w1=0.25), 6.4GB of video memory (w2=0.4), and 50GB / s bandwidth (w3=0.25) when allocated to rendering-type virtual GPU units; and 2457 CUDA cores (w1=0.6), 3.2GB of video memory (w2=0.2), and 50GB / s bandwidth (w3=0.25) when allocated to computing-type virtual GPU units. The allocation of time slices and computing resources is not statically fixed, but dynamically adjusted through real-time monitoring of task execution status. Resource usage data (such as compute unit utilization, memory usage, and bandwidth saturation) of virtual GPU units can be collected every 10ms. If the frame rate of a rendering task falls below the target value within its time slice (e.g., from 60fps to 50fps), its time slice length is increased from 10ms to 12ms, and the memory weight w2 is increased to 0.55 to increase memory supply. If the computational efficiency of a computing task decreases within its time slice (e.g., the number of inference operations per second decreases from 100 to 80), the time slice is extended to 120ms, and the compute unit weight w1 is increased to 0.65 to enhance parallel computing capabilities. Furthermore, the allocation process is implemented through the resource scheduling interface of the virtualization layer (Hypervisor), with interface latency controlled within 1ms to avoid resource waste caused by the allocation logic itself.

[0036] By implementing step 104, an appropriate time slice length and resource weight are allocated to each virtual GPU unit according to the requirements of the task, such as memory priority or computing unit priority, thereby achieving a precise match between task and resource capabilities. This not only ensures that real-time tasks can respond in a timely manner, but also ensures the efficient execution of computationally intensive tasks, thereby improving the overall system's task throughput and response performance.

[0037] Step 105: Under the hardware-level memory isolation mechanism, multiple concurrent tasks are executed alternately through virtual GPU units;

[0038] In some examples, hardware-level memory isolation mechanisms are the fundamental guarantee for the alternating execution of tasks. This is implemented through the GPU's Memory Management Unit (MMU). The MMU allocates an independent memory address space for each virtual GPU unit and ensures that the address spaces do not overlap by using preset address offsets, such as multiples of 2GB for the starting memory address of each virtual GPU unit. At the same time, strict access control is set (only the virtual GPU unit currently executing the task is allowed to access its bound memory blocks). For example, when a virtual GPU unit executing a rendering task is executing, the MMU will block its access requests to the memory addresses of computational virtual GPU units. Even if an abnormal instruction occurs, it cannot read or modify the memory data of other virtual GPU units, thus preventing data leakage or interference between tasks at the hardware level. The alternating execution of virtual GPU units is implemented based on the time slices allocated in step 104. The specific process is as follows: according to the time slice scheduling order, the execution rights of the physical GPU are allocated to each virtual GPU unit in turn. During the time slice of a certain virtual GPU unit, the computing units, video memory, bandwidth and other resources of the physical GPU are completely monopolized by that virtual GPU unit to execute the instructions of the corresponding task, such as the DrawCall instruction for rendering tasks and the matrix operation instruction for computing tasks. When the time slice is about to expire (e.g., 1ms remaining), the system triggers the switching mechanism, saves the task context of the current virtual GPU unit (including intermediate results in registers, unfinished data in video memory, the value of the instruction counter, etc.), and then switches the video memory address mapping table through the MMU to switch the physical GPU resources to the address space of the next virtual GPU unit. Then, the task context of the virtual GPU unit is restored so that it can continue execution from the last paused position. For example, the rendering virtual GPU unit has a time slice of 10ms. After completing part of the rendering of a frame within 10ms, the system saves the intermediate results of its pixel shader and switches to the computation virtual GPU unit (time slice 100ms) to perform convolution operations for AI inference. After 100ms, it switches back to the rendering virtual GPU unit to continue the remaining rendering, thus achieving alternation. Different optimization strategies can be adopted for the alternation of different types of tasks. For rendering tasks (with high real-time requirements), the time spent saving and restoring context during alternation is compressed (by using hardware-accelerated context caching, the switching latency is controlled within 2ms) to avoid frame rate fluctuations caused by switching (e.g., ensuring that the rendering interval of each frame for a 60fps task is stable at around 16.7ms). For computation tasks (with high throughput requirements), the continuity of time slices is optimized (e.g., allocating 2-3 consecutive identical time slices to reduce the number of switching) to improve computational efficiency (e.g., executing AI inference tasks continuously for 200ms can reduce computational interruptions caused by switching and increase the throughput of a single inference).The triggering of alternating execution can be controlled collaboratively by a hardware timer and a software scheduler. The timer generates interrupt signals at time slice granularities (e.g., 10ms, 100ms), and the scheduler immediately starts the switching process upon receiving the signal. At the same time, the address isolation status of the MMU can be monitored in real time (the access log is checked every 1ms). If a virtual GPU unit is found to be attempting to access a memory address other than its own, a protection mechanism will be immediately triggered (the execution of the virtual GPU unit will be suspended, and an exception log will be recorded), while maintaining the normal alternation of other virtual GPU units to ensure the effectiveness of the isolation mechanism.

[0039] By implementing step 105, multiple virtual GPU units are driven to execute tasks alternately through time-slice scheduling and context switching mechanisms. Combined with the GPU hardware's memory isolation capabilities, data security and performance isolation are achieved during the parallel execution of multiple tasks. This effectively prevents interference and information leakage between tasks, and improves the system's stability, security, and user data privacy protection capabilities while ensuring execution efficiency.

[0040] In summary, this application's embodiments achieve dynamic partitioning and efficient utilization of physical GPU resources through GPU virtualization and time-sharing multiplexing technologies, thereby improving resource utilization. By dividing virtual GPU units and scheduling them with time slices according to task type and real-time requirements, it can adapt to the performance needs of different types of tasks. Through dynamic allocation of computing resources and time slices, it can achieve efficient concurrent support for heterogeneous tasks such as game rendering and AI inference. The adoption of a hardware-level memory isolation mechanism ensures data security and user privacy protection during multi-task operation. In conclusion, the cloud phone GPU virtualization time-sharing multiplexing method provided in this application's embodiments achieves dynamic resource partitioning and scheduling through GPU virtualization and time-sharing multiplexing, balancing efficient concurrency of heterogeneous tasks with secure data isolation.

[0041] In some embodiments, step 102 may include: determining the task type based on the task identifier of the concurrent task, wherein the task type is a rendering task or a computation task; parsing the concurrent task to obtain the frame rate threshold and latency tolerance of the concurrent task; and determining the real-time requirements based on the frame rate threshold and latency tolerance.

[0042] In some examples, determining the task type based on the task identifier of concurrent tasks is the first step in feature parsing. The task identifier is a unique identifier string assigned to each task during generation. Its structure includes a type-distinguishing field; for example, the prefix "R-" represents rendering tasks, and "C-" represents computational tasks. Identifying this field through a string matching algorithm allows for quick classification. Rendering tasks mainly refer to tasks that rely on a graphics rendering pipeline, such as 3D games run by users (requiring real-time generation of 1080P / 4K images) and real-time beautification rendering for video calls (requiring processing 30 frames per second). Their core requirement is the efficient execution of graphics APIs (such as OpenGL and Vulkan). Computational tasks, on the other hand, refer to tasks primarily involving parallel data processing, such as AI image classification running on cloud phones (requiring batch processing of feature extraction from 100 images) and offline speech-to-text (requiring processing minutes of audio data). Their core relies on the parallel computing units of the GPU (such as CUDA cores and Tensor cores). The parsing of task identifiers is completed using preset regular expressions, with matching time controlled within 1ms, ensuring no impact on the overall process efficiency. Parsing concurrent tasks to obtain their frame rate thresholds and latency tolerances is a crucial step in quantifying real-time requirements. The frame rate threshold refers to the minimum number of frame updates per second required by the task, directly impacting the user's perception of smoothness. For example, competitive games typically include thresholds like "60fps" or "120fps" in their configuration files; below these values, stuttering will occur. Video editing tasks often have a frame rate threshold of "30fps," sufficient for basic previewing. Latency tolerance refers to the maximum acceptable latency from command issuance to result feedback. For instance, game operation commands (such as button shooting) typically have a latency tolerance of no more than 50ms, otherwise it will affect the feel of the controls. Offline AI inference tasks, however, can have a latency tolerance exceeding 1000ms, with lower requirements for real-time feedback. The parsing process is achieved by reading the task's metadata (such as the game's configuration file or the AI ​​task's API parameters). For tasks without explicit configuration, default values ​​can be assigned based on historical execution data; for example, an unknown game task might have a default frame rate threshold of 60fps and a latency tolerance of 50ms. Based on the frame rate threshold and latency tolerance, the real-time requirements are determined. The two need to be converted into a comparable real-time level through weighted calculation. Specifically, the real-time requirement score is calculated according to the formula "RealTimeScore=(1 / latency tolerance)×a+frame rate threshold×b", where a and b are weight coefficients (a=0.6, b=0.4, with latency impact being taken into account first), and the score range is 0-10 (0 is the lowest real-time requirement and 10 is the highest).For example, a task with a frame rate threshold of 120fps and a latency tolerance of 20ms would score approximately (1 / 20)×0.6 + 120×0.4 ≈ 0.03 + 48 = 48.03 (normalized to 10 points); a task with a frame rate threshold of 30fps and a latency tolerance of 1000ms would score approximately (1 / 1000)×0.6 + 30×0.4 ≈ 0.0006 + 12 = 12.0006 (normalized to 3 points). Based on these scores, real-time requirements can be categorized into three levels: 8-10 points for high real-time performance (e.g., competitive games), 4-7 points for medium real-time performance (e.g., video calls), and 0-3 points for low real-time performance (e.g., offline computing), providing a clear basis for subsequent virtual GPU unit partitioning and time slice allocation. The parsing process needs to be fault-tolerant. When task metadata is missing or parameters are abnormal (such as a frame rate threshold of 0), a default strategy can be triggered (such as assigning values ​​according to task type: high frame rate and low latency for rendering tasks, and low frame rate and high latency for computation tasks) to ensure that the determination of real-time requirements is not interrupted. At the same time, the parsing results will be cached in the task feature library for quick access to similar tasks on the next run, reducing parsing time (from 5ms for the first parsing to 1ms for the second parsing).

[0043] By parsing the task identifiers described above, it is possible to distinguish between rendering tasks (such as games) and computational tasks (such as AI inference), and further extract key parameters such as frame rate threshold and latency tolerance, thereby accurately determining the real-time requirements of each task. This intelligent task feature analysis method helps to achieve precise resource scheduling, provides a basis for subsequent GPU partitioning and resource allocation, ensures that high real-time tasks receive rapid response and low real-time tasks receive high throughput support, and improves the pertinence and rationality of overall task scheduling.

[0044] In some embodiments, step 103 may include: calculating the number of virtual GPU units to be partitioned based on task type and real-time requirements; dividing the physical GPU into multiple logical unit groups according to the number of partitions, wherein rendering tasks are bound to low-latency logical unit groups and computing tasks are bound to high-throughput logical unit groups; allocating independent video memory blocks to each logical unit group through the GPU memory management unit and setting a preset address offset to achieve a hardware-level video memory isolation mechanism; and combining the logical unit groups with the corresponding independent video memory blocks to obtain multiple virtual GPU units.

[0045] In some examples, calculating the number of virtual GPU units based on task type and real-time requirements is a prerequisite for partitioning. This coefficient is used to determine the minimum number of virtual GPU units required, avoiding excessive or insufficient resource allocation. Its calculation logic combines the number of concurrent tasks with the weight of real-time requirements: assuming there are currently M concurrent tasks, each task's real-time score is S1 to S2. m(Scoring range 0-10), then the formula for calculating the division coefficient K is K=α×M+β×(ΣS) i / M), where α is the task quantity weight (valued at 0.6 to ensure coverage of all tasks), and β is the real-time weight (valued at 0.4, high real-time tasks require more virtual GPU units to avoid contention). For example, for 5 tasks with a real-time score of 8, the calculated K = 0.6 × 5 + 0.4 × 8 = 3 + 3.2 = 6.2, rounded up to 7, meaning at least 7 virtual GPU units are needed to meet high real-time requirements; for 3 computational tasks with a score of 3, K = 0.6 × 3 + 0.4 × 3 = 1.8 + 1.2 = 3, meaning 3 virtual GPU units are sufficient. This coefficient is calculated using a preset algorithm module, with a processing time of less than 2ms, ensuring rapid response to task changes. Dividing the physical GPU into multiple logical unit groups based on the partitioning coefficient is the core step in resource partitioning. A logical unit group refers to a logical set of components from the physical GPU that includes computational units (such as streaming multiprocessors, SMs), L1 cache, shared memory, etc., and its configuration varies depending on the task type. For rendering tasks (such as games), which are sensitive to latency (real-time performance scores are typically 8-10), the bound logical unit groups need to optimize data access paths. For example, select the SM group closest to the memory controller in the physical GPU (to reduce data transfer distance) and lower the scheduling level (skip some unnecessary cache refresh steps) to keep the task response latency of this group within 10ms, meeting the low latency requirements. For computing tasks (such as AI inference), which focus on throughput (real-time performance scores 3-6), the bound logical unit groups should focus on parallel computing capabilities. For example, include 60%-80% of the tensor cores in the physical GPU (to support mixed-precision computing) and increase the L2 cache capacity (e.g., from 512KB to 1MB) to improve batch data processing efficiency. The splitting of logical unit groups is achieved through the resource mapping interface of the GPU virtualization layer. The interface dynamically adjusts the number of computing units in each group according to the number of division coefficients. For example, when the coefficient is 7, the physical GPU with 4096 CUDA cores is split into 7 groups, each containing 585-586 cores (with the error controlled within 1%), to ensure the balance of resource allocation.The GPU Memory Management Unit (MMU) allocates independent memory blocks to each logical unit group and sets preset address offsets to achieve hardware-level memory isolation, which is a crucial step in ensuring data security. The MMU is the hardware module in the physical GPU responsible for memory address mapping and access control. It manages memory access through a page table mechanism—the system allocates independent memory blocks to each logical unit group based on the task's memory requirements. For example, logical unit groups for rendering tasks need to store textures, frame buffers, and other data, and therefore allocate... 2GB-4GB of video memory (matching 1080P / 4K rendering requirements); logical unit groups for computational tasks, primarily storing model parameters and input data, are allocated 1GB-2GB of video memory. To avoid address overlap, the MMU sets a preset address offset for each video memory block. For example, the first block starts at address 0x00000000, the second at 0x80000000 (2GB offset), the third at 0x100000000 (4GB offset), and so on, making the address space of each block completely independent. Simultaneously, the MMU marks the access permissions for each block in the page table (only allowing read and write access by the bound logical unit group). Even if an out-of-bounds access instruction occurs, a hardware exception interrupt will be triggered, preventing data leakage from the underlying layer. Combining logical unit groups with their corresponding independent video memory blocks to obtain multiple virtual GPU units is the final step in the formation of virtual GPU units. Each virtual GPU unit thus becomes a complete virtual entity containing independent computing resources (logical unit groups) and storage resources (video memory blocks). For example, the virtual GPU unit for rendering tasks consists of a low-latency logic unit group (585 CUDA cores) and a 2GB dedicated memory block, which can meet the rendering requirements of 60fps games; the virtual GPU unit for computing tasks consists of a high-throughput logic unit group (586 CUDA cores + 128 Tensor cores) and a 1GB dedicated memory block, which can support 100 AI inferences per second. The combination process is completed through the resource binding interface of the virtualization layer. The interface associates the computing resource identifier of the logic unit group with the address range of the memory block to form the resource descriptor of the virtual GPU unit for subsequent use by the scheduling module.

[0046] Through the implementation of the above embodiments, the GPU partitioning coefficient is calculated according to the task type and real-time requirements, and logical unit groups with differentiated execution characteristics are constructed. This enables rendering tasks to be bound to low-latency units and computing tasks to high-throughput units. At the same time, independent memory block allocation is achieved in conjunction with the GPU memory management unit. This partitioning method not only improves the utilization accuracy of GPU physical resources, but also achieves hardware-level memory isolation by setting address offsets. It can solve the problems of data leakage and task interference when multiple user tasks are concurrent, and is one of the core mechanisms to ensure the safe and stable operation of the cloud phone system.

[0047] In some embodiments, step 104 may include: when the target type feature is a rendering task, allocating a time slice of a first duration threshold and a preset memory weight coefficient to the corresponding virtual GPU unit; when the target type feature is a computing task, allocating a time slice of a second duration threshold and a preset computing unit weight coefficient to the corresponding virtual GPU unit; wherein the first duration threshold is less than the second duration threshold, and the preset memory weight coefficient is greater than the preset computing unit weight coefficient; and allocating computing resources based on the preset memory weight coefficient and the preset computing unit weight coefficient.

[0048] In some examples, the target type feature, i.e., the task type (rendering or computation) parsed in step 102, directly determines the resource allocation strategy. Rendering tasks, centered on real-time graphics rendering (such as games and real-time video processing), have extremely high requirements for smoothness and responsiveness, and must prioritize low latency and high-frequency resource updates. Computation tasks, centered on parallel data processing (such as AI inference and batch data computation), focus more on computational throughput per unit time, and need to reduce resource switching overhead to improve efficiency. When the target type feature is a rendering task, a time slice of the first duration threshold and a preset memory weight coefficient are allocated to the corresponding virtual GPU unit. Specifically, the first duration threshold refers to the length of the time slice allocated to the virtual GPU unit of the rendering task, and its value must meet the high-frequency update requirements—for example, set to 10-20ms. A shorter time slice allows the virtual GPU unit to obtain physical GPU resources more frequently, ensuring that the rendering instructions for each frame can be processed in a timely manner (e.g., a 60fps game requires approximately 16.7ms per frame, and a 10ms time slice can ensure that each frame is scheduled at least once). The preset memory weight coefficient (w2) is the weight allocated to memory when allocating computing resources. Since rendering tasks require high-frequency reading and writing of textures, frame buffers, and other data (e.g., approximately 200MB of memory bandwidth per frame for a 1080P image), this coefficient is typically set to 0.4-0.5, higher than the computing unit weight (w1 = 0.3-0.35) and bandwidth weight (w3 = 0.2-0.25), ensuring priority allocation of memory resources. When the target type is a computing task, a second duration threshold time slice and a preset computing unit weight coefficient are allocated to the corresponding virtual GPU unit. Specifically, the second duration threshold is set for the long-cycle processing requirements of computing tasks, such as 100-200ms. A longer time slice can reduce the number of task switching (each switch requires saving / restoring the context, consuming approximately 1-2ms), allowing computing units to continuously execute batch operations (such as convolutional layer calculations for AI inference), thus improving throughput. The preset computation unit weight coefficient (w1) is the weight of the computation unit in the allocation of computing resources. Since computational tasks rely on a large amount of parallel computing (such as matrix operations in the CUDA core), this coefficient is usually set to 0.5-0.6, which is higher than the memory weight (w2 = 0.2-0.3) and bandwidth weight (w3 = 0.2-0.25), focusing on ensuring the supply of computing power. The first duration threshold is smaller than the second duration threshold, and the preset memory weight coefficient is greater than the preset computation unit weight coefficient. This is a design based on task characteristics. Short time slices (such as 10ms) for rendering tasks, combined with high-frequency switching, can meet real-time requirements (latency controlled within 50ms), while long time slices (such as 100ms) for computational tasks can reduce switching losses (the number of switching times is reduced to 1 / 10). The higher memory weight ensures that memory-intensive operations of rendering tasks do not lag, while the higher computation unit weight ensures the parallel processing efficiency of computational tasks. The two form a complementary resource allocation strategy.Computing resources are allocated based on preset memory weight coefficients and preset computing unit weight coefficients; specifically, this is done through a weighted formula, namely, computing resource = w1 × computing unit + w2 × memory + w3 × bandwidth. For example, a physical GPU has 4096 CUDA cores, 16GB of video memory, and 200GB / s bandwidth. When allocating virtual GPU units for rendering, using w1=0.3, w2=0.5, and w3=0.2, we get 1229 CUDA cores (4096×0.3), 8GB of video memory (16×0.5), and 40GB / s bandwidth (200×0.2). When allocating virtual GPU units for computing, using w1=0.6, w2=0.2, and w3=0.2, we get 2458 CUDA cores (4096×0.6), 3.2GB of video memory (16×0.2), and 40GB / s bandwidth (200×0.2), precisely matching the resource requirements of the two types of tasks. The time slice threshold and weighting coefficient can be dynamically fine-tuned. If the frame rate of rendering tasks falls below the target value (e.g., from 60fps to 50fps), the first duration threshold can be increased to 12ms, and the memory weighting coefficient can be increased to 0.55. If the throughput of computation tasks decreases (e.g., the number of inference operations per second decreases from 100 to 80), the second duration threshold can be increased to 120ms, and the computation unit weighting coefficient can be increased to 0.65. Adjustments are triggered by real-time monitoring of the virtual GPU unit's resource utilization (data is collected every 10ms) to ensure that resource allocation always adapts to the real-time state of the task.

[0049] By implementing the above embodiments, different time slice lengths and resource weight parameters can be set for different types of tasks, which can more effectively match the execution characteristics of various tasks. For example, rendering tasks are allocated shorter time slices and higher video memory weights to ensure image smoothness and low latency; while computing tasks are allocated longer time slices and higher computing resource weights to improve throughput efficiency. This mechanism can achieve precise on-demand resource allocation, optimize the execution effect of different types of tasks, and improve the task processing capability and user experience of the entire cloud phone platform.

[0050] In some embodiments, the aforementioned method of alternately executing multiple concurrent tasks using virtual GPU units may include: allocating a corresponding execution period of virtual GPU units to each concurrent task according to a time slice; within each execution period, scheduling the virtual GPU unit corresponding to the current concurrent task to load and run the corresponding computation instructions and graphics rendering operations; and after the current concurrent task has completed execution or the time slice has expired, saving the current task context state and switching to the virtual GPU unit corresponding to the next concurrent task to continue execution.

[0051] In some examples, a time slice refers to either the first duration threshold (10-20ms for rendering tasks) or the second duration threshold (100-200ms for computation tasks) allocated in step 104. An execution period refers to the continuous time interval during which each virtual GPU unit exclusively occupies physical GPU resources (e.g., a 10ms period for a rendering virtual GPU unit is 0-10ms, and a 100ms period for a computation virtual GPU unit is 10-110ms). This sequential allocation process is implemented through a task scheduling queue, which is sorted by task priority (tasks with higher real-time performance scores are prioritized) or submission order. For example, highly real-time game tasks are prioritized, followed by offline AI inference tasks, ensuring that critical tasks receive execution rights first. The allocation process is completed by the virtualization layer scheduler, which checks the time slice status every 1ms and dynamically updates the execution period table to ensure no overlap in periods (e.g., the end time of the previous task's execution period strictly coincides with the start time of the next task), thus avoiding resource conflicts. Within each execution period, the core stage of task execution is the scheduling of the virtual GPU unit corresponding to the current concurrent task to load and run the corresponding computational instructions and graphics rendering operations. The scheduling process refers to establishing a real-time mapping between the logical resources (computation units, memory blocks) of the current virtual GPU unit and the hardware resources (such as streaming multiprocessors, memory controllers) of the physical GPU through the resource mapping module of the GPU virtualization layer, so that the instructions of the virtual GPU unit can directly drive the execution of physical hardware. "Loading and running the corresponding instructions" varies depending on the task type: For rendering tasks (such as games), the virtual GPU unit loads graphics API instructions (such as DirectX's DrawIndexed and Vulkan's vkCmdDraw), which are converted into micro-instructions (such as pixel shader instructions) that can be executed by the physical GPU through the driver layer to complete rendering operations such as vertex processing, rasterization, and texture sampling; For computational tasks (such as AI inference), the virtual GPU unit loads parallel computing instructions (such as CUDA's kernel functions and TensorRT's inference engine instructions), which perform matrix multiplication, activation function and other operations through the tensor cores of the physical GPU. During execution, the virtual GPU unit reads data from its own independent video memory block in real time (such as texture data of rendering tasks and input features of computing tasks) and writes intermediate results into the block to ensure that the data is not mixed with other virtual GPU units.After the current concurrent task completes execution or its time slice expires, saving the current task context state and switching to the virtual GPU unit corresponding to the next concurrent task to continue execution is a crucial step in task switching. The task context state refers to the key state data during task execution, including intermediate calculation results in registers (such as the values ​​of general-purpose registers in the CUDA core), pointers to incomplete data in video memory (such as the frame buffer address of a rendering task), and instruction counters (which record which instruction is currently being executed). This data is the basis for the task to continue execution. The process of saving the context state is implemented through a hardware-accelerated context caching mechanism. The GPU's built-in context saving unit can write key state data to a dedicated cache area (such as a 2MB context cache) within 1ms, avoiding the latency caused by relying on video memory read and write. If the current task has been completed (e.g., game level completion, AI inference output results), the integrity of the task results will be verified first (e.g., rendering tasks check frame buffer CRC checksums, calculation tasks compare output tensor dimensions), and then the context will be saved (in case of potential task restart requirements). If the time slice expires, such as a rendering task ending in 10ms without completing a single frame of rendering, the context will be saved directly to ensure that execution can continue from the breakpoint when switching back next time. The process of switching to the virtual GPU unit corresponding to the next concurrent task includes two steps: First, the GPU Memory Management Unit (MMU) switches the memory address mapping table, changing the physical GPU's memory access permissions from the current virtual GPU unit block to the next virtual GPU unit block (address offset jumps according to preset values, such as switching from 0x00000000 to 0x80000000); second, the task context state of the next virtual GPU unit is restored from the context buffer, restoring register values, instruction counters, etc., to the state at the time of the last pause, so that it can continue execution seamlessly. The total latency of the switching process is controlled within 2ms (for rendering tasks) or within 5ms (for computation tasks) to avoid affecting the real-time performance or throughput of the task.

[0052] Through the implementation of the above embodiments, a time-slice-driven mechanism is used to sequentially schedule virtual GPU units to execute corresponding computation and rendering tasks for each concurrent task. The task context is saved and the process switches to the next task when the time slice ends or the task is completed. This time-sharing multiplexing mechanism effectively improves the parallel processing capability of the GPU and ensures the integrity and continuity of task switching through the context saving mechanism, significantly reducing the impact of task interruptions on performance. It is particularly suitable for high-concurrency, short-cycle alternating execution scenarios such as cloud phones.

[0053] In some embodiments, the aforementioned method may further include: in response to a task completion signal, releasing the mapping relationship between the virtual GPU unit and the physical GPU; clearing the video memory area allocated to the virtual GPU unit and releasing the occupied bandwidth resource channel.

[0054] In some examples, the task completion signal refers to the trigger signal generated by the system after the concurrent task execution is completed. Its sources include two scenarios: first, the task itself completes execution (e.g., a game exits normally, AI inference outputs results), triggered by the task process's "completion flag" (e.g., return value 0); second, the task terminates abnormally (e.g., timeout, erroneous instruction), triggered by the monitoring module's "abnormal signal" (e.g., instruction execution failure code). Signal detection is performed by the system's task status monitor, which scans the task execution status every 5ms to ensure the signal is captured within 10ms, preventing long-term resource idleness. De-mapping the virtual GPU unit from the physical GPU is the first step in resource reclamation. The mapping relationship refers to the real-time association between the virtual GPU unit's logical resources (e.g., logical computing units, virtual memory addresses) and the physical GPU's hardware resources (e.g., streaming multiprocessors, physical memory addresses) established in step 105. This association is maintained by the virtualization layer's (Hypervisor) resource mapping table. The unmapping process is implemented by calling the Hypervisor's resource unbinding interface: the interface first verifies the execution status of the current virtual GPU unit (ensuring the task has stopped), then removes the entry for that virtual GPU unit from the mapping table, and simultaneously sends a resource release micro-instruction to the physical GPU, such as clearing the address mapping entry in the MMU, so that the physical GPU's hardware resources (such as occupied streaming multiprocessors) switch from a bound state to an idle state, waiting to be occupied by a new virtual GPU unit. The unmapping time is controlled within 5ms to ensure that resources quickly return to the available pool. The process of clearing the video memory area allocated to the virtual GPU unit is a core operation to ensure data security. The video memory area refers to the independent video memory block allocated to the virtual GPU unit in step 103 (such as a 2GB block for rendering tasks and a 1GB block for computing tasks). Sensitive data from the task execution process, such as user images and AI model parameters, may remain in this area. Clearing is not a simple logical deletion, but rather a hardware-level erase instruction, such as "SecureErase," executed by the GPU Memory Management Unit (MMU). This instruction overwrites every storage unit in the video memory block (e.g., filling it with 0xFF), ensuring that the data cannot be recovered—even memory forensics tools cannot read the residual information, meeting the privacy protection requirements in multi-user scenarios. For the video memory area of ​​rendering tasks, which contains image data such as frame buffers, clearing will also trigger a video memory health check (such as verifying the read-write consistency of storage units) to prevent bad blocks from affecting subsequent tasks. For the video memory area of ​​computing tasks, which involves batch data, an erase log (including timestamps and block addresses) will be recorded after clearing for auditing and fault tracing. The bandwidth resource channel refers to the data transmission path (such as PCIe channel, internal bus link) between the virtual GPU unit and the physical GPU memory controller. Its bandwidth allocation is determined by the weighting coefficient w3 in step 104 (such as 20%-25%).The release process can be completed through the bandwidth controller. The controller first resets the channel's transmission parameters (e.g., reducing the data transfer rate from 20GB / s to the idle state of 1GB / s), then unbinds the channel from the virtual GPU unit and adds it to the idle bandwidth pool for allocation by new virtual GPU units. For high-priority channels occupied by rendering tasks (using low-latency links due to real-time requirements), an additional channel reset check is performed during release, such as testing the link error rate, to ensure that the channel state meets the requirements of the next high real-time transmission. For high-throughput channels occupied by computing tasks, data fragments in the cache are cleared during release, such as deleting untransmitted batch data fragments to avoid interfering with subsequent transmissions. The entire resource reclamation process must be controlled within 50ms (from signal triggering to complete resource release), of which unmapping time is ≤10ms, clearing video memory time is ≤30ms (depending on video memory capacity, such as about 20ms for 2GB video memory), and bandwidth release time is ≤10ms. After recycling is complete, the physical GPU resource status table can be updated to mark the released computing units, video memory, and bandwidth as available, and the scheduling module can be notified to include them in the next round of resource allocation, ensuring that the resource utilization of the physical GPU is maintained above 80% and achieving efficient cyclic reuse.

[0055] Through the implementation of the above embodiments, after the task is completed, the mapping relationship between the virtual GPU unit and the physical GPU can be released in a timely manner, and the video memory and bandwidth resources can be cleared and released, realizing the instantaneous recycling and redistribution of resources. This not only reduces the lag in resource occupation, but also improves the overall resource circulation efficiency of the system, enabling the cloud phone platform to run continuously and stably in a high-concurrency, multi-tasking environment, further reducing the hardware resource redundancy requirements and operation and maintenance costs.

[0056] Furthermore, as an implementation of the aforementioned method embodiments, this application also provides a cloud phone GPU virtualization time-sharing multiplexing device for implementing the aforementioned method embodiments. This device embodiment corresponds to the aforementioned method embodiments. For ease of reading, this cloud phone GPU virtualization time-sharing multiplexing device embodiment will not repeat the details of the aforementioned method embodiments one by one, but it should be clear that the device in this application embodiment can correspondingly implement all the contents of the aforementioned method embodiments. For example... Figure 2As shown, the cloud phone GPU virtualization time-sharing multiplexing device 20 includes: a task acquisition unit 201, a task parsing unit 202, a virtual partitioning unit 203, a resource allocation unit 204, and a task execution unit 205. The task acquisition unit 201 is used to acquire multiple concurrent tasks submitted by the cloud phone platform; the task parsing unit 202 is used to perform feature parsing on the concurrent tasks to obtain the task type and real-time requirements of the concurrent tasks; the virtual partitioning unit 203 is used to divide the physical GPU into multiple virtual GPU units based on the task type and real-time requirements; the resource allocation unit 204 is used to allocate time slices and computing resources to each virtual GPU unit based on the task type; and the task execution unit 205 is used to execute multiple concurrent tasks alternately through the virtual GPU units under a hardware-level memory isolation mechanism.

[0057] This application also provides a computer-readable storage medium storing computer-executable instructions or computer programs, which, when executed by a processor, will cause the processor to perform any step of the cloud phone GPU virtualization time-sharing multiplexing method provided in this application.

[0058] In some embodiments, the computer-readable storage medium may be a random access memory (RAM), a read-only memory (ROM), flash memory, a magnetic surface memory, an optical disc, or a compact disc read-only memory (CD-ROM); or it may be a variety of devices that include one or any combination of the above-mentioned memories.

[0059] In some embodiments, computer-executable instructions may take the form of programs, software, software modules, scripts, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as stand-alone programs or as modules, components, subroutines, or other units suitable for use in a computing environment.

[0060] In some embodiments, computer-executable instructions may, but do not necessarily, correspond to files in a file system, and may be stored as part of a file that holds other programs or data, for example, in one or more scripts in a HyperText Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple co-located files (e.g., files that store one or more modules, subroutines, or code sections).

[0061] In some embodiments, computer-executable instructions may be deployed to execute on an electronic device, or on multiple electronic devices located at one location, or on multiple electronic devices distributed across multiple locations and interconnected via a communication network.

[0062] like Figure 3 As shown, this application also provides an electronic device 30, including a memory 310, a processor 320, and a computer program 311 stored in the memory 310 and executable on the processor. When the processor 320 executes the computer program 311, it implements any step of the above-described cloud phone GPU virtualization time-sharing multiplexing method.

[0063] This application also provides a computer program product comprising a computer program or computer-executable instructions stored in a computer-readable storage medium. The processor of an electronic device reads the computer program or computer-executable instructions from the computer-readable storage medium and executes the computer program or computer-executable instructions, causing the electronic device to perform any step of the cloud phone GPU virtualization time-sharing method described above.

[0064] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A method for time-sharing multiplexing of GPU virtualization in cloud phones, characterized in that, include: Retrieve multiple concurrent tasks submitted by the cloud phone platform; Feature analysis is performed on the concurrent tasks to obtain the task type and real-time requirements of the concurrent tasks; Based on the task type and the real-time requirements, the physical GPU is divided into multiple virtual GPU units; Based on the task type, allocate time slices and computing resources to each virtual GPU unit; Under the hardware-level memory isolation mechanism, the multiple concurrent tasks are executed alternately by the virtual GPU unit.

2. The method according to claim 1, characterized in that, The step of performing feature analysis on the concurrent tasks to obtain the task type and real-time requirements of the concurrent tasks includes: The task type is determined based on the task identifier of the concurrent task, wherein the task type is a rendering task or a computation task; The concurrent tasks are analyzed to obtain the frame rate threshold and latency tolerance of the concurrent tasks; The real-time requirements are determined based on the frame rate threshold and the latency tolerance.

3. The method according to claim 2, characterized in that, Based on the task type and the real-time requirements, the physical GPU is divided into multiple virtual GPU units, including: Based on the task type and real-time requirements, calculate the partitioning coefficient of the virtual GPU unit; Based on the division coefficient, the physical GPU is divided into multiple logical unit groups, wherein the rendering tasks are bound to low-latency logical unit groups, and the computing tasks are bound to high-throughput logical unit groups. The GPU memory management unit allocates an independent video memory block to each logical unit group and sets a preset address offset to achieve the hardware-level video memory isolation mechanism. The logical unit group is combined with the corresponding independent video memory block to obtain the multiple virtual GPU units.

4. The method according to claim 2, characterized in that, The allocation of time slices and computing resources to each virtual GPU unit based on the task type includes: When the target type feature is the rendering task, a time slice of the first duration threshold and a preset memory weight coefficient are allocated to the corresponding virtual GPU unit. When the target type feature is the computing task, a time slice of the second duration threshold and a preset computing unit weight coefficient are allocated to the corresponding virtual GPU unit; wherein, the first duration threshold is less than the second duration threshold, and the preset memory weight coefficient is greater than the preset computing unit weight coefficient; The computing resources are allocated based on the preset memory weight coefficient and the preset computing unit weight coefficient.

5. The method according to claim 1, characterized in that, The method of alternately executing the multiple concurrent tasks through the virtual GPU unit includes: According to the time slice, the corresponding execution time slot of the virtual GPU unit is allocated to each concurrent task in sequence; During each execution period, the virtual GPU unit corresponding to the current concurrent task is scheduled to load and run the corresponding computing instructions and graphics rendering operations; After the current concurrent task is completed or the time slice is exhausted, the current task context state is saved and the process switches to the virtual GPU unit corresponding to the next concurrent task to continue execution.

6. The method according to claim 1, characterized in that, The method further includes: In response to a task completion signal, the mapping relationship between the virtual GPU unit and the physical GPU is released; Clear the video memory area allocated to the virtual GPU unit and release the occupied bandwidth resource channel.

7. A cloud phone GPU virtualization time-sharing multiplexing device, characterized in that, include: The task acquisition unit is used to acquire multiple concurrent tasks submitted by the cloud phone platform; The task parsing unit is used to perform feature parsing on the concurrent tasks to obtain the task type and real-time requirements of the concurrent tasks. A virtual partitioning unit is used to divide a physical GPU into multiple virtual GPU units based on the task type and the real-time requirements. A resource allocation unit is used to allocate time slices and computing resources to each virtual GPU unit based on the task type. The task execution unit is used to alternately execute the multiple concurrent tasks through the virtual GPU unit under the hardware-level memory isolation mechanism.

8. An electronic device, comprising: The memory and processor are characterized in that the processor, when executing a computer program stored in the memory, implements the steps of the cloud phone GPU virtualization time-sharing multiplexing method as described in any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the cloud phone GPU virtualization time-sharing multiplexing method as described in any one of claims 1 to 6.

10. A computer program product comprising a computer program or computer-executable instructions, characterized in that, When the computer program or computer-executable instructions are executed by the processor, the steps of the cloud phone GPU virtualization time-sharing multiplexing method as described in any one of claims 1 to 6 are implemented.

Images