Graphics processing unit (GPU) context priority dynamic adjustment procedures and central processing unit and graphics processing unit (CPU-GPU) joint scheduling strategy

Abstract

A processor-implemented method for adapting a priority of a graphics processing unit (GPU) content at runtime includes receiving, by a GPU driver, a priority change request for a GPU context. The GPU driver determines whether to approve the priority change request based on one or more of GPU capabilities, GPU hardware bandwidth, or a power budget. The GPU driver adapts a GPU context priority for the GPU context during runtime from a first priority level to a second priority level based on the determination.

Description

GRAPHICS PROCESSING UNIT (GPU) CONTEXT PRIORITY DYNAMIC ADJUSTMENT PROCEDURES AND CENTRAL PROCESSING UNIT AND GRAPHICS PROCESSING UNIT (CPU-GPU) JOINT SCHEDULING STRATEGYBACKGROUNDField

[0001] Aspects of the present disclosure relate to computing devices, and more specifically to graphics processing unit (GPU) context priority dynamic adjustment procedures and central processing unit and graphics processing unit (CPU-GPU) joint scheduling strategy.

[0002] Background

[0003] In consumer electronics and mobile devices, graphics processing unit (GPU) utilization continues to extend beyond graphics processing. The GPU is increasingly becoming a general-purpose processor broadly supporting compute or render tasks during runtime, according to client preference.

[0004] Sharing of the GPU’s resources may be managed by assigning a priority to a GPU context, which is created for each task to be executed by the GPU. The GPU context priority is fixed at the time that a GPU context is created. Some applications support tasks that may flexible or may have different priority specifications. However, there may be no application programming interface (API) to change the context priority at runtime. As such, GPU priority management of multiple flexible tasks at runtime is challenging.SUMMARY

[0005] In some aspects of the present disclosure, a processor-implemented method includes receiving, by a graphics processing unit (GPU) driver, a priority change request for a GPU context. The processor-implemented method further includes determining, by the GPU driver, whether to approve the priority change request based on one or more of GPU capabilities, GPU hardware bandwidth, or a power budget. The processor-implemented method also includes adapting, by the GPU driver, a GPU context priority for the GPU context during runtime from a first priority level to a second priority level based on the determining.

[0006] Various aspects of the present disclosure are directed to an apparatus including means for receiving, by a graphics processing unit (GPU) driver, a priority change request for a GPU context. The apparatus further includes means for determining, by the GPU driver, whether to approve the priority change request based on one or more of GPU capabilities, GPU hardware bandwidth, or a power budget. The apparatus also includes means for adapting, by the GPU driver, a GPU context priority for the GPU context during runtime from a first priority level to a second priority level based on the determining.

[0007] In some aspects of the present disclosure, a non-transitory computer-readable medium with non-transitory program code recorded thereon is disclosed. The program code is executed by a processor and includes program code to receive, by a graphics processing unit (GPU) driver, a priority change request for a GPU context. The program code also includes program code to determine, by the GPU driver, whether to approve the priority change request based on one or more of GPU capabilities, GPU hardware bandwidth, or a power budget. The program code further includes program code to adapt, by the GPU driver, a GPU context priority for the GPU context during runtime from a first priority level to a second priority level based on the determining.

[0008] Various aspects of the present disclosure are directed to an apparatus having a memory and one or more processors coupled to the memory. The processor (s) is configured to receive, by a graphics processing unit (GPU) driver, a priority change request for a GPU context. The processor (s) is also configured to determine, by the GPU driver, whether to approve the priority change request based on one or more of GPU capabilities, GPU hardware bandwidth, or a power budget. The processor (s) is further configured to adapt, by the GPU driver, a GPU context priority for the GPU context during runtime from a first priority level to a second priority level based on the determining.

[0009] This has outlined, rather broadly, the features and technical advantages of the present disclosure in order that the detailed description that follows may be better understood. Additional features and advantages of the present disclosure will be described below. It should be appreciated by those skilled in the art that this present disclosure may be readily utilized as a basis for modifying or designing other structures for carrying out the same purposes of the present disclosure. It should also be realized by those skilled in the art that such equivalent constructions do not depart from the teachings of the present disclosure as set forth in the appended claims. The novel features, which are believed to be characteristic of the present disclosure, both as to its organization and method of operation, together with further objects and advantages, will be better understood from the following description when considered in connection with the accompanying figures. It is to be expressly understood, however, that each of the figures is provided for the purpose of illustration and description only and is not intended as a definition of the limits of the present disclosure.BRIEF DESCRIPTION OF THE DRAWINGS

[0010] For a more complete understanding of the present disclosure, reference is now made to the following description taken in conjunction with the accompanying drawings.

[0011] FIGURE 1 illustrates an example implementation of a host system-on-a-chip (SoC) , which includes a graphics processing unit (GPU) configured for runtime dynamic context priority adjustment, in accordance with various aspects of the present disclosure.

[0012] FIGURE 2 is a block diagram illustrating an example architecture for processing application tasks using GPU hardware.

[0013] FIGURE 3 is a block diagram illustrating an example system for adapting a priority of a GPU context during runtime, in accordance with various aspects of the present disclosure.

[0014] FIGURE 4 is a block diagram illustrating an example GPU context priority change, in accordance with various aspects of the present disclosure.

[0015] FIGURE 5 is a flow diagram illustrating an example process for adapting a GPU context priority during runtime, in accordance with various aspects of the present disclosure.

[0016] FIGURE 6 is a block diagram showing an exemplary wireless communications system in which a configuration of the present disclosure may be advantageously employed.DETAILED DESCRIPTION

[0017] The detailed description set forth below, in connection with the appended drawings, is intended as a description of various configurations and is not intended to represent the only configurations in which the concepts described may be practiced. The detailed description includes specific details for the purpose of providing a thorough understanding of the various concepts. It will be apparent, however, to those skilled in the art that these concepts may be practiced without these specific details. In some instances, well-known structures and components are shown in block diagram form in order to avoid obscuring such concepts.

[0018] As described, the use of the term “and / or” is intended to represent an “inclusive OR, ” and the use of the term “or” is intended to represent an “exclusive OR. ” As described, the term “exemplary” used throughout this description means “serving as an example, instance, or illustration, ” and should not necessarily be construed as preferred or advantageous over other exemplary configurations. As described, the term “coupled” used throughout this description means “connected, whether directly or indirectly through intervening connections (e.g., a switch) , electrical, mechanical, or otherwise, ” and is not necessarily limited to physical connections. Additionally, the connections can be such that the objects are permanently connected or releasably connected. The connections can be through switches. As described, the term “proximate” used throughout this description means “adjacent, very near, next to, or close to. ” As described, the term “on” used throughout this description means “directly on”in some configurations, and “indirectly on” in other configurations.

[0019] As described, in consumer electronics and mobile devices, graphics processing unit (GPU) utilization continues to extend beyond graphics processing. The GPU is increasingly becoming a general-purpose processor broadly supporting compute or render tasks during runtime, according to client preference. For example, GPUs may perform tasks such as two-dimensional (2D) user interface (UI) rendering by applications and default system UI, three-dimensional (3D) gaming or 3D UI, general  image processing for cameras or applications, as well as video encoding or decoding. Still further uses of the GPU may include system service runtime compute, render, and compose tasks (e.g., for android Surfaceflinger) , artificial intelligence (AI) model inferencing for both systems and applications, as well as image segmentation, recognition, and classifying.

[0020] Application programming interfaces (APIs) may facilitate use of the GPU for performing compute tasks that may otherwise be performed using a central processing unit. That is, APIs may serve as a bridge between software applications and the GPU hardware. APIs may provide a set of functions or protocols that enable different applications to communicate with each other or to interact with the GPU without requiring detailed knowledge of the underlying hardware.

[0021] When an application requests a compute or render task to be performed by the GPU, an API may create a GPU context. A GPU context may refer to a virtual space created for each task that is to be executed using the GPU. The GPU context may include current state of information such a data, variables, conditions, and other information that the GPU may use to perform a computation for executing the task.

[0022] GPUs may concurrently serve multiple GPU contexts of multiple different applications. The sharing of the GPU resources may be managed by assigning a priority to each GPU context. Priority management in a GPU context may involve determining the order and level of importance of tasks to be executed by the GPU. Different tasks may have varying priorities based on factors such as user input, system requirements, or real-time rendering demands. The GPU context priority may be fixed at the time that the GPU context is created.

[0023] Some applications may support flexible compute / render tasks or may have different priority specifications. However, there may be no application programming interface (API) to change the context priority at runtime. As such, GPU priority management of multiple flexible tasks at runtime is challenging.

[0024] Accordingly, aspects of the present disclosure are directed to runtime dynamic context priority adjustment. Particular aspects of the subject matter described in this disclosure can be implemented to realize one or more of the following potential  advantages. In some examples, the described techniques, may improve processing efficiency and reduce memory and power consumption.

[0025] FIGURE 1 illustrates an example implementation of a host system-on-a-chip (SoC) 100, which includes a graphics processing unit (GPU) 104 configured for adapting a priority of a GPU context at runtime, in accordance with various aspects of the present disclosure. The host SoC 100 includes processing blocks tailored to specific functions, such as a connectivity block 110. The connectivity block 110 may include fifth generation (5G) connectivity, fourth generation long term evolution (4G LTE) connectivity, Wi-Fi connectivity, universal serial bus (USB) connectivity,  connectivity, Secure Digital (SD) connectivity, and the like.

[0026] In this configuration, the host SoC 100 includes various processing units that support multi-threaded operation. For the configuration shown in FIGURE 1, the host SoC 100 includes a multi-core central processing unit (CPU) 102, a graphics processor unit (GPU) 104, a digital signal processor (DSP) 106, and a neural processor unit (NPU) 108. The host SoC 100 may also include a sensor processor 114, image signal processors (ISPs) 116, a navigation module 120, which may include a global positioning system (GPS) , and a memory 118. The multi-core CPU 102, the GPU 104, the DSP 106, the NPU 108, and the multi-media engine 112 support various functions such as video, audio, graphics, gaming, artificial networks, and the like. Each processor core of the multi-core CPU 102 may be a reduced instruction set computing (RISC) machine, an advanced RISC machine (ARM) , a microprocessor, or some other type of processor. The NPU 108 may be based on an ARM instruction set.

[0027] The SoC 100 may be based on an ARM instruction set. In an aspect of the present disclosure, the instructions loaded into the general-purpose processor 102 may include code to receive, by a GPU driver, a priority change request for a graphics processing unit (GPU) context. The general-purpose processor 102 may also include code to determine, by the GPU driver, whether to approve the priority change request based on one or more of GPU capabilities, GPU hardware bandwidth, or a power budget. The general-purpose processor 102 may further include code to adapt, by the GPU driver, a GPU context priority for the GPU context during runtime from a first priority level to a second priority level based on the determining.

[0028] As described, aspects of the present disclosure are directed to runtime dynamic context priority adjustment.

[0029] FIGURE 2 is a block diagram illustrating an example architecture 200 for processing application tasks using GPU hardware. Referring to FIGURE 2, the example architecture 200 may include a ring buffer 202, a set of priority context lists 206a-d, and GPU hardware (HW) 210. The ring buffer 202 may comprise a four-level ring buffer, for example. A ring buffer may be considered a data structure that uses a single fixed length array arranged as if connected end-to-end with two pointers, one pointer representing the head of a queue and the other pointer representing the tail of the queue. Elements may be added to the ring buffer 202 at the tail of the ring buffer 202 in a first in-first out manner.

[0030] The ring buffer 202 may include a set of ring buffers RB0-RB3. Each ring buffer RB0-RB3 may support a different context priority list (e.g., 206a-d) . For example, the ring buffer RB0 may support real-time priority (e.g., a highest priority) GPU contexts (e.g., 204a-z) , the ring buffer RB1 may support high priority (e.g., second highest priority) GPU contexts, the ring buffer RB2 may support medium priority (e.g., third highest priority) GPU contexts, and the ring buffer RB3 may support lowest priority GPU contexts. Although the example of FIGURE 2 includes four ring buffers to support GPU context, any number of ring buffers may be employed according to design preference.

[0031] Applications operating on a device including the SoC 100, such as a smartphone, for example, may request GPU (e.g., GPU 104 of FIGURE 1) resources for computing tasks using an application programming interface (API) . The applications may use an operating system (OS) as an interface to communicate with hardware components of the device (e.g., the components of the SoC 100) . The OS may include APIs, which may create a GPU context (e.g., 204a-z) and may assign a priority for the GPU context (e.g., 204a-z) . Each GPU context (e.g., 204a-z) with the same priority may be linked as a list. The GPU context commands included in each context list (e.g., 206a-d) may then be submitted to a corresponding ring buffer (e.g., RB0-RB3) . Then, the commands of the respective GPU contexts (e.g., 204a-z) may be supplied from the respective ring buffers (e.g., RB0-RB3) to the GPU hardware 210 for execution according to the context priority.

[0032] In accordance with aspects of the present disclosure, an API may be added to a GPU driver (not shown) to adapt the priority of a GPU context (e.g., 204a-z) during runtime according to the real-time demands of that GPU context (e.g., 204a-z) . An application may send a priority change request to the GPU driver including the context priority adapting API to change a priority for the GPU context (e.g., 204a-z) during runtime. The adapted priority for the GPU context (e.g., 204a-z) may take effect after completing execution of commands of the specified GPU context (e.g., 204a-z) currently being processed by the GPU hardware 210, prior to receiving the priority change request. In some aspects, only commands submitted after the GPU context priority change may be affected.

[0033] A priority value for a GPU context (e.g., 204a-z) may be changed, for example, in the GPU drivers. Then the specified GPU context (e.g., 204a-z) may be removed from a prior priority context list (e.g., 206c) and relinked to a new priority context list (e.g., 206a) . A subsequent command of the GPU context (e.g., 204a-z) queued after the priority change for the GPU context may be submitted to a different level of the ring buffer (e.g., RB0-RB3) according to its new priority.

[0034] In some aspects, the GPU drivers (e.g., a kernel mode driver (KMD) and / or a user mode driver (UMD) ) and runtime operating system (OS) may determine whether to accept a requested priority change or not based on GPU hardware, device bandwidth loading, and / or power budget, for example.

[0035] Additionally, in various aspects, the GPU drivers (e.g., KMD and / or UMD) and runtime OS may jointly schedule CPU and GPU tasks following client API priority change requests.

[0036] FIGURE 3 is a block diagram illustrating an example system 300 for adapting a priority of a GPU context during runtime, in accordance with various aspects of the present disclosure. Referring to FIGURE 3, the example system 300 may include one or more applications 302, an operating system (OS) 312, and a GPU driver module 306. One or more of the applications 302 may request that a task be computed using the GPU hardware (e.g., 210) . In doing so, a GPU context (e.g., 204a-z) may be generated including commands and information for performing computations using the GPU  hardware 210. As described, the GPU context (e.g., 204a-z) is assigned a priority at the time the GPU context (e.g., 204a-z) is created.

[0037] The GPU driver module 306 may include a driver for managing communication between the applications 302, the OS 312, and the GPU hardware (e.g., 210) . For instance, the GPU driver module 306 may include a kernel mode driver (KMD) and a user mode driver (UMD) . The KMD may manage the communication between the GPU hardware (e.g., 210) and the OS 312. For example, when an application issues GPU-related commands through an API, the KMD may translate the commands into instructions that the GPU can understand. The KMD may also perform the functions of memory management, task scheduling, and hardware resource allocation.

[0038] On the other hand, the UMD may function as an intermediary between the applications 302 and the KMD. The UMD may implement API requests (referred to as calls) from applications 302 and transmit the requests to the KMD.

[0039] In accordance with aspects of the present disclosure, the GPU driver module 306 may include an API to adapt a priority (may be referred to as priority adapting API) for a GPU context (e.g., 204a-z) from one of the applications 302. In some aspects, the priority adapting API may be incorporated in the KMD. For example, when a GPU context priority 308 is to be changed, the KMD (e.g., of the GPU driver module 306) may sync with the GPU hardware (e.g., 210) to ensure the context’s previously submitted commands are completely executed on the GPU hardware (e.g., 210) . Then, the priority adapting API may change the priority value of the specified GPU context (e.g., 204a-z) , remove it from the initial priority context list (e.g., 206c) , and add the specified GPU context (e.g., 204a-z) to the updated priority context list (e.g., 206a) .

[0040] The GPU driver module 306 may receive a priority change request 304 from one or more applications 302 via the OS 312. The GPU driver module 306 may determine whether to approve or reject the priority change request 304 based on the GPU hardware capabilities, device bandwidth, and / or power constraints, for instance.

[0041] If the GPU driver module 306 approves the priority change request 304, the GPU driver module 306 may change the GPU context priority 308 from the initial priority level to a different priority level (e.g., a higher priority or a lower priority than  the initial priority level) . In some aspects, the GPU driver module 306 may remove the GPU context (e.g., 204a-z) from a current context priority list (e.g., 206d) and may add the GPU context (e.g., 204a-z) to a different context priority list (e.g., 206b) .

[0042] On the other hand, if the GPU driver module 306 rejects the priority change request 304, the GPU driver module 306 may retain the GPU context priority 308 at the initial priority level (e.g., 206d) .

[0043] In some aspects, the GPU driver module 306 and the runtime OS 312 may jointly schedule application tasks and corresponding GPU contexts (e.g., 204a-z) that involve the CPU (e.g., 102) and the GPU (e.g., 104) . For example, the GPU context (e.g., 204a-z) may involve a draw call for a drawing task. When the priority change request 304 is for a GPU context (e.g., 204a-z) that involves a draw call, a corresponding CPU render thread priority 310 may also be adapted if the priority change request 304 is approved.

[0044] Render threads are responsible for preparing a draw call (e.g., request) . Draw calls may be identified by checking whether they belong to the same GPU context (or Vulkan device queue (VK) for a Vulkan API) (e.g., 206a-z) and by checking which render threads may submit draw calls. Accordingly, the runtime OS 312 and GPU driver module 306 may coordinate the scheduling of the CPU (e.g., 102) and GPU hardware (e.g., 210) tasks to align the execution of tasks and enable proper performance.

[0045] In one example, an instant messaging and social media application may request a context priority change (e.g., 304) to high priority during runtime. The GPU driver module 306 may determine (e.g., based on GPU hardware device bandwidth) that the priority level of the associated GPU context may be increased and rescheduled (e.g., removed from a current priority context list (e.g., 206c or 206d) and added to a high priority context list 206b) , as described. In addition, the application render thread priority 310 in the CPU may also be increased in a corresponding fashion.

[0046] FIGURE 4 is a block diagram illustrating an example GPU context priority change 400, in accordance with various aspects of the present disclosure. Referring to FIGURE 4, ring buffers 202 and corresponding sets of GPU contexts 404 for tasks to be computed using the GPU hardware 210 are shown. The sets of GPU contexts 404  having a same priority level are linked and included in contexts lists according to the level of priority.

[0047] As described, one or more applications may request a priority change with respect to GPU contexts. In the example of FIGURE 4, the GPU drivers may receive priority change requests (e.g., 304) with respect to GPU contexts 410 and 412, respectively. Initially both of the GPU contexts 410 and 412 were assigned a medium priority. With respect to the GPU context 410, the priority change request (e.g., 304) may be to increase the priority level to high priority. The GPU drivers may determine that the GPU has a sufficient budget to accommodate the priority change and may approve the priority change request (e.g., 304) . In turn, the GPU driver may confirm that any commands of the GPU context that are being executed by the GPU hardware 210 are completed. The GPU driver (e.g., 306) may remove the GPU context 410 from the medium priority context list. Then, the GPU driver (e.g., 306) may add the GPU context 410 to the high priority context list.

[0048] With respect to the GPU context 412, the GPU drive (e.g., 306) may receive a request or an indication that the priority is flexible and may be decreased. The GPU may determine whether to decrease the GPU context. The GPU driver may, for example evaluate the GPU hardware processing capabilities, GPU hardware bandwidth, other application demands, other priority change requests and the like to determine whether to adjust the priority. In the example, of FIGURE 4, the GPU driver, having determined to change the priority of GPU context 412, may remove the GPU context 412 from the medium priority context list. Thereafter, the GPU driver may add the GPU context 412 to the low priority context list.

[0049] According to aspects of the present disclosure, a mobile device includes a context priority adaptation module. The context priority adaptation module may include means for receiving, means for determining, and means for adapting. In one configuration, the means for receiving, the means for determining, and / or means for adapting may, for example, comprise the CPU 102, the GPU 104, and / or the memory 118, as shown in FIGURE 1. In other aspects, the aforementioned means may be any structure or any material configured to perform the functions recited by the aforementioned means.

[0050] FIGURE 5 is a flow diagram illustrating an example process 500 for adapting a GPU context priority during runtime, in accordance with various aspects of the present disclosure. The example process 500 may be performed, for example, by processor such as CPU 102 or GPU 104, for example. Moreover, the example process 500 may be implemented on a mobile device such as a smartphone, for instance.

[0051] As shown in FIGURE 5, in some aspects, at block 502, the process 500 may include receiving by a GPU driver, a priority change request for a GPU context. The GPU context may correspond to a task to be executed using the GPU. As described with reference to FIGURE 3, the GPU driver module 306 may receive a priority change request 304 from one or more applications (e.g., 302) , via the OS 312. The GPU context is assigned a priority at the time the GPU context is created.

[0052] At block 504, the processor determines, by the GPU driver, whether to approve the priority change request based on one or more of GPU capabilities, GPU hardware bandwidth, or a power budget. As described, for example, with reference to FIGURE 3, the GPU driver module 306 may determine whether to approve or reject the priority change request 304 based on the GPU hardware capabilities, device bandwidth and / or power constraints, for instance.

[0053] At block 506, the processor adapts, by the GPU driver, a GPU context priority for the GPU context during runtime from a first priority level to a second priority level based on the determining. For instance, as described with reference to FIGURE 3, if the GPU driver module 306 approves the priority change request 304, then the GPU driver module 306 may change the GPU context priority 308 from the initial priority level to a different priority level (e.g., a higher priority or a lower priority than the initial priority level) . In some aspects, the GPU driver module 306 may remove the GPU context from a current context priority list and may add the GPU context to a different context priority list. On the other hand, if the GPU driver module 306 rejects the priority change request 304, the GPU driver module 306 may retain the GPU context priority 308 at the initial priority level. In some aspects, the GPU drivers and the runtime OS may jointly schedule application tasks and corresponding GPU contexts that involve the CPU (e.g., 102) and the GPU (e.g., 104) .

[0054] FIGURE 6 is a block diagram showing an exemplary wireless communications system 600, in which an aspect of the present disclosure may be advantageously employed. For purposes of illustration, FIGURE 6 shows three remote units 620, 630, and 650, and two base stations 640. It will be recognized that wireless communications systems may have many more remote units and base stations. Remote units 620, 630, and 650 include integrated circuit (IC) devices 625A, 625B, and 625C that include the disclosed GPU context priority adapting module. It will be recognized that other devices may also include the disclosed GPU context priority adapting module, such as the base stations, switching devices, and network equipment. FIGURE 6 shows forward link signals 680 from the base stations 640 to the remote units 620, 630, and 650, and reverse link signals 690 from the remote units 620, 630, and 650 to the base stations 640.

[0055] In FIGURE 6, remote unit 620 is shown as a mobile telephone, remote unit 630 is shown as a portable computer, and remote unit 650 is shown as a fixed location remote unit in a wireless local loop system. For example, the remote units may be a mobile phone, a hand-held personal communication systems (PCS) unit, a portable data unit, such as a personal data assistant, a GPS enabled device, a navigation device, a set top box, a music player, a video player, an entertainment unit, a fixed location data unit, such as meter reading equipment, or other device that stores or retrieves data or computer instructions, or combinations thereof. Although FIGURE 6 illustrates remote units according to the aspects of the present disclosure, the disclosure is not limited to these exemplary illustrated units. Aspects of the present disclosure may be suitably employed in many devices, which include the disclosed GPU context priority adapting module.

[0056] Implementation examples are provided in the following numbered clauses.

[0057] 1. A processor-implemented method, comprising:

[0058] receiving, by a graphics processing unit (GPU) driver, a priority change request for a GPU context;

[0059] determining, by the GPU driver, whether to approve the priority change request based on one or more of GPU capabilities, GPU hardware bandwidth, or a power budget; and

[0060] adapting, by the GPU driver, a GPU context priority for the GPU context during runtime from a first priority level to a second priority level based on the determining.

[0061] 2. The processor-implemented method of clause 1, in which the first priority level for the GPU context is assigned at creation of the GPU context.

[0062] 3. The processor-implemented method of clause 1 or 2, in which the second priority level is a higher priority level than the first priority level.

[0063] 4. The processor-implemented method of any of clauses 1-3, further comprising:

[0064] removing, by the GPU driver, the GPU context from a first context list corresponding with the first priority level; and

[0065] adding, by the GPU driver, the GPU context to a second context list corresponding to the second priority level.

[0066] 5. The processor-implemented method of any of clauses 1-4, in which the adapting is performed after currently executing commands of the GPU context are completed.

[0067] 6. The processor-implemented method of any of clauses 1-5, in which the GPU context comprises a draw call, and execution of the GPU context is jointly scheduled by the GPU driver and a runtime operating system.

[0068] 7. The processor-implemented method of any of clauses 1-6, further comprising adapting a render thread priority associated with a draw task of the GPU context.

[0069] 8. An apparatus, comprising:

[0070] at least one memory; and

[0071] at least one processor coupled to the at least one memory, the at least one processor configured to:

[0072] receive, by a graphics processing unit (GPU) driver, a priority change request for a GPU context;

[0073] determine, by the GPU driver, whether to approve the priority change request based on one or more of GPU capabilities, GPU hardware bandwidth, or a power budget; and

[0074] adapt, by the GPU driver, a GPU context priority for the GPU context during runtime from a first priority level to a second priority level based on the determining.

[0075] 9. The apparatus of clause 8, in which the at least one processor is further configured

[0076] to assign the first priority level for the GPU context at creation of the GPU context.

[0077] 10. The apparatus of clause 8 or 9, in which the second priority level is a higher priority level than the first priority level.

[0078] 11. The apparatus of any of clauses 8-10, in which the at least one processor is further configured to:

[0079] remove, by the GPU driver, the GPU context from a first context list corresponding with the first priority level; and

[0080] add, by the GPU driver, the GPU context to a second context list corresponding to the second priority level.

[0081] 12. The apparatus of any of clauses 8-11, in which the at least one processor is further configured to perform the adapting of the GPU context priority after currently executing commands of the GPU context are completed.

[0082] 13. The apparatus of any of clauses 8-12, in which the GPU context comprises a draw call, and execution of the GPU context is jointly scheduled by the GPU driver and a runtime operating system.

[0083] 14. The apparatus of any of clauses 8-13, in which the at least one processor is further configured to adapt a render thread priority associated with a draw task of the GPU context.

[0084] 15. A non-transitory computer-readable medium having program code recorded thereon, the program code executed by a processor and comprising:

[0085] program code to receive, by a graphics processing unit (GPU) driver, a priority change request for a GPU context;

[0086] program code to determine, by the GPU driver, whether to approve the priority change request based on one or more of GPU capabilities, GPU hardware bandwidth, or a power budget; and

[0087] program code to adapt, by the GPU driver, a GPU context priority for the GPU context during runtime from a first priority level to a second priority level based on the determining.

[0088] 16. The non-transitory computer-readable medium of clause 15, in which the program code comprises program code to assign the first priority level for the GPU context at creation of the GPU context.

[0089] 17. The non-transitory computer-readable medium of clause 15 or 16, in which the second priority level is a higher priority level than the first priority level.

[0090] 18. The non-transitory computer-readable medium of any of clauses 15-17, in which the program code comprises:

[0091] program code to remove, by the GPU driver, the GPU context from a first context list corresponding with the first priority level; and

[0092] program code to add, by the GPU driver, the GPU context to a second context list corresponding to the second priority level.

[0093] 19. The non-transitory computer-readable medium of any of clauses 15-18, in which the program code comprises program code to adapt the GPU context priority after currently executing commands of the GPU context are completed.

[0094] 20. The non-transitory computer-readable medium of any of clauses 15-19, in which the GPU context comprises a draw call, and execution of the GPU context is jointly scheduled by the GPU driver and a runtime operating system.

[0095] 21. The non-transitory computer-readable medium of any of clauses 15-20, in which the program code comprises: program code to adapt a render thread priority associated with a draw task of the GPU context.

[0096] 22. An apparatus, comprising:

[0097] means for receiving, by a graphics processing unit (GPU) driver, a priority change request for a GPU context;

[0098] means for determining, by the GPU driver, whether to approve the priority change request based on one or more of GPU capabilities, GPU hardware bandwidth, or a power budget; and

[0099] means for adapting, by the GPU driver, a GPU context priority for the GPU context during runtime from a first priority level to a second priority level based on the determining.

[0100] 23. The apparatus of clause 22, further comprising:

[0101] means for in which the first priority level for the GPU context is assigned at creation of the GPU context.

[0102] 24. The apparatus of clause 22 or 23, in which the second priority level is a higher priority level than the first priority level.

[0103] 25. The apparatus of any of clauses 22-24, further comprising:

[0104] means for removing, by the GPU driver, the GPU context from a first context list corresponding with the first priority level; and

[0105] means for adding, by the GPU driver, the GPU context to a second context list corresponding to the second priority level.

[0106] 26. The apparatus of any of clauses 22-25, further comprising means for adapting the GPU context priority after currently executing commands of the GPU context are completed.

[0107] 27. The apparatus of any of clauses 22-26, in which the GPU context comprises a draw call, and execution of the GPU context is jointly scheduled by the GPU driver and a runtime operating system.

[0108] 28. The apparatus of any of clauses 22-27, further comprising means for adapting a render thread priority associated with a draw task of the GPU context.

[0109] For a firmware and / or software implementation, the methodologies may be implemented with modules (e.g., procedures, functions, and so on) that perform the functions described. A machine-readable medium tangibly embodying instructions may be used in implementing the methodologies described. For example, software codes may be stored in a memory and executed by a processor unit. Memory may be implemented within the processor unit or external to the processor unit. As used, the term “memory” refers to types of long term, short term, volatile, nonvolatile, or other memory and is not limited to a particular type of memory or number of memories, or type of media upon which memory is stored.

[0110] If implemented in firmware and / or software, the functions may be stored as one or more instructions or code on a computer-readable medium. Examples include computer-readable media encoded with a data structure and computer-readable media encoded with a computer program. Computer-readable media includes physical computer storage media. A storage medium may be an available medium that can be accessed by a computer. By way of example, and not limitation, such computer-readable media can include random access memory (RAM) , read-only memory (ROM) , electrically erasable read-only memory (EEPROM) , compact disc read-only memory (CD-ROM) or other optical disk storage, magnetic disk storage or other magnetic storage devices, or other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer. Disk and disc, as used, include compact disc (CD) , laser disc, optical disc, digital versatile disc (DVD) , floppy disk, and  disc, where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media.

[0111] In addition to storage on computer-readable medium, instructions and / or data may be provided as signals on transmission media included in a communications apparatus. For example, a communications apparatus may include a transceiver having signals indicative of instructions and data. The instructions and data are configured to cause one or more processors to implement the functions outlined in the claims.

[0112] Although the present disclosure and its advantages have been described in detail, it should be understood that various changes, substitutions, and alterations can be made without departing from the technology of the disclosure as defined by the  appended claims. For example, relational terms, such as “above” and “below” are used with respect to a substrate or electronic device. Of course, if the substrate or electronic device is inverted, above becomes below, and vice versa. Additionally, if oriented sideways, above, and below may refer to sides of a substrate or electronic device. Moreover, the scope of the present disclosure is not intended to be limited to the particular configurations of the process, machine, manufacture, composition of matter, means, methods, and steps described in the specification. As one of ordinary skill in the art will readily appreciate from the present disclosure, processes, machines, manufacture, compositions of matter, means, methods, or steps, presently existing or later to be developed that perform substantially the same function or achieve substantially the same result as the corresponding configurations described may be utilized according to the present disclosure. Accordingly, the appended claims are intended to include within their scope such processes, machines, manufacture, compositions of matter, means, methods, or steps.

[0113] Those of skill would further appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the present disclosure may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present disclosure.

[0114] The various illustrative logical blocks, modules, and circuits described in connection with the disclosure may be implemented or performed with a general-purpose processor, a digital signal processor (DSP) , an application-specific integrated circuit (ASIC) , a field-programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described. A general-purpose processor may be a microprocessor, but, in the alternative, the processor may be any  conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.

[0115] The steps of a method or algorithm described in connection with the present disclosure may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module may reside in RAM, flash memory, ROM, erasable programmable read-only memory (EPROM) , EEPROM, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor such that the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. The processor and the storage medium may reside in an ASIC. The ASIC may reside in a user terminal. In the alternative, the processor and the storage medium may reside as discrete components in a user terminal.

[0116] The previous description of the present disclosure is provided to enable any person skilled in the art to make or use the present disclosure. Various modifications to the disclosure will be readily apparent to those skilled in the art, and the generic principles defined may be applied to other variations without departing from the spirit or scope of the disclosure. Thus, the present disclosure is not intended to be limited to the examples and designs described, but is to be accorded the widest scope consistent with the principles and novel features disclosed.

Claims

1. [Rectified under Rule 91, 28.09.2023]A processor-implemented method, comprising:receiving, by a graphics processing unit (GPU) driver, a priority change request for a GPU context;determining, by the GPU driver, whether to approve the priority change request based on one or more of GPU capabilities, GPU hardware bandwidth, or a power budget; andadapting, by the GPU driver, a GPU context priority for the GPU context during runtime from a first priority level to a second priority level based on the determining.

2. [Rectified under Rule 91, 28.09.2023]The processor-implemented method of claim 1, in which the first priority level for the GPU context is assigned at creation of the GPU context.

3. [Rectified under Rule 91, 28.09.2023]The processor-implemented method of claim 1, in which the second priority level is a higher priority level than the first priority level.4.[Rectified under Rule 91, 28.09.2023]The processor-implemented method of claim 1, further comprising:removing, by the GPU driver, the GPU context from a first context list corresponding with the first priority level; andadding, by the GPU driver, the GPU context to a second context list corresponding to the second priority level.

5. [Rectified under Rule 91, 28.09.2023]The processor-implemented method of claim 1, in which the adapting is performed after currently executing commands of the GPU context are completed.

6. [Rectified under Rule 91, 28.09.2023]The processor-implemented method of claim 1, in which the GPU context comprises a draw call, and execution of the GPU context is jointly scheduled by the GPU driver and a runtime operating system.

7. [Rectified under Rule 91, 28.09.2023]The processor-implemented method of claim 6, further comprising adapting a render thread priority associated with a draw task of the GPU context.8.An apparatus, comprising:at least one memory; andat least one processor coupled to the at least one memory, the at least one processor configured to:receive, by a graphics processing unit (GPU) driver, a priority change request for a GPU context;determine, by the GPU driver, whether to approve the priority change request based on one or more of GPU capabilities, GPU hardware bandwidth, or a power budget; andadapt, by the GPU driver, a GPU context priority for the GPU context during runtime from a first priority level to a second priority level based on the determining.9.The apparatus of claim 8, in which the at least one processor is further configuredto assign the first priority level for the GPU context at creation of the GPU context.10.The apparatus of claim 8, in which the second priority level is a higher priority level than the first priority level.11.The apparatus of claim 8, in which the at least one processor is further configured to:remove, by the GPU driver, the GPU context from a first context list corresponding with the first priority level; andadd, by the GPU driver, the GPU context to a second context list corresponding to the second priority level.12.The apparatus of claim 8, in which the at least one processor is further configured to perform the adapting of the GPU context priority after currently executing commands of the GPU context are completed.13.The apparatus of claim 8, in which the GPU context comprises a draw call, and execution of the GPU context is jointly scheduled by the GPU driver and a runtime operating system.14.The apparatus of claim 13, in which the at least one processor is further configured to adapt a render thread priority associated with a draw task of the GPU context.15.A non-transitory computer-readable medium having program code recorded thereon, the program code executed by a processor and comprising:program code to receive, by a graphics processing unit (GPU) driver, a priority change request for a GPU context;program code to determine, by the GPU driver, whether to approve the priority change request based on one or more of GPU capabilities, GPU hardware bandwidth, or a power budget; andprogram code to adapt, by the GPU driver, a GPU context priority for the GPU context during runtime from a first priority level to a second priority level based on the determining.16.The non-transitory computer-readable medium of claim 15, in which the program code comprises program code to assign the first priority level for the GPU context at creation of the GPU context.17.The non-transitory computer-readable medium of claim 15, in which the second priority level is a higher priority level than the first priority level.18.The non-transitory computer-readable medium of claim 15, in which the program code comprises:program code to remove, by the GPU driver, the GPU context from a first context list corresponding with the first priority level; andprogram code to add, by the GPU driver, the GPU context to a second context list corresponding to the second priority level.19.The non-transitory computer-readable medium of claim 15, in which the program code comprises program code to adapt the GPU context priority after currently executing commands of the GPU context are completed.20.The non-transitory computer-readable medium of claim 15, in which the GPU context comprises a draw call, and execution of the GPU context is jointly scheduled by the GPU driver and a runtime operating system.21.The non-transitory computer-readable medium of claim 20, in which the program code comprises: program code to adapt a render thread priority associated with a draw task of the GPU context.22.An apparatus, comprising:means for receiving, by a graphics processing unit (GPU) driver, a priority change request for a GPU context;means for determining, by the GPU driver, whether to approve the priority change request based on one or more of GPU capabilities, GPU hardware bandwidth, or a power budget; andmeans for adapting, by the GPU driver, a GPU context priority for the GPU context during runtime from a first priority level to a second priority level based on the determining.23.The apparatus of claim 22, further comprising:means for in which the first priority level for the GPU context is assigned at creation of the GPU context.24.The apparatus of claim 22, in which the second priority level is a higher priority level than the first priority level.25.The apparatus of claim 22, further comprising:means for removing, by the GPU driver, the GPU context from a first context list corresponding with the first priority level; andmeans for adding, by the GPU driver, the GPU context to a second context list corresponding to the second priority level.26.The apparatus of claim 22, further comprising means for adapting the GPU context priority after currently executing commands of the GPU context are completed.27.The apparatus of claim 22, in which the GPU context comprises a draw call, and execution of the GPU context is jointly scheduled by the GPU driver and a runtime operating system.28.The apparatus of claim 27, further comprising means for adapting a render thread priority associated with a draw task of the GPU context.

Images