Controlling scheduling of a GPU

Abstract

This application relates to controlling scheduling of a GPU. Operation of the GPU is controlled based on one or more deadlines by which one or more GPU tasks must be completed and estimates of time required to complete execution of a first GPU task (that is currently being executed) and time required to execute one or more other GPU tasks (that are not currently being executed). Based on a comparison between the deadlines and the estimates, a context switch can or can not be triggered.

Description

[0001] This application is a divisional application of the application filed on December 9, 2016, with application number 201680069957.9 and invention title "Controlling GPU Scheduling". Technical Field

[0002] This application relates to the field of GPU scheduling. Background Technology

[0003] A Graphics Processing Unit (GPU) is a processor with a highly parallel architecture and is typically used for graphics operations such as texture mapping and rendering polygons. GPUs (which may also be called VPUs) can also be used for non-graphics applications, such as performing data-parallel computations. A GPU can run several processes, and the scheduling system within the GPU selects which process to run next. Scheduling is typically performed based on synchronization (i.e., running tasks in an order determined by their interdependencies) and priority (i.e., running higher-priority tasks before lower-priority tasks). If context switching is enabled, a higher-priority task (e.g., a rendering task associated with user interaction) will interrupt a lower-priority task (e.g., rendering a live wallpaper) once it can run (i.e., it is not blocked by synchronization).

[0004] The implementations described below are provided as examples only and are not limitations of any or all of the known methods for controlling scheduling within a GPU. Summary of the Invention

[0005] An overview of the invention is provided to introduce, in a simplified form, the concept selection that will be further described in the detailed description below. This overview is not intended to identify key or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

[0006] The operation of the GPU is controlled based on one or more deadlines for completing one or more GPU tasks, as well as estimates of the time required to complete the execution of the first GPU task (currently being executed) and the time required to execute one or more other GPU tasks (currently not being executed).

[0007] A context switch may or may not be triggered based on a comparison between the deadline and the estimate.

[0008] The first aspect provides a method for scheduling tasks within a GPU, the method comprising: while executing a first GPU task, in response to a second GPU task being ready to run, determining which of the first GPU task and the second GPU task has a higher priority; in response to determining that the second GPU task has a higher priority than the currently executing first GPU task; estimating the completion time of each of the first GPU task and the second GPU task; using the estimated completion time to determine whether the first GPU task and the second GPU task can be completed before a deadline associated with the second GPU task; and in response to determining that both the first GPU task and the second GPU task can be completed before the deadline associated with the second GPU task, allowing the first GPU task to continue execution.

[0009] The second aspect provides a graphics processing unit (GPU) including a microprocessor configured to: while executing a first GPU task, in response to a second GPU task being ready to run, determine which of the first GPU task and the second GPU task has a higher priority; and in response to determining that the second GPU task has a higher priority than the currently executing first GPU task; estimate the completion time of each of the first GPU task and the second GPU task; use the estimated completion time to determine whether the first GPU task and the second GPU task can be completed before a deadline associated with the second GPU task; and in response to determining that both the first GPU task and the second GPU task can be completed before a deadline associated with the second GPU task, allow the first GPU task to continue execution.

[0010] The other aspects provide: a GPU in hardware embodied in an integrated circuit as described herein; computer-readable code, when the code is run on a computer (and may be encoded on a computer-readable storage medium) suitable for performing the steps of the methods described herein; manufacturing a GPU as described herein at an integrated circuit manufacturing system; a method for manufacturing an integrated circuit definition dataset; configuring a system to manufacture a GPU as described herein when the integrated circuit definition dataset is processed in the integrated circuit manufacturing system; and a computer-readable storage medium having an integrated circuit definition dataset stored thereon, configuring a system to manufacture a GPU as described herein when the integrated circuit definition dataset is processed in the integrated circuit manufacturing system.

[0011] Preferred features may be combined where appropriate, as will be apparent to those skilled in the art, and may be combined with any aspect of the invention. Attached Figure Description

[0012] Embodiments of the present invention will be described by way of example with reference to the following accompanying drawings, in which: Figure 1 This is a schematic diagram of an example GPU in which the methods described in this article can be implemented; Figure 2 This is a flowchart of the first example method for controlling GPU operations; Figure 3 This is a flowchart of the second example method for controlling GPU operations; Figure 4 This is a schematic diagram showing the timeline of periodically displayed refresh points; Figure 5 This is a flowchart of the third example method for controlling GPU operations; Figure 6 This is a schematic diagram of an exemplary integrated circuit manufacturing system.

[0013] Common reference figures are used throughout the figures to indicate similar features. Detailed Implementation

[0014] Embodiments of the invention are described below by way of example only. These examples represent the best mode currently known to the applicant for carrying out the invention, although they are not the only ways in which this can be achieved. The description illustrates the function of the examples and the order of steps used to construct and operate the examples. However, the same or equivalent functions and order can be accomplished by different examples.

[0015] This paper describes a method for controlling the operation of a GPU. The method uses stored statistics related to the time spent executing GPU tasks (e.g., rendering or compute tasks) to determine an estimated time to complete each of a plurality of tasks, and then compares the estimated time to the deadlines of one or more tasks. The GPU operation is then modified based on whether the task deadlines are met. As described below, modifications to the GPU operation can affect task scheduling, and more specifically, can affect whether lower-priority tasks are interrupted (via context switching) to execute higher-priority tasks. Alternatively, modifications to the GPU operation can affect the GPU's operating points (e.g., operating voltage and frequency) (e.g., using Dynamic Voltage and Frequency Scaling (DVFS)).

[0016] If the methods described in this paper are used to influence task scheduling within the GPU, the number of context switches performed can be reduced without compromising the user experience, and this improves GPU efficiency. Switching tasks on the GPU (via context switching) is particularly expensive (in terms of efficiency, memory bandwidth, and scheduler performance) because the pipelines are deeper (i.e., they include more stages than the pipelines within the CPU) and there are large caches storing large amounts of data that must be flushed. In such an implementation, two tasks are considered—the currently executing task and a new, runnable, higher-priority task—and thus two estimates are generated and compared to the deadline of the higher-priority task.

[0017] By using the methods described herein to control the GPU's operation point, the target performance of the GPU can be met while optimizing power consumption (and heat generation). For example, the operation point can be set to have lower power consumption unless increased operation speed (i.e., increased clock speed) is required to schedule tasks to meet their deadlines. In such an implementation, all tasks the GPU is executing within a time window are considered, where the time window can cover all currently available tasks in the queue. Alternatively, the time window can be defined in different ways, for example, the window can run until (i.e., terminate) the next deadline on a timeline (e.g., an ordered list) of deadlines (e.g., the next display refresh or the next refresh if the next display refresh is very close in time). In various examples, when there are multiple different workloads (where the workloads can be tasks, subtasks, or groups of tasks) in the GPU queue for different deadlines (where these deadlines can be display refreshes) and the time window expands to cover all currently available workloads in the queue, the operation point can be controlled so that each task can meet its respective deadline.

[0018] Figure 1This is a schematic diagram of an example GPU 100 in which the methods described herein can be implemented. GPU 100 includes an embedded microprocessor 102 running software or firmware that implements the methods described herein. This software / firmware may be stored in external memory (i.e., outside of GPU 100, accessed via memory management unit 104) or in core memory 103 within the GPU. Statistics used in the methods described herein may be stored within GPU 100 (e.g., in core memory 103), or may be stored outside the GPU and accessed via memory management unit (MMU) 104 within the GPU (which may be referred to as the “GPU MMU” to distinguish it from external MMUs (e.g., CPU MMU and / or system MMU). GPU 100 also includes a GPU core 108, which includes a data master device 108 for performing GPU tasks, a shader cluster 110, a texture pipeline 112, and a data post-processing module 114.

[0019] It should be understood that other GPUs may not include... Figure 1 All functional elements shown (i.e., can be omitted) Figure 1 (one or more functional elements shown), and in some embodiments, may include Figure 1 Additional functional components not shown (e.g., the interface to the power management IC).

[0020] Figure 2 It controls the GPU (e.g.) Figure 1 The flowchart illustrates an example method of operating a GPU (as shown), which can be implemented by software / firmware running within a microprocessor 102 of GPU 100. The method includes determining an estimate for completing each of one or more GPU tasks (box 202), or, in various examples, determining an estimate for completing each of two or more GPU tasks, where at least one task is currently running. The estimates determined (in box 202) can be time (e.g., X milliseconds) or GPU cycles (e.g., Y cycles). GPU tasks can be rendering tasks, computation tasks, or other types of tasks performed on the GPU, and in some examples of determining estimates for two or more GPU tasks, the two or more GPU tasks can be of the same type (e.g., two rendering tasks) or can be of different types. After determining the estimates (in box 202), these estimates are compared to one or more deadlines to determine whether the deadlines (in box 204) can be met. Based on the result of this determination (in box 204), the operation of the GPU can be modified, as will be described below with reference to several examples.

[0021] You can refer to this. Figure 3The flowchart in section 302 illustrates another example method for controlling GPU operations, where the scheduling of GPU tasks is determined (in box 202). While the GPU is executing a first GPU task (box 302), a second GPU task becomes runnable (box 304), where the term "runnable" is used to indicate that the task is no longer blocked due to synchronization (i.e., any tasks the second GPU task depends on have completed). Both the first and second GPU tasks have associated priorities, which can be explicitly defined (e.g., specified by the application) or as a result of the task type (e.g., rendering a live wallpaper inherently has a lower priority than a compositor that maintains a fixed frame rate, and rendering updates to a navigation system inherently has a lower priority than a car's digital dashboard), and in various examples, these tasks can be rendering tasks or computation tasks.

[0022] According to the conventional scheduling algorithm, if the second GPU task has a lower priority than the currently executing first GPU task (No in box 306), the first GPU task is allowed to complete before the second GPU task (box 310) (box 308). Furthermore, if the third GPU task becomes runnable before the first GPU task completes, the relative priorities of the first and third GPU tasks are compared (in an operation similar to box 306). Therefore, it is possible that the second GPU task may not be executed after the first GPU task, as the first task may be interrupted to run the third GPU task. Additionally, after the first GPU task completes (in box 308), if the third GPU task has a lower priority than the first GPU task but a higher priority than the second GPU task, the third GPU task may be executed next.

[0023] However, if a second GPU task (box 304) is ready to run during the execution of the first GPU task and has a higher priority than the first GPU task ("Yes" in box 306), a context switch will occur according to the regular scheduling algorithm, switching the execution of the first GPU task to the execution of the second GPU task. Conversely, in Figure 3 In the method shown, the context switch does not occur automatically; instead, it is evaluated based on whether the first GPU task can be completed. This avoids unnecessary context switches, thereby improving GPU efficiency.

[0024] The evaluation involves estimating the time to complete each of the first and second GPU tasks (box 312), and then comparing these estimates to the deadline for completing the second (higher priority) GPU task (box 314). The estimates can be generated based on time (e.g., X milliseconds) or GPU cycles (e.g., Y cycles) (in box 312), and can be generated using statistics on storage for the GPU task or subtask (e.g., based on a storage statistics model for the GPU task).

[0025] like Figure 3 As shown, in various examples, estimates (in box 312) can be determined by identifying the workload characteristics of each of the first and second GPU tasks (box 316). The workload characteristics depend on the type of GPU task involved, and various examples may include one or more of the following: render target size, number of semi-transparent objects, profiles of all shaders, shader length, and number of primitives. Once the workload characteristics of each task have been determined (in box 316), stored statistics for each identified characteristic are accessed (box 318), and these accessed statistics for each task's characteristics are used to generate two estimates, one for each of the first and second GPU tasks (box 320). Because these characteristics are not specific to any particular GPU task, the statistics may even exist before the GPU task is first executed (e.g., they may be generated before the task is queued based on analysis of the GPU task), and these statistics may subsequently be updated after the GPU task is executed (box 322).

[0026] In various examples, workload characteristics can be described based on the workload footprint, where each workload (e.g., each render) has a calculated footprint. If a new workload has the same (or similar) footprint as another workload that has already been executed on the GPU, the estimate for the new task can be set to the same cycle count (i.e., the same number of cycles) as the executed workload.

[0027] If a GPU task is a rendering task, a single rendering task can include many subtasks, each corresponding to a smaller unit of granularity that can be launched on the GPU. For example, a single rendering task can include many rendering commands (e.g., 100 rendering commands), so estimates can be generated by evaluating stored statistics using the characteristics of each individual rendering command.

[0028] These individual commands can be considered as “children” of the parent render target corresponding to the render task. In one example, a single render can be a set of N vertex DM (data master device) workloads and M pixel DM workloads, where in many cases, M = 1. Each of these workloads can correspond to a subtask.

[0029] The generated estimate (from box 312) is compared with the deadline of the higher-priority (second) GPU task (box 314). The deadline can be explicitly defined (e.g., provided to the GPU by platform software, applications, or a user interface) or it can be determined by the microprocessor (box 324). If the second GPU task is a rendering (or other graphics center) task, the deadline can be inferred (in box 324) based on the display's refresh rate, which for a 60 fps display is every 16.66 ms. Figure 4 As shown in the figure. Figure 4 In the diagram, display refresh points are indicated by vertical lines 402 on timeline 404 separated by time intervals f. If a second GPU task becomes runnable at point A, the deadline (used in box 314) can be the next display refresh point (as indicated by arrow 406) such that the deadline will never be greater than f (where f is the time interval between display refresh points, e.g., f = 16.66 ms). However, in some examples, a minimum deadline value d may exist such that if a second GPU task becomes runnable at point B, where the time b before the next display refresh point is less than a threshold (b < d), the deadline is set to the subsequent display refresh point (as indicated by arrow 408). In this example, the deadline will never be greater than f+d or less than d.

[0030] In some examples, while the monitor may run at a specific frame rate (e.g., 50fps), the application may run at a lower refresh rate. In such cases, the deadline for rendering the application can be defined relative to the application's refresh rate rather than the monitor's refresh rate.

[0031] In some examples, deadlines for certain GPU tasks can be set based on the acceptable latency experienced by the user, rather than on the refresh rate. For some applications, a larger latency may be acceptable compared to others (e.g., calendar or clock applications). For non-graphics tasks, the deadline can be provided by the application, for example.

[0032] After determining the two estimates (in box 312), they are compared with a deadline (in box 314) to determine if the two tasks (i.e., the first and second GPU tasks) can be completed before the deadline of the second GPU task. If both tasks can be completed before the deadline ("Yes" in box 314), no context switch occurs, and the first GPU task is allowed to complete before the second GPU task is executed (box 310) (box 308). This eliminates what would otherwise be an unnecessary context switch, which switches from the first task to the second task and then back to the first task after the second task completes. However, if neither task can be completed before the deadline ("No" in box 314), a context switch occurs (interrupting the execution of the first GPU task) and the second GPU task is executed (box 326). Upon completion of the second (higher priority) GPU task (and assuming another higher priority GPU task has not yet become runnable), a second context switch occurs, allowing the first GPU task to complete (box 328).

[0033] Since the determinations are based on estimates (in box 314), these estimates may be inaccurate. In some implementations, such as real-time systems where deadlines cannot be missed (e.g., for automotive digital dashboards), timers can be used to ensure that the execution of a lower-priority first GPU task does not exceed the limits to the point that a second GPU task cannot meet its deadline, while allowing the first GPU task to continue. Figure 3 As shown, if it is determined that both tasks can be executed before the deadline ("Yes" in box 314), a timer can be set in parallel with allowing the first GPU task to continue execution (box 330). If the deadline for the second GPU task is D and the estimate for completing the second task is E, the timer can be set to the time given by D - E, D - (E + C), where C is the time spent performing the context switch from the first task to the second task, or D - (E + C + M), where M is an additional error margin (e.g., in case the estimate for the second GPU task is inaccurate).

[0034] If the first task completes before the timer expires (No in box 332), the second GPU task can be executed after the first GPU task completes. However, if the timer expires before the first task completes (Yes in box 332), a context switch is performed (box 326) so that the second GPU task can complete to meet the deadline before switching back to the first GPU task (box 328), assuming that no higher-priority GPU task becomes runnable during this period that could prevent the completion of the first GPU task. Using timers in this way means that even if a lower-priority GPU task takes longer than predicted (by estimation), it can still be interrupted, and the system is no less efficient than a system using a conventional priority-based scheduler.

[0035] like Figure 3 As shown, when stored statistics are used to generate estimates (in box 312), these estimates can be updated at one or more points in the method based on the actual execution time of the first and / or second GPU tasks or their subtasks (box 322).

[0036] exist Figure 3 In a variation of the method shown, the GPU's operating point (box 334, e.g., using DVFS) can be adjusted to ensure the deadline of the second (higher priority) GPU task is met, rather than using context switching to ensure the deadline is met (e.g., in box 326). By increasing the voltage / frequency, the estimate (from box 312), if defined in terms of GPU cycles, does not change, but rather the length of the GPU cycle (based on time) is reduced, thus reducing the estimate in terms of time.

[0037] Figure 3 The method shown adds flexibility to traditional priority-based scheduling, and this improves GPU efficiency by reducing the number of context switches performed. As mentioned above, context switching on a GPU can be particularly expensive (in terms of time, and therefore efficiency) because the depth of the pipeline and the amount of cache increase the time spent on the store and load operations for performing context switches.

[0038] While the GPU's operation point can change due to the estimation of only one or two GPU tasks being computed (as described above), in other examples, the operation point can change based on the evaluation of all GPU tasks that are queued and / or need to be executed within a specific time window, as can be seen in [reference]. Figure 5 As described.

[0039] like Figure 5As shown, a set of GPU tasks is identified (box 502). This set of GPU tasks can be all queued tasks in the system, all tasks within a defined time window, or a task group that can be defined in another way (e.g., critical rendering that contributes to the pixels the compositor draws on the next frame to be displayed). Estimates for completing each of the identified tasks are then confirmed (box 504), and these estimates can be generated as described above in reference box 312 (e.g., using workload characteristics and stored statistics). Where deadlines are not explicitly defined (e.g., by platform software, application, or user interface), deadlines can be determined by the microprocessor for each identified task (box 506), and can be obtained using methods similar to those described above in reference box 312. Figure 3 and 4 The described method is similar to the method used to determine deadlines (e.g., for the next display refresh event). In various examples, tasks can be grouped based on their deadlines; for example, there could be one group of tasks targeting a deadline D1 and another group targeting a deadline D2, where D2 > D1.

[0040] After determining the estimates (in box 504) and deadlines (in box 506), it is determined whether all deadlines for all identified GPU tasks can be met (box 508). If the current operating point can meet all deadlines ("Yes" in box 508), the GPU clock frequency can be maintained (i.e., kept constant), or in some cases reduced (box 510). However, if the current operating point cannot meet all deadlines ("No" in box 508), the GPU clock frequency can be increased, for example, using DVFS (box 512), so that the deadlines can be met. If the maximum clock frequency is reached, it may not be possible to further increase the frequency to meet all deadlines; however, using the maximum frequency will ensure that as many deadlines as possible are met.

[0041] Although Figure 5 The diagram illustrates changing the clock frequency based on whether a deadline can be met or not (in boxes 510 and 512), but alternatively (or additionally), the operating voltage / frequency can be changed (e.g., in boxes 510 and 512 or equivalent boxes), where the frequency changes as a result of the change in operating voltage. With the voltage / frequency adjusted, the GPU can be included in a power management IC (PMIC). Figure 1 An interface (not shown) may be used, or alternatively, a request may be sent to the CPU that communicates with the GPU, and the CPU may process (and implement) the request (e.g., using a driver running on the CPU).

[0042] Although Figure 3 and Figure 5The methods described in the document are presented separately, and the GPU can implement two (or parts of both) of these methods. The GPU can use these methods to independently control DVFS and scheduling.

[0043] Determination of the estimate (in) Figure 2 Frame 202 Figure 3 box 312 and Figure 5 (In box 504) those estimates may be calculated based on stored statistics, or alternatively, the determination of the estimates may be performed on stored statistics of the task and subtasks on the CPU communicating with the GPU.

[0044] The methods described above can be used in systems with at least one process that has real-time or other time-critical requirements. Examples include automotive digital dashboards and synthesizers that run output at a fixed frame rate (e.g., 60 fps). The system can also run less time-sensitive processes such as navigation system updates and real-time wallpaper updates.

[0045] GPUs that implement the above methods can be used in many different devices. For example, in computing devices used in vehicles, in handheld computing devices (such as tablets or smartphones), in other consumer devices (such as digital TVs or set-top boxes), or in any other computing device (such as laptops, desktop computers, smartwatches, etc.).

[0046] The terms "processor" and "computer" are used herein to refer to any device or part thereof with processing capabilities, enabling it to execute instructions. The term "processor" may include, for example, a central processing unit (CPU), a graphics processing unit (GPU or VPU), a physical processing unit (PPU), a radio processing unit (RPU), a digital signal processor (DSP), a general-purpose processor (e.g., a general-purpose GPU), a microprocessor, any processing unit designed to accelerate tasks outside the CPU, and the like. Those skilled in the art will recognize that such processing capabilities are incorporated into many different devices, and therefore the term "computer" includes set-top boxes, media players, digital radio devices, PCs, servers, mobile phones, personal digital assistants, and many other devices.

[0047] Those skilled in the art will recognize that storage devices for storing program instructions can be distributed across a network. For example, a remote computer can store examples of processes described as software. A local or terminal computer can access the remote computer and download part or all of the software to run the program. Alternatively, a local computer can download fragments of software on demand or execute some software instructions at a local terminal and some instructions at a remote computer (or computer network). Those skilled in the art will also recognize that, by utilizing conventional techniques known to those skilled in the art, all or part of the software instructions can be implemented by special-purpose circuitry (e.g., DSPs, programmable logic arrays, etc.).

[0048] The methods described herein can be executed by a computer configured with software stored in a machine-readable form on a tangible storage medium, for example, in the form of a computer program that includes computer-readable program code comprising components for configuring the computer to perform the methods, or in the form of a computer program that includes computer program code modules suitable for performing all steps of any of the methods described herein when the program is run on a computer, and wherein the computer program may be embodied on a computer-readable storage medium.

[0049] Examples of tangible (or non-transitory) storage media include disks, thumb drives, memory cards, etc., and do not include propagated signals. The software may be adapted to execute on parallel or serial processors, such that method steps can be executed in any suitable order or simultaneously.

[0050] The hardware components described herein may be generated from a non-transitory computer-readable storage medium having computer-readable program code encoded thereon.

[0051] It is also intended to include software that “describes” or defines the configuration of hardware implementing the modules, functions, components, or logic described above, such as HDL (Hardware Description Language) software, used for designing integrated circuits or configuring programmable chips to achieve desired functionality. That is, a computer-readable storage medium may be provided having computer-readable program code encoded thereon for generating processing units configured to perform any of the methods described herein or for generating processing units including any of the means described herein. In other words, a computer system may be configured to generate a representation of digital circuits from data defining rules for combining those circuit elements and definitions of the circuit elements, wherein a non-transitory computer-readable storage medium may have processor-executable instructions stored thereon that, when executed at such a computer system, cause the computer system to generate processing units as described herein. For example, a non-transitory computer-readable storage medium may have computer-readable instructions stored thereon that, when executed at a computer system used to generate representations of integrated circuits, cause the computer system to generate a processor representation of a receiver as described in the examples herein or to generate a processor representation configured to perform the methods described in the examples herein. The processor representation may be the processor itself or a representation of a processor (e.g., a mask) that can be used to generate the processor.

[0052] Now refer to Figure 6 This describes an example of processing integrated circuit definition datasets at an integrated circuit manufacturing system in order to configure the system to manufacture GPUs.

[0053] Figure 6 An example of an integrated circuit (IC) manufacturing system 602 is shown, which includes a layout processing system 604 and an integrated circuit generation system 606. The IC manufacturing system 602 is configured to receive an IC definition dataset (e.g., a GPU defined as described in any example herein), process the IC definition dataset, and generate an IC based on the IC definition dataset (e.g., which embodies a GPU as described in any example herein).

[0054] The IC definition dataset is processed by the IC manufacturing system 602 to manufacture integrated circuits embodying GPUs as described in any of the examples herein. More specifically, the layout processing system 604 is configured to receive and process the IC definition dataset to determine a circuit layout. Methods for determining a circuit layout based on an IC definition dataset are known in the art and may, for example, involve synthesizing RTL code to determine, for example, a gate-level representation of the circuit to be generated in terms of logic components (e.g., NAND, NOR, AND, OR, multiplexing, and triggering components). The circuit layout can be determined by determining the location information of the logic components based on the gate-level representation of the circuit. This can be done automatically or with the aid of user intervention to optimize the circuit layout. When the layout processing system 604 determines the circuit layout, it can output the circuit layout definition to the IC generation system 606. The IC generation system 606 generates an IC based on the circuit layout definition, as known in the art. For example, the IC generation system 606 may implement a semiconductor device manufacturing process to generate an IC, which may involve a multi-step sequence of photolithography and chemical processing steps during which electronic circuitry is typically created on a wafer made of semiconductor material. The circuit layout definition can be in the form of a mask, which can be used during photolithography to generate an IC based on the circuit definition. Alternatively, the circuit layout definition provided to the IC generation system 606 can be in the form of computer-readable code, which the IC generation system 606 can use to form an appropriate mask for use during IC generation. The different processes performed by the IC manufacturing system 602 can all be implemented in one location, for example, by one party.

[0055] Optionally, the IC manufacturing system 602 can be a distributed system, allowing some processes to be performed at different locations and by different entities. For example, some of the steps are: (i) synthesizing RTL code representing an IC definition dataset to form a gate-level representation of the circuit to be generated; (ii) generating a circuit layout based on the gate-level representation; (iii) forming a mask according to the circuit layout; and (iv) manufacturing the integrated circuit using the mask, which can be implemented at different locations and / or by different parties.

[0056] In other examples, processing of an integrated circuit definition dataset at an integrated circuit manufacturing system can configure the system to manufacture GPUs without processing the IC definition dataset to determine circuit layout. For example, an IC definition dataset can define the configuration of a reconfigurable processor (e.g., an FPGA), and processing of that dataset can configure the IC manufacturing system to produce a reconfigurable processor with that defined configuration (e.g., by loading the configuration data into the FPGA).

[0057] In some examples, an integrated circuit definition dataset may include software running on hardware defined by the dataset, or software combined with hardware defined by the dataset. Figure 6In the example shown, the IC generation system can also be configured by the integrated circuit definition dataset to load firmware onto the integrated circuit according to the program code defined at the integrated circuit definition dataset during the manufacturing of the integrated circuit, or otherwise provide program code to the integrated circuit for use by the integrated circuit.

[0058] The memory storing machine-executable data used in implementing the disclosed aspects can be a non-temporary medium. A non-temporary medium can be volatile or non-volatile. Examples of volatile non-temporary media include semiconductor-based memories such as SRAM or DRAM. Examples of techniques that can be used to implement non-volatile memories include optical and magnetic memory technologies, flash memory, phase-change memory, and resistive RAM.

[0059] The specific reference to "logic" refers to a structure that performs one or more functions. Examples of logic include circuits arranged to perform those functions. For example, such circuits may include transistors and / or other hardware elements available during the manufacturing process. As an example, such transistors and / or other elements may be used to form circuits or structures that implement and / or include memory (e.g., registers, flip-flops, or latches), logic units (e.g., Boolean operations), mathematical units (e.g., adders, multipliers, or shifters), and interconnections. Such elements may be provided as custom circuits or standard cell libraries, macros, or at other levels of abstraction.

[0060] Such elements can be interconnected in a specific arrangement. Logic may include circuitry with fixed functions, and the circuitry may be programmed to perform one or more functions; such programming may be provided from firmware or software updates or control mechanisms. Logic identified as performing a function may also include logic that implements constituent functions or sub-processes. In the example, the hardware logic has circuitry that implements fixed function operations or multiple operations, state machines, or processes.

[0061] Any range or device values ​​given in this document may be extended or changed without losing the desired effect, as will be apparent to a person skilled in the art.

[0062] It will be understood that the benefits and advantages described above may apply to one embodiment or several embodiments. The embodiments are not limited to those that solve any or all of the stated problems or those that have any or all of the stated benefits and advantages.

[0063] Any reference to “one” means one or more of those items. The term “comprising” is used herein to mean including the identified method blocks or elements, but such blocks or elements do not include an exclusive list, and the apparatus may include additional blocks or elements, and the method may include additional operations or elements. Furthermore, blocks, elements, and operations are not implicitly closed on their own.

[0064] The steps of the methods described herein can be performed in any suitable order or simultaneously, as appropriate. The arrows between the boxes in the accompanying drawings indicate an example order of method steps, but are not intended to exclude other orders or the parallel execution of multiple steps. Furthermore, individual blocks can be removed from any method without departing from the spirit and scope of the subject matter described herein. Aspects of any example described above can be combined with aspects of any of the other examples described to form further examples without losing the desired effect. Where elements in the accompanying drawings are shown connected by arrows, it will be appreciated that these arrows illustrate only one example flow of communication (including data and control messages) between elements. Flow between elements can occur in either direction or in both directions.

[0065] It will be understood that the above description of preferred embodiments is given by way of example only, and various modifications can be made by those skilled in the art. Although various embodiments have been described above with a certain level of detail or with reference to one or more individual embodiments, those skilled in the art can make many changes to the disclosed embodiments without departing from the spirit or scope of the invention.

[0066] This application provides the following aspects: 1) A method for scheduling tasks within a GPU, the method comprising: While executing the first GPU task (302), in response to the second GPU task being ready to run (304), it is determined which of the first GPU task and the second GPU task has a higher priority (306); and In response to determining that the second GPU task has a higher priority than the currently executing first GPU task; Estimate the completion time of each of the first GPU task and the second GPU task (312); The estimated completion time is used to determine whether the first GPU task and the second GPU task can be completed before the deadline associated with the second GPU task (314); and In response to determining that both the first GPU task and the second GPU task are capable of completing before the deadline associated with the second GPU task, the first GPU task is allowed to continue execution (308, 330) and a timer (330) is set; and In response to the timer timing out (322) before the execution of the first GPU task is completed, the execution of the first GPU task is interrupted and the second GPU task is executed (326).

[0067] 2) The method described in 1) further includes: In response to determining that both the first GPU task and the second GPU task cannot be completed before the deadline associated with the second GPU task, the execution of the first GPU task is interrupted and the second GPU task is executed (326).

[0068] 3) The method according to 1) or 2), wherein allowing the first GPU task to continue execution includes: Allow the execution of the first task to be completed (308).

[0069] 4) The method according to 1) further includes: In response to determining that the first GPU task and the second GPU task cannot both be completed before the deadline associated with the second GPU task, the operating frequency of the GPU is increased (334) and the first GPU task is allowed to continue execution (308) before the second GPU task is executed (310).

[0070] 5) The method according to any one of 1)-4), wherein estimating the completion time of each of the first GPU task and the second GPU task includes, for each GPU task: Identify one or more workload characteristics of the GPU task (316); Access the stored statistics for each identified workload characteristic (318); and The estimated completion time (320) of the GPU task is generated using the stored statistics of the identified workload characteristics.

[0071] 6) The method according to any one of 1)-5) further includes: Determine the deadline associated with the second GPU task (324).

[0072] 7) According to the method in 6), wherein the deadline associated with the second GPU task is determined based on the display refresh rate.

[0073] 8) The method according to any one of 1)-7) further includes: Update the stored statistics associated with the first GPU task and / or the second GPU task (322).

[0074] 9) The method according to any one of 1)-8), wherein the first GPU task and the second GPU task are graphics tasks.

[0075] 10) According to the method in 9), wherein the first GPU task and the second GPU task are rendering tasks.

[0076] 11) The method according to any one of 1)-10), wherein the GPU includes a microcontroller.

[0077] 12) A GPU (100) including a microcontroller (102), wherein The microcontroller is configured to: While executing the first GPU task (302), in response to the second GPU task being ready to run (304), it is determined which of the first GPU task and the second GPU task has a higher priority (306); and In response to determining that the second GPU task has a higher priority than the currently executing first GPU task; Estimate the completion time of each of the first GPU task and the second GPU task (312); The estimated completion time is used to determine whether the first GPU task and the second GPU task can be completed before the deadline associated with the second GPU task (314); and In response to determining that both the first GPU task and the second GPU task are capable of completing before the deadline associated with the second GPU task, the first GPU task is allowed to continue execution (308, 330) and a timer (330) is set; and In response to the timer timing out (332) before the execution of the first GPU task is completed, the execution of the first GPU task is interrupted and the second GPU task is executed (326).

[0078] 13) The GPU according to 12) further includes a memory (103) arranged to store device-executable instructions, which, when executed, cause the microcontroller to: determine, in response to a second GPU task being ready to run (304), which of the first GPU task and the second GPU task has a higher priority (306); in response to determining that the second GPU task has a higher priority than the currently executing first GPU task; estimate the completion time of each of the first GPU task and the second GPU task (312); use the estimated completion time to determine whether the first GPU task and the second GPU task can be completed before the deadline associated with the second GPU task (314); and in response to determining that both the first GPU task and the second GPU task can be completed before the deadline associated with the second GPU task, allow the first GPU task to continue execution (308, 330).

[0079] 14) The GPU according to 12) or 13), wherein the microcontroller is further configured to: interrupt the execution of the first GPU task and execute the second GPU task in response to determining that the first GPU task and the second GPU task cannot both be completed before the deadline associated with the second GPU task (326).

[0080] 15) The GPU according to any one of 12)-14), wherein the microcontroller is configured to allow the first GPU task to continue execution by allowing the first task to complete (308).

[0081] 16) The GPU according to any one of 12)-15), wherein the microcontroller is configured to estimate the completion time of each of the first GPU task and the second GPU task by the following operations for each GPU task: Identify one or more workload characteristics of the GPU task (316); Access the stored statistics for each identified workload characteristic (318); and The estimated completion time (320) of the GPU task is generated using the stored statistics of the identified workload characteristics.

[0082] 17) The GPU according to any one of 12)-16), wherein the microcontroller is further configured to determine a deadline (324) associated with the second GPU task.

[0083] 18) The GPU according to 17), wherein the deadline associated with the second GPU task is determined based on the display refresh rate.

[0084] 19) The GPU according to any one of 12)-18), wherein the microcontroller is further configured to update stored statistics associated with the first GPU task and / or the second GPU task (322).

[0085] 20) The GPU according to any one of 12)-19), wherein the first GPU task and the second GPU task are graphics tasks.

[0086] 21) The GPU according to 20), wherein the first GPU task and the second GPU task are rendering tasks.

[0087] 22) The GPU according to any one of 12)-21), wherein the GPU is embodied in hardware on an integrated circuit.

[0088] 23) A computer-readable code, when run on a computer, adapted to perform the steps of the method according to any one of 1)-11).

[0089] 24) A computer-readable storage medium having computer-readable code encoded thereon according to 23).

[0090] 25) A method for manufacturing a GPU according to any one of 12)-21) at an integrated circuit manufacturing system.

[0091] 26) An integrated circuit definition dataset, wherein when the dataset is processed in an integrated circuit manufacturing system, the system is configured to manufacture a GPU according to any one of 12)-21).

[0092] 27) A computer-readable storage medium having an integrated circuit definition dataset stored thereon, wherein the integrated circuit definition dataset is processed in an integrated circuit manufacturing system, the system being configured to manufacture a GPU according to any one of 12)-21).

Claims

1. A method for scheduling tasks within a GPU, the method comprising: While executing the first GPU task, in response to the second GPU task being ready to run, it is determined which of the first GPU task and the second GPU task has a higher priority. and In response to determining that the second GPU task has a higher priority than the currently executing first GPU task: - Estimate the completion time of each of the first GPU task and the second GPU task, wherein the second GPU task is a rendering task on the display; - Determine the deadline associated with the second GPU task using the following steps: -- Determine the first upcoming refresh point based on the refresh rate of the display; -- Determine whether the second GPU task is ready to run during the threshold period preceding the first upcoming refresh point; -- In response to the second GPU task being ready before the threshold period, the deadline associated with the second GPU task is set to the first upcoming refresh point; as well as -- In response to the second GPU task being ready during the threshold period, the deadline associated with the second GPU task is set to the second upcoming refresh point; - Use the estimated completion time to determine whether both the first GPU task and the second GPU task can be completed before the deadline associated with the second GPU task; as well as - In response to determining that both the first GPU task and the second GPU task are capable of completing before the deadline associated with the second GPU task, the first GPU task is allowed to continue execution; and In response to the determination that neither the first GPU task nor the second GPU task can be completed before the deadline, the execution of the first GPU task is interrupted and the second GPU task is executed.

2. The method according to claim 1, further comprising: In response to determining that neither the first GPU task nor the second GPU task can be completed before the deadline associated with the second GPU task, the operating frequency of the GPU is increased.

3. The method according to claim 1, wherein, The estimated completion time for each of the first GPU task and the second GPU task includes, for each GPU task: Identify one or more workload characteristics of the GPU task, wherein the workload characteristic is at least one of the following: render target size, number of semi-transparent objects, shader profile, shader length, or number of primitives; Access stored statistics for each identified workload characteristic; and The estimated completion time of the GPU task is generated using stored statistics based on the identified workload characteristics.

4. The method according to claim 1, further comprising: Update the stored statistics associated with the first GPU task and / or the second GPU task.

5. The method according to claim 1, wherein, The first GPU task and the second GPU task are rendering tasks.

6. The method according to claim 1, wherein, The GPU includes a microcontroller.

7. A GPU including a microcontroller, wherein the microcontroller is configured to: While executing the first GPU task, in response to the second GPU task being ready to run, it is determined which of the first GPU task and the second GPU task has a higher priority. and In response to determining that the second GPU task has a higher priority than the currently executing first GPU task: - Estimate the completion time of each of the first GPU task and the second GPU task, wherein the second GPU task is a rendering task on the display; - Determine the deadline associated with the second GPU task using the following steps: -- Determine the first upcoming refresh point based on the refresh rate of the display; -- Determine whether the second GPU task is ready to run during the threshold period preceding the first upcoming refresh point; -- In response to the second GPU task being ready before the threshold period, the deadline associated with the second GPU task is set to the first upcoming refresh point; as well as -- In response to the second GPU task being ready during the threshold period, the deadline associated with the second GPU task is set to the second upcoming refresh point; - Use the estimated completion time to determine whether both the first GPU task and the second GPU task can be completed before the deadline associated with the second GPU task; as well as - In response to determining that both the first GPU task and the second GPU task are capable of completing before the deadline associated with the second GPU task, the first GPU task is allowed to continue execution; and In response to determining that both the first GPU task and the second GPU task cannot be completed before the deadline, the execution of the first GPU task is interrupted and the second GPU task is executed.

8. The GPU according to claim 7, wherein, The microcontroller is configured to estimate the completion time of each of the first GPU task and the second GPU task by performing the following operations for each GPU task: Identify one or more workload characteristics of the GPU task, wherein the workload characteristic is at least one of the following: render target size, number of semi-transparent objects, shader profile, shader length, and number of primitives; Access stored statistics for each identified workload characteristic; and The estimated completion time of the GPU task is generated using stored statistics based on the identified workload characteristics.

9. The GPU of claim 7, wherein, The microcontroller is also configured to update stored statistics associated with the first GPU task and / or the second GPU task.

10. The GPU of claim 7, wherein, The first GPU task and the second GPU task are rendering tasks.

11. The GPU of claim 7, wherein, The GPU is embodied in hardware on an integrated circuit.

12. A computer-readable storage medium having computer-readable code encoded thereon, which, when run on a computer, is adapted to perform the method steps according to any one of claims 1-6.

13. A method for manufacturing a GPU according to any one of claims 7-11 at an integrated circuit manufacturing system.

14. An integrated circuit definition dataset, wherein when the dataset is processed in an integrated circuit manufacturing system, the system is configured to manufacture a GPU according to any one of claims 7-11.

15. A computer-readable storage medium having an integrated circuit definition dataset stored thereon, wherein the integrated circuit definition dataset is processed in an integrated circuit manufacturing system, the system being configured to manufacture a GPU according to any one of claims 7-11.

Images