GPU circuit self-context storage during context unmapping

The SDMA circuit with a scheduling circuit optimizes GPU context switching by using MQD addresses to streamline context register management, reducing latency and improving system performance.

JP2026522376APending Publication Date: 2026-07-07ADVANCED MICRO DEVICES INC

Patent Information

Authority / Receiving Office
JP · JP
Patent Type
Applications
Current Assignee / Owner
ADVANCED MICRO DEVICES INC
Filing Date
2024-06-10
Publication Date
2026-07-07

AI Technical Summary

Technical Problem

Conventional GPU context switching procedures involve significant overhead due to handshaking with the Direct Memory Access (DMA) circuit, leading to increased memory traffic and degraded system performance.

Method used

Implementing a System Direct Memory Access (SDMA) circuit with a scheduling circuit that generates a memory queue descriptor (MQD) address for efficient context switching, allowing the SDMA circuit to save and map context registers without additional calls to the scheduling circuit.

Benefits of technology

This approach reduces latency and optimizes GPU performance by minimizing the workload associated with context switching, enhancing system responsiveness and efficiency.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 2026522376000001_ABST
    Figure 2026522376000001_ABST
Patent Text Reader

Abstract

A system and method for efficient context switching in a multithreaded processor are disclosed. The processing system comprises a direct memory access module configured to detect preemption requests generated by a scheduling circuit. In response to a preemption request, the direct memory access module determines whether the execution of a first task among several tasks needs to be replaced by the execution of a second task. If replacement is necessary, the module stores a first set of registers associated with the first task at a memory location transmitted by the scheduling circuit and queues the second task for execution. The memory location is transmitted by the scheduling circuit as part of the preemption request.
Need to check novelty before this filing date? Find Prior Art

Description

Background Art

[0001] (Description of Related Art) In computer graphics and video processing, context switch refers to the process of switching between different tasks or threads running on a Graphics Processing Unit (GPU). This can occur when the GPU is required to execute multiple tasks simultaneously, such as rendering multiple frames of a video game or playing video. When a context switch occurs, the GPU can save the current state of the task it is working on, then load the state of the new task and start its execution. This process can add additional overhead and latency to the GPU's operation, which can affect the performance and responsiveness of the system.

[0002] On the GPU, a context is the state of all GPU resources that can be used during rendering and computational operations, such as memory objects, shaders, pipeline states, etc. Swapping contexts can be costly because the GPU has to reload the context state and wait for the completion of the previous operation, but since the GPU can only execute one context at a time, parallel operations need to be performed.

[0003] Conventional GPU context switch procedures can involve significant overhead. For example, performing a context switch can include handshaking with the Direct Memory Access (DMA) circuit, unmapping existing context data, writing the unmapped context data to memory, and mapping the new context to the DMA circuit. The overhead associated with these procedures can, for example, increase memory traffic and degrade system performance when data is moved between registers and memory.

[0004] Considering the above, an improved system and method for GPU context switching is needed.

[0005] The advantages of the methods and mechanisms described herein can be better understood by referring to the following description in conjunction with the accompanying drawings. [Brief explanation of the drawing]

[0006] [Figure 1] This is a block diagram of one embodiment of a computing system. [Figure 2] This block shows a heterogeneous system architecture for context switching. [Figure 3] This is a block diagram showing a process control block that includes at least several registers related to the process. [Figure 4] This is a generalized flowchart illustrating a method for switching contexts between applications. [Figure 5] This is a generalized flowchart illustrating a method for preempting queues during a context switching process. [Modes for carrying out the invention]

[0007] The following description includes numerous specific details to provide a full understanding of the methods and mechanisms presented herein. However, those skilled in the art should recognize that various embodiments can be implemented without these specific details. In some cases, well-known structures, components, signals, computer program instructions, and techniques are not shown in detail to avoid obscuring the methods described herein. For simplicity and clarity, please understand that the elements shown in the figures are not necessarily drawn to scale. For example, the dimensions of some elements may be exaggerated relative to others.

[0008] A system, apparatus, and method for performing context switching using a System Direct Memory Access (SDMA) circuit is disclosed. In various embodiments, a graphical processing unit (GPU) supporting multiple context-based processes comprises an SDMA circuit and a scheduling circuit. The scheduling circuit is configured to schedule work items to be processed by one or more shaders associated with the GPU. Each work item (or referred to as a task or application) includes several context registers indicating the current state (or context) of the work item when it is being executed or queued for execution. During context switching, the GPU is configured to save the context registers associated with a first work item to memory, clear all active data queues, and queue the execution of a second work item, depending on whether it has identified a preemption request. In one embodiment, the preemption request is generated by the scheduling circuit for the SDMA circuit. Furthermore, the memory location where the registers of the first work item are saved is specified by the scheduling circuit in the preemption request, thereby enabling the SDMA circuit to save these registers to the memory location without calling the scheduling circuit. Therefore, the scheduling circuit can map the register associated with the second work item to the SDMA circuit without needing to store the register associated with the first work item. These and other features are described herein.

[0009] Referring to Figure 1, a block diagram of one embodiment of the computing system 100 is shown. In one embodiment, the computing system 100 includes a central processing unit (CPU) 102, a graphics processing unit (GPU) 104, GPU memory 106, and CPU memory 108. The GPU 104 further includes a system direct memory access (SDMA) circuit 110 (or "engine") and a shader 112. The shader 112 includes a plurality of computing units, shown as compute units 114A to 114N and collectively referred to as compute unit 114. In one embodiment, the shader 112 includes additional compute units not shown in Figure 1.

[0010] In some embodiments, the GPU is a vector processor, a general-purpose GPU (GPGPU), a non-scalar processor, a highly parallel processor, an artificial intelligence (AI) processor, an inference circuit, a machine learning processor, or another multithreaded processing unit. The GPU 104 further includes a scheduling circuit 116. In one embodiment, the scheduling circuit 116 is hardware or software (a software program or algorithm) running on the GPU 104. The scheduling circuit 116 includes one or more subunits, indicated as subunits 118A to 118N, each subunit 118 assisting the scheduling circuit 116 in assigning tasks to various units of the GPU 104, for example, based on instructions received from the CPU 102. In some embodiments, subunits 118A to 118N are configured to use one or more parameters, including but not limited to a task dependency graph, a task data mapping, or a task dispatch list, to assist the scheduling circuit 116 in scheduling tasks. For example, using these parameters, a given subunit 118 is configured to generate data requirements for a given task in order to schedule that task. In another example, subunit 118 may be configured to generate a set of read and write configurations for a given task using parameters. In yet another example, a given subunit 118 may be configured to generate mappings to the respective objects and / or data of a task using parameters. Briefly, subunits 118A to 118N use the above parameters to enable the scheduling circuit 116 to make decisions about scheduling tasks and their subdata blocks for one or more of the computing units 114A to 114N, and other embodiments are also conceivable. As used herein, in various embodiments, the term “unit” refers to a circuit or circuit configuration. Thus, a subunit may be considered a subcircuit, etc.

[0011] In one embodiment, subunits 118A to 118N include circuits configured to perform various tasks, including generating scheduling data based at least partially on the above parameters, in order to enable the scheduling circuit to schedule tasks to one or more computing units 114A to 114N. Alternatively, each subunit 118A to 118N may be microcoded and executed within the scheduling circuit 116. For example, each subunit 118 may have programmable instructions, which are executed by the scheduling circuit 116 to schedule tasks based on one or more scheduling algorithms. These scheduling algorithms may include, for example, round-robin scheduling, priority-based scheduling, nearest due-first (EDF) scheduling, machine learning-based scheduling, etc. In some other embodiments, subunits 118A to 118N are configured as a combination of hardware circuits and programmable instructions. In embodiments where the subunits are software, the software includes executable instructions to execute algorithms to accomplish various tasks.

[0012] During the operation of the computing system 100, the CPU 102 issues commands or instructions to the GPU 104 to initiate scheduling of multiple tasks (applications or work items). A task, as used herein, is defined as a unit of execution representing a program instruction executed by the GPU 104. For example, a task includes a thread of a work item executed by the GPU 104. In one embodiment, multiple tasks are executed according to a single-instruction multiple-data (SIMD) protocol, and as a result, each task has associated task data requirements (i.e., data blocks required for the execution of each task), as described above. Furthermore, each task is executed on one or more of the computing units 114A to 114N.

[0013] In one embodiment, the GPU 104 may also include control logic 120 (alternatively referred to as “context switching logic 120”) for preempting the task currently running within the shader 112. The context switching logic 120 includes, for example, instructions for suspending the currently running task and saving its current state (e.g., the state of the shader 112, the state of the command processor, etc.) to a specified memory location. In one embodiment, to switch between tasks, the scheduling circuit 116 may use the context switching logic 120 to generate a preemption request whenever it is determined that the currently running task should be paused so that another task can be queued for execution. In use in the present invention, the context can be thought of as the environment in which the kernel runs, and as the area in which synchronization and memory management are defined. The context is associated with a set of devices, the memory accessible to those devices, the corresponding memory properties, and one or more command queues used to schedule the execution of kernels or operations on memory objects. Furthermore, the context also defines the memory and current state of task execution.

[0014] In one embodiment, context switching, i.e., saving the state of the currently running task in order to pause task execution and queue another task, is required when the CPU 102 is interrupted by an on-chip timer or peripheral device (not shown). In a multiprocessing environment, context switching may occur when the CPU 102 switches from the execution of one task to the execution of another. In steady-state operation, the CPU 102 must save the state of the current task in memory, including the contents of general-purpose registers (GPRs), floating-point registers (FPRs), and other processor state registers. Then, before starting execution, it loads the state of the next task, i.e., the "context," into the registers. Various registers and state information for a given task are shown in detail in Figure 3.

[0015] Typically, in the GPU 104, the SDMA circuit 110 is a dedicated hardware component responsible for managing data transfer between the GPU 104 and the CPU memory 108. In a context switching scenario, the SDMA circuit 110 may be used to perform a context switch by transferring the context of the current task from the GPU 104 to the CPU memory 108, and then transferring the context of a new task back from the CPU memory 108 to the GPU 104.

[0016] During context switching, the scheduling circuit 116 generates a preemption request based on instructions received from the CPU 102. In one embodiment, a preemption request is generated when the CPU 102 determines one or more context switching conditions. For example, if a higher-priority queue becomes ready, the currently running task queue is paused to execute the higher-priority queue. In other examples, context switching is initiated in response to quantum being enabled, for example, when the processing duration of a task queue is exceeded and another queue of the same priority is ready for processing. Still other examples in which context switching is initiated may include quantum being disabled, the current queue wavefront packet preempting the queue from the compute pipeline and schedule, the current queue and compute pipeline becoming empty and any other queue in the same compute pipeline becoming ready, and / or the operating system requesting the current queue to preempt.

[0017] In response to a preemption request, the scheduling circuit 116 receives an index from the SDMA circuit 110 when it is ready to switch between processes. Upon receiving this index, the scheduling circuit 116 stores the current context of the ongoing process in a memory location (e.g., a memory address in CPU memory 108) and maps the data related to the other task onto the SDMA circuit 110. However, this GPU context switching procedure can be inefficient because the scheduling circuit 116 incurs a high workload due to the "handshake" operation with the SDMA circuit 110, such as unmapping the registers associated with the original task from the SDMA circuit 110 and writing these registers to the memory location. Furthermore, the scheduling circuit 116 may also utilize considerable computing resources to map the new context onto the SDMA circuit 110 by writing the registers related to the new task to the SDMA circuit 110.

[0018] In various embodiments described herein, to facilitate efficient context switching between tasks, the scheduling circuit 116 generates a memory queue descriptor (MQD) address (for example, as an address pointer) as part of a preemption request, and as a result, the SDMA circuit 110 can use the MQD address to store the current context of the task in progress at a specified memory location in CPU memory 108. This allows the scheduling circuit 116 to have an efficient "handshake" operation with the SDMA circuit 110, since the scheduling circuit 116 no longer needs to store the current context of the task in progress at a memory location. In one embodiment, the MQD address includes at least a memory address pointer that points to a specified memory location where the current context of the task in progress needs to be stored.

[0019] Referring to Figure 2, a heterogeneous system architecture (HSA) 200 for context switching between tasks is disclosed. As shown in the figure, the execution of various applications 202A to 202N is initiated and controlled to be executed by the CPU 240 by distributing the processing associated with a given application 202 across other processing resources such as the CPU 240 and the GPU 230.

[0020] In one example, the CPU 240 inputs commands for various applications 202 into appropriate process control blocks (not shown) for the GPU 230 to retrieve and execute. Exemplary embodiments of process control blocks are shown in detail in Figure 3. Multiple process control blocks may be held in system memory 214. Furthermore, as referred to herein, application 202 is a combination of program portions to be executed on one or more compute units (e.g., compute unit 114) scheduled for execution on the GPU 230. In various embodiments, the operating system (OS) can provide common services that may include scheduling, fault management, interrupt service, and handling of input and output for applications 202 to run on and within the CPU 240. For example, application 202 includes various programs or commands for executing user compute on the CPU 240.

[0021] In one example, the kernel driver 204 (or "KD204") implements an API through which the CPU 240 or an application 202 running on the CPU 240 can invoke functions of the GPU 230, particularly the scheduling circuit 232. Furthermore, the KD204 can perform scheduling of processes running on the GPU 230, for example, by using logic to maintain a priority list of processes running on the GPU 230. These processes are then scheduled by the scheduling circuit 232 to run on the computing units (not shown) of the GPU 230.

[0022] In one embodiment, the KD204 maps the command queue associated with application 202 to scheduling circuit 232 hardware, so that once the mapping is established, application 202 can directly send commands to system memory direct access (SDMA) circuit 208. In one embodiment, such mapping is performed by the KD204. For example, the mapping may be performed by accessing and programming management input / output (MMIO) registers associated with the SDMA circuit 208 via a system management network (not shown).

[0023] In the HSA model, user-level applications such as application 202 cannot access the privileged write and read pointer registers (WPTR / RPTR) associated with the SDMA circuit 208. Therefore, a doorbell mechanism is introduced to allow applications to update these registers without direct access. The doorbell mechanism allows applications to update registers via an allocated doorbell address space. In one example, the application first updates a copy of the register in memory and then writes the same data to the doorbell memory management input / output (MMIO) space of the GPU 230. In one embodiment, the doorbell function described herein can function as a hardware data path between application 202 and the SDMA circuit 208, enabled by a hardware interface 216. For example, in one embodiment, the doorbell function uses the Advanced Extensible Interface (AXI) traffic format, and as a result, KD204 uses this function to assign a dedicated doorbell address to the SDMA circuit 208 (for example, by programming a given SDMA MMIO register). Application 202 can then use a hardware data path to update a buffer (e.g., a ring buffer) write pointer register for the SDMA circuit 208 and notify the SDMA circuit 208 about one or more tasks assigned to it. This process is called "ringing a doorbell." When the SDMA circuit 208 detects a doorbell from a given application 202, it compares the doorbell address to a dedicated SDMA doorbell address in a given MMIO register (previously programmed by KD204), and if the two addresses match, it accepts data associated with one or more tasks.

[0024] In one example, the SDMA circuit 208 is a shared resource for applications 202 including, but not limited to, graphics, computing, video, image, and operating system level applications. Further, KD204 in one embodiment functions as a central controller and uses a ring buffer to process communication between application 202 and SDMA circuit 208. For example, application 202 transmits data to KD204 from each process control block, and KD204 inserts this data into the ring buffer. Information related to each ring buffer, such as the ring buffer base address, ring buffer read and write pointers, and other data, is included in a predetermined memory queue descriptor (MQD) 210.

[0025] As described herein, a memory queue descriptor (e.g., MQD210) is a data structure that describes the properties of a memory queue. A memory queue is a type of memory buffer that can be used to store commands and data executed on GPU230. MQD210 includes information such as the start address and size of the memory queue, the current read and write pointers of the memory queue, and any other optional metadata necessary to manage the memory queue. MQD210 is used together with the scheduling circuit 232 to manage the execution of commands on GPU230. When a task or command is executed on GPU230, it is added to the memory queue, and the command scheduling circuit 232 reads MQD210 to determine the properties of the memory queue and the position of the next command to be executed. In one embodiment, MQD210 can also be used to manage the memory allocation of the memory queue by tracking the current and maximum allocations of the queue and triggering reallocation as needed.

[0026] In one embodiment, each application 202 is associated with an individual memory queue, and as a result, KD204 can generate MQDs 210A - 210N that each describe an individual memory queue of application 202. In one embodiment, KD204 generates MQDs 210A - 210N associated with applications 202A - 202N and combines these MQDs 210A - 210N into an array 212 that can be referred to as an "execution list". This array 212 or execution list is stored in system memory 214. According to this embodiment, the scheduling circuit 232 uses the execution list to determine the processes to be actively executed for application 202 based on the instructions received from CPU 240. Each MQD210 within array 212 can include an active queue. In one example, the active queues are each associated with a compute pipeline and can include independent processes or a subset of processes associated with the execution of application 202.

[0027] In one embodiment, each MQD210 provides the ability for the operating system to preempt an active process from sending a workgroup for which shader resources have not yet been allocated. Any interrupted queue (and its associated process) can be rescheduled to continue later or can be terminated if the operating system desires. Interrupting an ongoing process and putting a new process into the queue is referred to herein as a "context switch".

[0028] During such a context switching process, for example, the active execution list associated with the original process, as indicated by array 212, is replaced by a different execution list associated with the new process due to one or more context switching factors. These factors may include executions in higher-priority queues, exceeding the processing duration of queues, and other queues of the same priority that are ready for processing, or the current queue wavefront packet preempting the queue from the compute pipeline. In one embodiment, each application 202 is associated with a DMA down queue and / or DMA up queue, their description indicated by their respective MQD 210. For example, during context switching, the DMA down queue 218A may indicate a memory queue that stores information about one or more processes of application 202A that are being interrupted from current execution (i.e., unmapped from the SDMA circuit 208). Furthermore, one or more new processes that are queued for execution instead are stored in another memory queue, indicated by one or more of the DMA up queues 220A-220N, and as a result, when the unmapping of the DMA down queue 220A is complete, these are mapped to the SDMA circuit 208. Based on queue mapping and unmapping, KD204 can also update array 212.

[0029] In one embodiment, whenever the need for a context switch is determined, the scheduling circuit 232 generates a preemption request for the SDMA circuit 208 to process. In one embodiment, the preemption request generated by the scheduling circuit 232 includes the memory queue descriptor address (MQDA) (e.g., as an address pointer) of the operating system allocation array 212 associated with the original process. In one embodiment, the MQDA indicates a memory location where the current state of the original process is stored, including at least one context register, so that the original process can be restored for execution at a later time in the processing cycle. In one example, one or more context registers, along with other information associated with the original process, may be accessed from the process control block associated with the original process. In one example, each context register indicates the state of the GPU 230 during the execution of the original process. Context registers may include general-purpose registers (GPRs), floating-point registers (FPRs), condition code registers (CCRs), and other processor registers.

[0030] In one embodiment, the MQDA generated by the scheduling circuit as part of a preemption request allows the SDMA circuit 208 to save the context of the original process without calling the scheduling circuit 232 to save the context of the original process. Once the SDMA circuit 208 stores the current state of the original process at the memory location indicated by the MQDA, the SDMA circuit 208 can send an acknowledgment to the scheduling circuit 232. In one embodiment, this acknowledgment is sent in the form of an interrupt. Other embodiments are also possible.

[0031] Based on receiving an acknowledgment from the SDMA circuit 208, the scheduling circuit 232 maps a new context (e.g., registers associated with a new process) to the SDMA circuit 208. In one embodiment, mapping a new context includes at least loading data associated with the new process for the new process in the form of an MQD array (similar to the array 212 described above). In one embodiment, the context switching process allows the scheduling circuit 232 to simultaneously generate preemption requests for multiple queues that need to be dequeued and wait for them all to be cleared, as described above. This optimization can reduce the latency required to dequeuing the queues sequentially and optimize GPU performance. Such optimizations can further simplify the software running on the scheduling circuit that is performed to unmap the queues of the original process from the SDMA circuit 208.

[0032] Referring next to Figure 3, an exemplary process control block 300 is shown. As described above, the process control block contains data related to one or more applications scheduled to be executed by the processing device. In one embodiment, a scheduling circuit (e.g., the scheduling circuit 232 in Figure 2) uses the information present in a given process control block to schedule one or more processes based on instructions received from a central processing unit.

[0033] As shown in the figure, the process control block 300 includes a process ID 302, a process state 304, a program counter 306, a register 308, memory limit data 310, an open file list 312, and other data 314. In one embodiment, the process ID 302 includes a unique identifier used to identify a given process. Whenever a new process is created by the user, the operating system assigns a number to that process. This number becomes a unique identifier for the process and helps to distinguish it from all other processes present in the system. The operating system can set a limit on the maximum number of processes that can be processed at one time. For example, if there are currently n processes queued for execution in the system, the process ID 302 can take a value between 0 and n-1. The operating system assigns the value 0 to the first process arriving in the system, the value 1 to the next process, and so on. At this point, if a process has been assigned the value n-1 and a new process arrives, the operating system wraps around and assumes that the process with process ID 0 has finished, and assigns the value 0 to the newly arrived process. Process ID 302 may be assigned in any numerical or alphanumeric format, and such embodiments are conceivable.

[0034] The process state 304 includes, but is not limited to, different states of a given process, such as standby, running, ready, blocked, stopped, etc. In one embodiment, the process state 304 holds the current state of each process; for example, if a process is currently running, the process state can indicate the "running state" of that process. The information in the process state 304 field is stored in an encoded form.

[0035] The program counter 306 is an identifier that contains a pointer to the next instruction that the CPU should execute for a given process. For example, the program counter 306 field contains at least the address of the next instruction to be executed in the process.

[0036] Register 308 stores the values ​​of the CPU registers of a given process that was last executed. In one embodiment, whenever an interrupt occurs and there is a context switch between processes, temporary information is stored in the register, so that when a process resumes execution, the processing device can accurately resume the process from its last execution cycle. Furthermore, for the purposes of this disclosure, each of these registers 308 contains data associated with a given queue (comprising an active process or processes queued for execution). Thus, other embodiments are conceivable.

[0037] In one embodiment, register 308 includes one or more registers such as a control register 320, a base register 322, a write pointer register 324, a read pointer register 326, a doorbell register 328, a dequeue request register 330, and an address register 332. Other possible registers are also conceivable. In one embodiment, the system described herein may utilize a ring buffer data structure to handle different data when performing one or more tasks. A ring buffer is a data structure that uses a single fixed-size buffer as if it were end-to-end connected. The buffer operates in a "circular" manner, where the next position to be written to is determined by the current position, and the first position to be read is determined by the oldest stored value. In one embodiment, the control register 320 indicates information about ring buffer data, such as ring buffer enablement and ring buffer size for a given memory queue (such as a memory queue described using MQD206). Furthermore, the base register 322 includes the ring buffer base address of a given queue in memory. The write pointer register 324 and the read pointer register 326 each contain the current ring buffer write pointer and the current ring buffer read pointer for a given queue.

[0038] The doorbell register 328 contains data related to a doorbell index that identifies a given memory queue. For example, in one embodiment, the doorbell register 328 includes a memory-mapped I / O (MMIO) base address register. The doorbell register 328 may further comprise multiple doorbells for activating doorbell notifications in response to receiving a doorbell trigger from the driver. As described above, the doorbell function provides a hardware data path between the CPU driver and the SDMA circuit. The driver assigns a dedicated doorbell address to the SDMA circuit, uses the hardware data path to update the write pointer register 324, and notifies the SDMA circuit 208 about one or more tasks assigned to the SDMA circuit.

[0039] In one embodiment, register 308 comprises one or more context switching control registers, such as a dequeue request register 330, and an address register 332. For example, a kernel driver (such as kernel driver 204 shown in Figure 2) programs the address register 332 to notify the SDMA of the memory address of the memory queue descriptor (MQD) of a given queue. Furthermore, the driver sets the dequeue request register 330 to a predetermined binary value, for example, 1, to notify the SDMA to preempt the given queue. Depending on such programming of the registers, the SDMA can store one or more context registers having the given queue in the memory location of the MQD and set the dequeue request register 330 to 0 to confirm that it is ready to preempt the given queue. Based on the above acknowledgments, the scheduling circuit can map different queues for the SDMA without needing to store one or more context registers for the original queue, because these are already stored by the SDMA.

[0040] The memory limit field 310 contains information about the memory management system used by the operating system. This information may include page tables, segment tables, etc. Furthermore, the open file list 312 contains a list of files opened for a given process. Other data 314 may include information about the amount of CPU used for the execution of a given process, time constraints, job or process number, etc.

[0041] Referring to Figure 4, a method 400 for context switching is disclosed. As described above, during GPU processing, the SDMA circuit preempts a given queue based on information received from the scheduling circuit. Furthermore, the information received from the scheduling circuit includes, at least partially, MQD addresses, and as a result, the SDMA circuit can store one or more context registers associated with the active application queue in a memory location specified by the MQD address without calling the scheduling circuit. Although method 400 is described in relation to context switching performed by the SDMA circuit, in some alternative embodiments, a processing unit other than the SDMA circuit, such as a command processor, may be configured for similar switching contexts (e.g., context switching for graphics tasks) using the techniques described herein.

[0042] The SDMA can initiate preemption from a given application queue based on an identified preemption request (block 402). In one embodiment, a preemption request is generated by the scheduling circuit when it is determined that an ongoing process (identified by the application queue) should be interrupted so that another process can be queued for execution (i.e., the context needs to be switched). In various examples, such a decision is made by the scheduling circuit based on one or more factors, such as when a higher-priority queue becomes ready, when quantum is enabled, or when quantum is disabled.

[0043] The SDMA circuit, upon identifying a preemption request, determines whether a context switch is possible (conditional block 404). In some embodiments, there may be scenarios where a context switch is not possible (conditional block 404: "no"). In such cases, the SDMA instructs the GPU to continue executing the current queue (block 406). However, if a context switch is possible (conditional block 404: "yes"), the SDMA clears the current application queue (block 408). For example, to clear the application queue for an ongoing graphics application, the graphics pipeline may be configured to wait until a given processing unit has completed executing the current instruction.

[0044] When the current application queue is cleared, the SDMA circuit stores the current application data at a specified memory location (block 410). In one embodiment, the current application data includes at least a context register indicating the current state of the current application. Furthermore, the specified memory location is indicated in one embodiment by a scheduling circuit within a generated preemption unit. For example, the scheduling circuit may write to a ring buffer preemption register associated with the current application and notify the SDMA circuit of the MQD address of the current application. Based on the MQD address, the SDMA circuit may store the context register associated with the current application at the memory location indicated by the MQD address.

[0045] The SDMA circuit resets the application queue after storing the context registers associated with the current application (block 412). In one embodiment, to reset the application queue, the SDMA circuit clears the application queues of all processes associated with the current application. According to this embodiment, the SDMA circuit is configured to wait for a predetermined period before resetting the queue, so that one or more required internal operations are completed before the queue is reset. Furthermore, once the SDMA has finished the reset, the SDMA clears the queue reset field of the queue and clears all registers associated with the queue to indicate default values. This may be done as an acknowledgment that the queue reset is complete.

[0046] When a preempted queue is reset, the SDMA circuit clears the dequeue request register (block 414). As described above, the scheduling circuit driver sets the dequeue request register to a predetermined value (e.g., 1) to notify the SDMA circuit to preempt from the current queue. Once preemption is complete, the SDMA circuit can clear the dequeue request register by setting it to another predetermined value (e.g., 0) to indicate that preemption is complete. The SDMA circuit sends an acknowledgment of the completion of preemption for the current application queue to the scheduling circuit in the form of an interrupt (block 416).

[0047] In one embodiment, the SDMA circuit accepts new application data after preemption of the current application queue is complete (block 418). According to this embodiment, the new application data includes information related to the last saved state of the new application or process. For example, the new application data includes the context register associated with the new application, the last processor state, timestamp information, etc. In one embodiment, the new application data is mapped onto the SDMA circuit by the scheduling circuit. Once the mapping is complete, the SDMA circuit queues the new application for execution (block 420). Execution continues until all processes in the application queue are completed, until the system becomes idle, and / or until another preemption request is identified.

[0048] Referring to Figure 5, a method 500 for queue preemption during a context switching process is disclosed. As described above, the scheduling circuit generates preemption requests to switch between one process and another, depending on one or more context switching factors. Based on the preemption requests, the SDMA circuit stores data related to the currently running process and queues the new process for execution.

[0049] In one embodiment, the scheduling circuit sends a generated preemption request (block 502) when it determines that a context switch is required. According to this embodiment, the preemption request includes at least a memory queue descriptor (MQD) address, and as a result, the SDMA circuit can use that address to store the current state of the running process (e.g., indicated by one or more context registers) at the memory location specified by that address without calling the scheduling circuit.

[0050] After a preemption request is sent, the scheduling circuit determines whether an interrupt signal has been received from the SDMA circuit (conditional block 504). In one embodiment, the interrupt signal from the SDMA circuit indicates an acknowledgment that the SDMA circuit has preempted the queue associated with the process that was running and stored the current state of the process at the memory location specified by the address. If no interrupt has been received yet (conditional block 504: "no"), the scheduling circuit is configured to wait for an interrupt signal, for example, until an interrupt signal is received or a timeout period has elapsed (block 506).

[0051] However, if an interrupt signal is received (conditional block 504: "yes"), the scheduling circuit maps new application data onto the SDMA circuit (block 508). As described above, the new application data includes context registers associated with the new application or process to be queued for execution, last processor state, timestamp information, etc.

[0052] It should be emphasized that the embodiments described above are merely non-limiting examples of embodiments. A large number of variations and modifications will become apparent to those skilled in the art once the above disclosure is fully understood. The following claims are intended to be construed as encompassing all such variations and modifications.

Claims

1. It is a system, Scheduling circuit and It includes a direct memory access circuit, The direct memory access circuit is To detect preemption requests generated by the scheduling circuit, In response to the detection of the preemption request, it is determined whether the execution of the first task among the multiple tasks needs to be replaced by the execution of the second task, In response to replacing the execution of the first task with the execution of the second task, a plurality of first registers associated with the first task are stored at a memory location transmitted by the scheduling circuit, The second task mentioned above is put into a queue for execution, It is configured to do, system.

2. The memory location is transmitted by the scheduling circuit as part of the preemption request. The system according to claim 1.

3. The memory location is transmitted by the scheduling circuit as a memory queue descriptor (MQD) address pointer. The system according to claim 2.

4. The first plurality of registers include at least a dequeue request register, The direct memory access circuit, in response to the detection of the preemption request, Clearing the aforementioned dequeuing request register, Sending an interrupt signal to the aforementioned scheduling circuit, It is configured to do, The system according to claim 1.

5. The scheduling circuit is configured to map a second set of registers associated with the second task to the direct memory access circuit in response to the reception of the interrupt signal. The system according to claim 4.

6. The first set of registers includes one or more of the following: a ring buffer write pointer register, a ring buffer read pointer register, a ring buffer control register, a ring buffer base address, and a doorbell register. The system according to claim 1.

7. The first task described above is associated with the application, The system comprises a kernel driver configured to map one or more command queues associated with the first task to the scheduling circuit. The system according to claim 1.

8. It is a method, Detecting preemption requests generated by the scheduling circuit, In response to detecting the aforementioned preemption request, it is determined whether the execution of the first task among the multiple tasks needs to be replaced by the execution of the second task, In response to replacing the execution of the first task with the execution of the second task, a plurality of first registers associated with the first task are stored at a memory location transmitted by the scheduling circuit, This includes queuing the second task for execution, method.

9. The memory location is transmitted by the scheduling circuit as part of the preemption request. The method of claim 8.

10. The memory location is transmitted by the scheduling circuit as a memory queue descriptor (MQD) address pointer. The method of claim 9.

11. The first plurality of registers include at least a dequeue request register, The method, in response to detecting the preemption request, Clearing the aforementioned dequeuing request register, This includes transmitting an interrupt signal to the scheduling circuit, The method of claim 8.

12. The scheduling circuit includes, in response to receiving the interrupt signal, mapping a second set of registers associated with the second task to a direct memory access circuit. The method according to claim 11.

13. The first set of registers includes one or more of the following: a ring buffer write pointer register, a ring buffer read pointer register, a ring buffer control register, a ring buffer base address, and a doorbell register. The method of claim 8.

14. A computing system, Central processing unit and A graphics processing unit comprising a scheduling circuit and a system direct memory access circuit, The aforementioned system direct memory access circuit is To detect preemption requests generated by the scheduling circuit, In response to the detection of the preemption request, it is determined whether the execution of the first task among the multiple tasks needs to be replaced by the execution of the second task, In response to replacing the execution of the first task with the execution of the second task, a plurality of first registers associated with the first task are stored at a memory location transmitted by the scheduling circuit, The second task mentioned above is put into a queue for execution, It is configured to do, Computing system.

15. The memory location is transmitted by the scheduling circuit as part of the preemption request. The computing system according to claim 14.

16. The memory location is transmitted by the scheduling circuit as a memory queue descriptor (MQD) address pointer. The computing system according to claim 15.

17. The first plurality of registers include at least a dequeue request register, The circuit of the computing system, in response to the detection of the preemption request, Clearing the aforementioned dequeuing request register, Sending an interrupt signal to the aforementioned scheduling circuit, It is configured to do, The computing system according to claim 14.

18. The scheduling circuit includes a circuit configured to map a second set of registers associated with the second task to the system direct memory access module in response to the reception of the interrupt signal. The computing system according to claim 17.

19. The first set of registers includes one or more of the following: a ring buffer write pointer register, a ring buffer read pointer register, a ring buffer control register, a ring buffer base address, and a doorbell register. The computing system according to claim 14.

20. The first task described above is associated with the application, The computing system's circuitry is configured to map one or more command queues associated with the first task to the scheduling circuitry, so that the application can send one or more commands to the system direct memory access module. The computing system according to claim 14.