Time slicing

Abstract

And time slicing. A method of scheduling a plurality of active GPU drivers in a GPU is described. The method includes: for one or more active GPU drivers of the plurality of active GPU drivers, allocating a portion of a scheduling period to the active GPU drivers; and selecting the active GPU driver for execution according to a priority-based scheduling algorithm. In some embodiments, the active GPU driver is prioritized in response to execution of the active GPU driver within its allocated portion, the active GPU driver is prioritized in response to completion of its workload within its allocated portion, and the active GPU driver is prioritized in response to execution of the active GPU driver throughout its allocated portion. At the beginning of each scheduling period, the priority of each active GPU driver is reset to its initial priority.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to UK patent application 2311307.9 filed on July 24, 2023, which is incorporated herein by reference in its entirety. Technical Field

[0003] The present invention relates to scheduling of workloads in a graphics processing unit (GPU). Background Art

[0004] Within a GPU, there are many different types of workloads to execute, and the scheduler may use the workload type (e.g., compute, 2D, 3D, etc.) or the identity of the hardware unit that feeds specific data into a particular GPU pipeline (which may be referred to as a "master unit" and may be a proxy for the workload type) in the scheduling algorithm to determine which workload to schedule at any time. In a virtualized system, there will be many different GPU drivers, each corresponding to a different virtual operating system (OS), and at any point in time, there may be workloads associated with several different GPU drivers waiting to execute within the GPU. Different priorities may be assigned to different GPU drivers, and these priorities may be used in the scheduling algorithm to determine which workload to schedule at any time.

[0005] The embodiments described below are provided by way of example only and are not intended to limit implementations that address any or all of the shortcomings of known scheduling algorithms. Summary of the invention

[0006] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

[0007] A method for scheduling multiple active GPU drivers in a GPU is described. The method includes: for one or more active GPU drivers among the multiple active GPU drivers, allocating a portion of a scheduling period to the active GPU driver; and selecting the active GPU driver to execute according to a priority-based scheduling algorithm. In response to the active GPU driver executing within its allocated portion, increasing the priority of the active GPU driver, in response to the active GPU driver completing its workload within its allocated portion, resetting the priority of the active GPU driver, and in response to the active GPU driver executing within its entire allocated portion, decreasing the priority of the active GPU driver. At the beginning of each scheduling period, the priority of each active GPU driver is reset to its initial priority.

[0008] A first aspect provides a method for scheduling multiple active GPU drivers in a GPU, each of the active GPU drivers having an initial priority, and the method includes: for one or more active GPU drivers among the multiple active GPU drivers, allocating a portion of a scheduling period to the active GPU driver; selecting the active GPU driver for execution according to a priority-based scheduling algorithm; in response to the active GPU driver executing within its allocated portion, increasing the priority of the active GPU driver; in response to the active GPU driver completing its workload within its allocated portion, resetting the priority of the active GPU driver; in response to the active GPU driver executing within its entire allocated portion, decreasing the priority of the active GPU driver; and resetting the priority of each active GPU driver to its initial priority at the beginning of each scheduling period.

[0009] Increasing the priority of the active GPU driver may include increasing the priority of the active GPU driver by a first predefined amount, and wherein decreasing the priority of the active GPU driver includes decreasing the priority of the active GPU driver by a second predefined amount.

[0010] Each priority value may be represented using a two's complement number, and increasing the priority of the active GPU driver by a first predefined amount may include setting a first reserved bit in the value indicating the priority of the active GPU driver, and wherein decreasing the priority of the active GPU driver by a second predefined amount includes setting a second reserved bit in the value indicating the priority of the active GPU driver.

[0011] Resetting the priority of the active GPU driver may include clearing a first reserved bit and a second reserved bit in a value indicating the priority of the active GPU driver.

[0012] The method may further include, for one or more active GPU drivers of the plurality of active GPU drivers, changing the portion of the scheduling period allocated to the active GPU driver in a next scheduling period.

[0013] The portion of the schedule period allocated to the active GPU driver within the next schedule period may be changed in response to a first detected system condition.

[0014] The first detected system condition may be a reduction in a frame rate of the active GPU driver.

[0015] The method may also include defining an initial length of the scheduling period (106).

[0016] The method may further include changing the length of the next scheduled period.

[0017] The length of the next scheduled period may be changed in response to a second detected system condition.

[0018] The second detected system condition may relate to a number of detected context switch events.

[0019] The portion of the scheduled period may be allocated to the active GPU driver according to user-defined parameters.

[0020] The method may further include: in response to the active GPU driver starting execution: calculating the remainder of the allocated portion using slice usage data, the slice usage data indicating the cumulative execution time of the active GPU driver within the scheduling period; if the remainder of the allocated portion is positive, determining whether the active GPU driver is executing within its allocated portion; and in response to determining that the active GPU driver is executing within its allocated portion, starting a timer for the active GPU driver, and in response to the active GPU driver completing its workload within its allocated portion, stopping the timer for the active GPU driver, and wherein the method further includes resetting the slice usage data for each active GPU driver at the beginning of each scheduling period.

[0021] The method may also include selectively resetting or lowering the priority of each other active GPU driver in response to the active GPU driver completing the workload within its assigned portion; and lowering the priority of the active GPU driver in response to the active GPU driver completing a context switch of the workload.

[0022] The method may further include: in response to the active GPU driver starting execution: calculating the remainder of the allocated portion using slice usage data, the slice usage data indicating the cumulative execution time of the active GPU driver within the scheduling period; if the remainder of the allocated portion is positive, determining whether the active GPU driver is executing within its allocated portion; and in response to determining that the active GPU driver is executing within its allocated portion, starting a timer for the active GPU driver, and in response to the active GPU driver completing a workload within its allocated portion, determining whether the completed workload is the last workload of the active GPU driver; and in response to determining that the completed workload is the last workload of the active GPU driver, stopping the timer of the active GPU driver, and wherein the method also includes resetting the slice usage data of each active GPU driver at the beginning of each scheduling period.

[0023] The method may also include selectively resetting or lowering the priority of each other active GPU driver in response to the active GPU driver completing the last workload within its assigned portion; and lowering the priority of the active GPU driver in response to the active GPU driver completing a context switch for the last workload (715).

[0024] The method may also include determining that the active GPU driver has executed within its entire allocated portion when a time elapsed since a timer for the active GPU driver was started is equal to a remaining portion of a calculation for the allocated portion.

[0025] Other aspects provide a GPU configured to perform the method of the first aspect or any other method described herein, the GPU comprising a microprocessor configured to perform the method of the first aspect or any other method described herein.

[0026] A GPU (which may be a GPU with an integrated workload scheduler) may be included in hardware on an integrated circuit. A method of manufacturing a GPU at an integrated circuit manufacturing system may be provided. An integrated circuit definition data set may be provided, which, when processed in the integrated circuit manufacturing system, configures the system to manufacture a GPU. A non-transitory computer-readable storage medium may be provided, which has a computer-readable description of a GPU stored thereon, which, when processed in the integrated circuit manufacturing system, causes the integrated circuit manufacturing system to manufacture an integrated circuit including a GPU.

[0027] An integrated circuit manufacturing system may be provided, the integrated circuit manufacturing system comprising: a non-transitory computer-readable storage medium having a computer-readable description of a GPU stored thereon; a layout processing system configured to process the computer-readable description so as to generate a circuit layout description of an integrated circuit including the GPU; and an integrated circuit generation system configured to manufacture the GPU based on the circuit layout description.

[0028] A method for manufacturing a GPU configured to perform the method of the first aspect or any other method described herein using an integrated circuit manufacturing system may be provided, the method comprising: processing a computer-readable description of the GPU using a layout processing system to generate a circuit layout description of an integrated circuit including the GPU; and manufacturing the GPU according to the circuit layout description using the integrated circuit generation system.

[0029] A computer program code for performing any of the methods described herein may be provided. A non-transitory computer readable storage medium may be provided having computer readable instructions stored thereon, which when executed at a computer system causes the computer system to perform any of the methods described herein.

[0030] As will be apparent to the skilled person, the above features may be combined as appropriate and may be combined with any aspect of the examples described herein. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] Examples will now be described in detail with reference to the accompanying drawings, in which:

[0032] Figure 1 A flow chart showing a first exemplary scheduling method;

[0033] Figure 2 It shows the use of Figure 1 A schematic diagram of an exemplary scenario of the method;

[0034] Figure 3 yes Figure 2 A priority diagram of an exemplary scenario shown in ;

[0035] Figure 4 Shown in more detail Figure 1 A first exemplary implementation of the execution phase 104 of the method;

[0036] Figure 5 Shown in more detail Figure 1 A second exemplary embodiment of the execution phase 104 of the method;

[0037] Figure 6is a schematic diagram illustrating the potential effects of context switch latency;

[0038] Figure 7 Shown in more detail Figure 1 A third exemplary embodiment of the execution phase 104 of the method;

[0039] Figure 8 A computer system is shown in which a graphics processing system is implemented; and

[0040] Fig. 9 An integrated circuit manufacturing system for producing an integrated circuit including a graphics processing system is shown.

[0041] The accompanying drawings show various examples. The skilled person will appreciate that the element boundaries (e.g., boxes, groups of boxes, or other shapes) shown in the accompanying drawings represent an example of boundaries. In some examples, it may be the case that an element can be designed as multiple elements, or multiple elements can be designed as one element. Where appropriate, common reference numerals are used throughout the accompanying drawings to indicate similar features. DETAILED DESCRIPTION

[0042] The following description is presented by way of example to enable those skilled in the art to make and use the invention. The present invention is not limited to the embodiments described herein, and various modifications to the disclosed embodiments will be apparent to those skilled in the art.

[0043] Embodiments will now be described by way of example only.

[0044] As described above, in a virtualized system, there will be many different GPU drivers, each corresponding to a different virtual operating system, and at any point in time, there may be workloads associated with several different GPU drivers waiting to be executed within the GPU. Different priorities can be assigned to different GPU drivers (e.g., assigned by a user), and these priorities can be used in a scheduling algorithm (e.g., by scheduling a higher priority driver relative to a lower priority driver) to determine which workload to schedule at any time. A scheduling algorithm that uses priority to determine the workload to be scheduled can be referred to as a priority-based scheduling algorithm. Such an algorithm may use only priority, or may use additional parameters in addition to priority to determine the workload to be scheduled. However, problems may arise when the workload of a high priority driver is scheduled in such a way that a lower priority driver lacks execution time to the extent that performance is affected (e.g., performance may be visually affected by making a graphical user interface (GUI) application appear frozen or by significantly reducing the frame rate, such as to less than 60fps). For example, if a high priority driver with a computational workload (e.g., AI or data tasks) is scheduled, it may starve a lower priority driver performing a graphics workload (e.g., geometry processing, fragment processing, or 2D graphics workload) indefinitely, i.e., the graphics workload may be blocked from executing until the computational workload is completed, which may take many seconds. Blocking the graphics workload may cause the frame rate of the GUI application to temporarily decrease to zero, so the GUI application will appear to be frozen. Such problems are not limited to computational tasks starving graphics tasks, and in other examples, a higher priority driver with a first graphics workload may starve a lower priority driver with a second graphics workload, causing the frame rate of the second graphics workload to decrease (e.g., to a point visible to the user, such as to below 60fps), or a higher priority driver with a first computational workload may starve a lower priority driver with a second computational workload.

[0045] To address this issue, different types of workloads (i.e., workloads from different master units within the GPU) can be allowed to overlap (i.e., run in parallel); however, because the execution of overlapping workloads may rely on the use of shared resources (e.g., shared registers, temporary registers, etc.), the workloads may still end up with a lack of execution time.

[0046] A scheduling method is described herein that provides a guaranteed, configurable, minimum execution time for an active driver, provided that the active driver has enough workload to execute and the workload is executable when the active driver can be scheduled to execute. An active driver is a driver that is powered on and establishes a connection with a scheduler. Depending on the configuration, a guaranteed minimum execution time can be provided for each active driver or only for some active drivers (i.e., for an appropriate subset of active drivers). The guaranteed minimum execution time can be different for different drivers and can change over time, such as making the first driver initially have a greater guaranteed minimum execution time than the second driver, and then the second driver has a greater guaranteed minimum execution time than the first driver. The minimum execution time of the driver can be configured by the user, or can be defined by the system (e.g., by the scheduler), and this can be different between drivers (e.g., some drivers have a user-defined minimum execution time and other drivers have a system-defined minimum execution time). In the case where the minimum execution time is user-defined, this can be expressed in absolute time (e.g., expressed in milliseconds) or a proportion of the available execution time (e.g., expressed in percentage or fraction). Where the minimum execution time is system defined, it may be dynamic (i.e., it is defined in real time and may change over time in response to detected system conditions). Where the minimum execution time is user defined, it may be periodically updated by the user and therefore may not remain constant.

[0047] As described in more detail below, the scheduling method described herein uses two types of timers, which may be referred to as period timers and slice timers. The method uses a single period timer and one or more slice timers. The method relies on dividing the GPU execution time into periods, as defined by the period timer. When the period timer expires, one period ends and the next period begins. The duration of the period timer may be a user-configurable parameter (e.g., stored in a data structure) and / or may vary over time (i.e., it may be a dynamically defined parameter). The duration of the period timer (and therefore the length of the period) may be, for example, 100ms or 1000ms. Within each period, a time slice is assigned to one or more active drivers, and in some examples to all active drivers. These assigned time slices correspond to the guaranteed minimum execution time of the corresponding driver within a specific period, and as described above, the length of the time slice may be user-configured or dynamically defined by the system. As described above, the assigned time slice may be defined in absolute terms or as a ratio of the period length. By using proportional allocations (e.g., 5% of a period) rather than fixed allocations (e.g., 10ms), the allocated time slices are automatically scaled if the length of the period changes, so this is more efficient than using fixed-length allocations. The sum of the allocated time slices cannot exceed the total period length, so the maximum time slice that can be allocated corresponds to the entire period length (i.e., 100%, where time slices are allocated as a percentage of the period).

[0048] During the time period, when the active driver executes, it uses up its time slice, so the slice timer of the active driver indicates the remainder of the time slice allocated to the driver based on the cumulative execution time of the driver in the time period (for example, slice timer = allocated time slice - total execution time in the time period). The time slice of the driver does not need to be used in a continuous block, for example, in the case where the driver completes its current workload before exhausting its time slice, it can stop execution and keep the remainder of the time slice to execute any future workload in the same time period. When the time that the driver has executed in the time period is equal to the allocated time slice (that is, the allocated time slice = total execution time in the time period), the slice timer of the driver expires, and this situation can be described as the driver's time slice being completely exhausted. As described below, the expiration of the slice timer will not prevent the driver from continuing its execution (that is, the expiration of the slice time will not trigger the driver to stop executing immediately). On the contrary, once the driver's time slice has been exhausted, its priority is reduced, making it more likely to be context-switched off, so that another driver can start execution (for example, so that the driver with an unexpired slice timer can start execution). In the case where more than one driver can be executing in parallel, there can be one slice timer for each executing driver, or there can be a single slice timer that is used for all active drivers while they are executing (e.g., so that when a timer expires for one executing driver, the timer is restarted for the executing drivers that do have a remaining allocation). There can also be a slice timer for each other active driver that was allocated a time slice but is not currently executing, or the total execution time of the active drivers during the period can be stored and used to update the slice timer when it begins executing.

[0049] Two types of timers are used in this method to trigger the change of the priority of the active driver. The expiration of the period timer triggers the priority to be reset to its initial value, and the expiration of the slice timer of the active driver in execution triggers the reduction of the priority of the active driver in the specific execution. By manipulating the priority in this way, the existing scheduling algorithm using the priority of the driver can still be used (for example, without any modification), while providing a guaranteed, configurable, minimum execution time for the active driver (and thus preventing the workload starvation of the specific active driver), and this can reduce the context switching that is particularly expensive (for example, in terms of latency and efficiency) on the GPU (for example, compared with the CPU pipeline) due to the depth of the pipeline exhausted at the time of context switching. The use of these two types of timers also provides flexibility in terms of the allocation configuration for different active drivers and the period length configuration on both the per period level and the longer time scale (for example, on many period lengths).

[0050] Figure 1 A first example of a scheduling method is shown in FIG. The method includes a setting phase 102 and an execution phase 104. Figure 1 As shown, in the setup phase 102, the length of the period is defined (box 106), and a portion of the period is allocated to the active driver (box 108). More than one portion can be allocated (in box 108), each of which is allocated to a different active driver, and in the case of allocating more than one portion, the allocated portions can have the same or different sizes. A portion of the period can be allocated to some or all active drivers respectively (in box 108), and the total allocation cannot exceed 100% of the period (regardless of whether the portions are defined in absolute amounts or percentages / fractions). Therefore, the maximum possible allocation is 100% of the period, in which case this portion is allocated to a single active driver. Some active drivers may not be allocated any portion of the period. As described below, if a portion of the period is not allocated to the active driver, the active driver is not necessarily prevented from being scheduled to execute within the period; however, the driver does not have any guaranteed minimum execution time within the period, and is only executed when there is no workload scheduled from any other driver with an allocation.

[0051] The setup phase 102 is initially performed before the execution phase 104 (eg Figure 1104) but once execution has begun, setup phase 102 may then be performed in parallel with execution phase 104 to update the period lengths and / or allocations in subsequent periods. Without repeating setup phase 102, the period lengths and allocations remain unchanged in subsequent periods. Period lengths and / or partial allocations may be updated in the middle of a setup phase period, but any changes made during a period do not affect the current period, but take effect at the beginning of the next period. As described above, where allocations are defined as a ratio of period lengths, allocations are automatically updated (i.e., scaled) in response to changes in period lengths, which improves efficiency compared to fixed allocations.

[0052] The execution phase 104 begins at the beginning of the period (box 110), at which time the slice usage (e.g., the record of the cumulative execution time of each driver in the period) and the priority of each active driver are reset (box 112). During the first period in the execution phase 104, this reset operation (in box 112) will not change anything because the slice usage is already zero and the priority of each active driver will be at its unmodified input (and therefore reset) level. For active drivers that have executed workloads that have been transferred from the immediately preceding period ("yes" in box 113), if the driver is executing within its allocated portion, the priority of the executing active driver is increased ("yes" in box 114, followed by box 115). In other words, if the slice timer of the executing active driver has not expired, the priority of the executing active driver is increased (in box 115).

[0053] like Figure 1 As shown, in the event that there is no driver ("No" in box 113) executing a workload transferred from an immediately preceding period at the start of the period (box 110), the method takes no further action (indicated by "End") until a driver is subsequently selected for execution and the method restarts (starting from box 111).

[0054] If the executing active driver completes its workload before its allocated portion has been exhausted (i.e., before its slice timer expires), and the active driver has no more workload to execute, the driver stops executing, and its priority is reset to its original input level (box 116). However, if the executing active driver executes for a cumulative time period equal to its allocated portion during the period, such that its slice timer expires (and the driver can be described as having exhausted its allocated portion), the priority of the executing active driver is reduced to a level below its original input level (box 118). This does not directly cause the executing active driver to stop executing; however, it increases the likelihood that the driver is context-switched away so that a higher priority active driver can execute instead.

[0055] If the executing active driver has no allocations, the driver will not execute within its allocated portion, and therefore its priority will not be increased (in block 115). Instead, the driver's priority will be reduced to a level below its original input level (in block 118). As described above, this will not directly cause the executing active driver to cease execution; however, it increases the likelihood that the driver will be context-switched away so that a higher priority active driver can execute instead.

[0056] If a different active driver begins executing within the period (e.g., due to a context switch from a lower priority active driver to a higher priority active driver or the executing active driver completing its current workload), the method continues from block 111 for the newly executing active driver. If the driver executes within its allocated portion ("yes" in block 114), its priority is increased (in block 115), and once the allocated portion is exhausted, its priority is decreased (in block 118).

[0057] If the active driver stops executing during this period due to completion of its current workload, it can then be rescheduled (e.g., based on the scheduling algorithm used) and selected to execute (in block 111), and if it has a new workload to execute, it starts executing again. At this point, if the driver has remaining allocations ("yes" in block 114), its priority is increased again (in block 115), as indicated by the dashed arrow from block 116 to block 111.

[0058] If an active driver stops executing in the period because it is context switched away after it has exhausted its allocated portion, it may still be rescheduled later (e.g., based on the scheduling algorithm used) and begin executing again, e.g., if there are no other active drivers with higher priority that have workloads to execute. At this point, its priority remains at the reduced level (from block 118) until it is reset at the start of the next period.

[0059] If the period timer expires before the executing active driver has exhausted its allocated portion and the period ends (e.g., because the executing active driver is not ready to execute early enough in the period to use the entire allocated portion of the workload), the driver does not stop executing, but its priority is first reset to its original input level (in box 112), and then increased (in box 115) if the driver has an allocation in the new period ("yes" in box 114). The executing active driver can then continue to execute until it exhausts the workload or it exhausts its allocation in the new period (thereby causing its priority to be reduced in box 118) and is context switched out in favor of a higher priority active driver. By not stopping the execution of the driver immediately after the driver's allocated portion is exhausted, the number of context switches is reduced and the efficiency of the GPU is improved.

[0060] Because Figure 1 As shown and described above, if all allocated portions have been exhausted, or any remaining portion relates to an active driver that does not have any workload to execute, a priority-based scheduling algorithm (e.g., a scheduling algorithm that selects drivers to execute based on their relative priorities and can, for example, select a higher priority driver with a workload to execute before a lower priority driver) may be used to select any active driver that has not been allocated a portion (in box 108) for execution. Such active drivers will remain at their initial, unmodified priority until they begin execution, and will therefore be at a higher priority than those active drivers that have exhausted their allocated portions and have had their priorities reduced (in box 118). Once a driver begins to execute outside of an allocation in a particular time period or without the allocation ("no" in box 114), its priority is reduced to below its initial level (in box 118).

[0061] The input unmodified priorities of the active drivers may all fall within a range of values ​​that may be referred to as a normal range. When the priority of the active driver increases (in block 115), the priority may increase from a value within the normal range to a value within a higher range, which may be referred to as an upper range. The higher range may be wider or narrower or the same width as the normal range (i.e., in terms of the range of priority values ​​that fall within the range).

[0062] In some examples, the upper range may include a single maximum priority value, in which case the priority may be increased from its input value within the normal range to the single upper priority value when the priority of the active driver is increased (in block 115). However, in such examples, the input priority value of the active driver needs to be stored so that the priority can be subsequently reset (in blocks 112 or 116).

[0063] However, in other examples, when the priority of the active driver is increased (in block 115), the priority may be increased from its input value (P initial ) increases by a first predefined amount (A ceiling ) to a higher range of values ​​(P ceiling )(For example, P ceiling =P initial +A ceiling ). In such examples, the higher range may have the same width as the normal range. This avoids the need to store the input priority value because to reset the priority (in block 116), the priority value is reduced by the first predefined amount. In an exemplary embodiment, the priority may be increased / decreased by the first predefined amount by setting / unsetting a predefined bit in the priority value that is reserved for this purpose (e.g., bit 30), i.e., it is not used to set priority values ​​within the normal range (e.g., so that no more than the first 29 bits in the priority value may be used to set the normal range of values).

[0064] In a similar manner, when the priority of the active driver is reduced below its initial value (in block 118), the priority may be reduced from a value within the upper range to a value within a range below the normal range (which may be referred to as the lower range). The lower lower range may be wider or narrower or the same width as the normal range and / or the upper range (i.e., in terms of the range of priority values ​​that fall within the range).

[0065] In some examples, the lower range may include a single minimum priority value, in which case the priority may be reduced from its input value within the normal range to the single lower priority value when the priority of the active driver is reduced (in block 118). However, in such examples, the input priority value of the active driver needs to be stored so that the priority can be reset later (in block 112).

[0066] However, in other examples, when the priority of the active driver is reduced (in block 118), the priority may be reduced by a second predefined amount (A) that is greater than the first predefined amount. floor )(For example, P floor =P ceiling –A floor , where A floor >A ceiling This ensures that the resulting priority value (P floor) is below its input value and falls within the lower range. In such examples, the lower lower range may have the same width as both the normal range and the upper range. This avoids the need to store the input priority value because to reset the priority (in block 112), the priority value is increased by the difference between the first predefined amount and the second predefined amount (e.g., P initial =P floor +A floor –A ceiling ). In an exemplary embodiment, where a two's complement is used to represent the priority value, the priority may be decreased by a second predefined amount by setting the most significant bit in the priority value (e.g., bit 31 of a 31-bit priority value) (in addition to being set to the next most significant bit that increases the priority value), wherein this most significant bit (MSB) is also not used to set the priority value within the normal range (i.e., it is reserved for this purpose), and setting the MSB changes the priority value to negative. The priority may then be reset by unsetting both the reserved bits, i.e., the MSB and the next most significant bits (e.g., bits 30 and 31 of a 31-bit priority value).

[0067] As described above, this avoids the need to store the input priority values ​​of the active drivers in cases where the priorities are adjusted up and down by predefined amounts. In addition, it preserves the relative priorities of the active drivers, which is particularly useful for active drivers that have exhausted their allocated portions and have priority values ​​in the lower range. This has the effect that in the absence of active drivers with workloads to be executed whose priorities are in the upper or normal range, the priority-based scheduling algorithm can be used to schedule the active drivers in the lower range with the same relative priorities relative to each other as their input priorities.

[0068] Resetting the priorities (in block 112) at the start of each period enables each period to start afresh while reducing context switching by avoiding context switching away executing drivers when the period timer expires. If the currently executing driver does not have an allocation in the new period, a context switch will only occur at the start of the period, and in this case the driver will be context switched away in favor of the driver that has an allocation in the new period.

[0069] Figure 1 The method can refer to Figure 2 and Figure 3 The exemplary scenario shown in FIG. Figure 2 is a schematic diagram showing both the initial allocation of portions of each time period to active drivers (in the boxes in the lower row) and the resulting execution schedule (in the boxes in the upper row). Figure 2, the boxes in the lower row show the allocation of the various parts to each driver, but do not imply any particular order in which they must be executed. Events are indicated by vertical arrows. In the example shown, there are three active drivers, denoted D0, D1, and D2. Three time periods are shown, labeled I, II, and III, with the timeline proceeding from left to right (i.e., so that the first period I is on the left and the third period III is on the right). In the boxes in the upper row, the height of the box indicates the priority value of the corresponding executing driver at that time; however, in Figure 3 The priority of active drivers is shown more clearly in . Figure 2 The priority of the executing driver shown in is either the driver's increased upper priority (as increased in block 115) or the driver's decreased lower priority (as decreased in block 118). Figure 2 , the upper level is shown as being the same for all drivers; however, as described above, there may be a range of priority values ​​within the upper range and within any range. Figure 3 Shown in Figure 2 A more detailed graph of the priority of each of the three active drivers for the three time periods shown, Figure 2 and Figure 3 The timeline alignment is shown. Figure 3 Three ranges of priority are marked: an upper range 301, a normal range 302, and a lower range 303, and in this example, D0 has a higher normal priority (P0) than D1 (P1), and D1 has a higher normal priority (P1) than D2 (P2).

[0070] In the first period I, Figure 2 , a portion is allocated to each of the three active drivers D0, D1, and D2. In this example, the portion allocated to the first active driver D0 is defined by the user as 60%, and the remaining 40% is dynamically allocated between the other two active drivers D1 and D2 (i.e., 20% to each active driver). This is shown in the boxes in the next row within the first time period, but as mentioned above, the order of the boxes in the next row does not indicate any kind of preferred order for executing the three drivers. In the first time period, D0 executes until it has exhausted its allocated portion of the time period (and therefore its slice timer expires). As Figure 3As shown, while D0 is executing, its priority is raised to within the upper range 301 (in box 115), and then once its slice timer expires, its priority is lowered to within the lower range 303 (in box 118), with the result that D1 (which is now at its initial priority within the normal range 302) has a higher priority than D0. Therefore, D1 is selected to execute, a context switch occurs (arrow 202), and D1 begins execution. Once D1 is executing, its priority is raised to within the upper range 301 (in box 115). When D1 has used up its allocated portion of the time period (and therefore its slice timer expires), its priority is lowered to within the lower range 302 (arrow 204). There is no context switch at this time because D2 has no workload to execute, and therefore D1, which has more workload to execute, continues to execute until D2 has a workload to execute, at which time (arrow 206) a context switch occurs and D2 begins execution. Although Figure 2 206), D1 would be context switched out in favor of D0 because D0's reduced priority (within the lower bound) is higher than D1's reduced priority (also within the lower bound). At the point where the period timer expires (arrow 208), D2 is executing and has not yet used its entire allocation for the first period because there is no workload to execute at the point where D1's slice timer expires.

[0071] When the period timer expires (arrow 208), there is no immediate context switch. Instead, the currently executing driver (D2) continues to execute, and the slice usage, allocation, and priority are reset (in box 112). Figure 2In the example of , the allocation remains unchanged in the second period II (e.g., 60 / 20 / 20), but the period length has increased. When D2 is executing and has an allocation in the second period, its priority is increased to the upper range 301, and it continues to execute until its slice timer expires (arrow 210). A context switch then occurs, and D0 begins execution. The priority of D2 is reduced to the lower range 303 (because its allocation has been exhausted), and the priority of D0 is increased to the upper range 301 (because its allocation has not yet been exhausted). In this example, D0's workload is completed before its allocation is exhausted (arrow 212). D0 stops executing after its workload is completed, and D1 begins execution. The priority of D0 is reset to its initial value in the normal range 302 (in box 116, because its allocation has not yet been exhausted, but it has no workload to execute), and the priority of D1 is increased to the upper range 301 (because its allocation has not yet been exhausted). Before D1's slice timer expires (arrow 214), another workload for D0 is available, so D1 is context switched away and D0 resumes its execution. D1's priority is reduced to the lower range 303 (because its allocation has been exhausted), and D0's priority is increased to the upper range 301 (because its allocation has not yet been exhausted). At the point where the period timer expires at the end of the second period (arrow 216), D0 is executing and has just used its allocation in the second period.

[0072] When the period timer expires at the end of the second period (arrow 216), there is no immediate context switch. Instead, the currently executing driver (D0) continues to execute, and the slice usage, allocation, and priority are reset (in box 112). Figure 2In the example of , distribution changes in the third period III, wherein the user has allocated two drivers D0 and D1, and unallocated all 100%. In the third period, the period length has also been reduced. When D0 is executing and has distribution in the third period, its priority is increased to upper range 301, and it continues to execute until its slice timer expires (arrow 218). When the slice timer of D0 expires, its priority is reduced to in the lower range 303 (in frame 118), and it continues to execute until it does not have more workloads to execute (arrow 220). At this point, other active drivers do not have any workloads to execute, so no driver is executing in a short time. Once D1 has a workload to execute, it starts to execute, and its priority is increased to in the upper range 301 (in frame 115). Once D1 has exhausted the allocation part of its time period (and therefore its slice timer expires), its priority is reduced to in the lower range 303 (arrow 220). There is no context switch at this point because D0 or D2 have no workload to execute, and therefore D1, which has more workload to execute, continues to execute until D0 has a workload to execute. Since D0 has a higher priority within the lower bound range 303 than D1 has within the lower bound range 303, once D0 has a workload, a context switch occurs (arrow 222) and D0 begins to execute. Although Figure 2 , D2 is not shown as executing in the third time period III, but if D2 had a workload to execute and was selected for execution, its priority would immediately drop to within the lower range 303 (in box 118) because it is not executing within the allocation (because D2 is not allocated in the third time period).

[0073] As shown in the third period III, Figure 2 , drivers with priorities in the lower range 303 execute in an unrestricted time-slicing manner until the period timer expires (arrow 224), at which time their allocation, usage, and priority are reset (in box 112).

[0074] like Figure 2As shown, the length of the period (and therefore the duration of the period timer) can change over time. Compared with longer periods, shorter periods generally result in smaller allocations and more context switches to different active drivers. As described above, context switching in the GPU is expensive (e.g., in terms of latency and efficiency), and therefore the period length can be increased (in box 106) in response to the number of context switches in the previous period or the group of previous periods exceeding a predefined threshold. However, longer periods may result in larger allocations to different active drivers, and may cause drivers with shorter workloads to be delayed in their execution until the end of the period of other drivers with longer workloads. Therefore, in addition to (or instead of) increasing the period length (in box 106) based on the number or frequency of context switches, the period length (in box 106) can be reduced in response to a decrease in the frame rate of a specific driver detected. By enabling the period length to be dynamically changed in this manner (and / or in response to other detected conditions within the GPU or wider computing system), without the need to change the underlying scheduling algorithm, the period length can be optimized for a specific combination of workloads executed at any time.

[0075] As described above, the period timer can be a user-configurable parameter or a system-defined parameter. Similarly, for any active driver, the portion of the period assigned to the driver can be user-defined or system-defined. Data identifying the portion and period duration assigned to each active driver can be stored in a local data structure (which can be referred to as a time slice data structure) (e.g., within the GPU) and updated when the period timer is triggered (i.e., when the period timer expires). This update enables any changes made during the previous period (i.e., the period that just ended) to be implemented in the next period. Inactive drivers are not assigned portions, and some or all of the active drivers can be assigned portions. When the driver becomes active, these portions can be defined (by the user or the system) and added to the time slice data structure when the period timer is triggered next time. Once the driver is no longer active (e.g., it becomes offline), any portion assigned to the driver is de-allocated. The time slice data structure can store a default period duration, which can be used when there is no user-defined period duration and / or initially before modifying the period (as described above) based on detected system conditions.

[0076] Figure 4 Shown in more detail Figure 1 An exemplary embodiment of the execution phase 104 of the method. Figure 1 The method shown in is similar to the method described above. Figure 4The method of has two starting points: at the beginning of a period, the method starts at block 110, and when a new driver is subsequently started within the period (e.g., after a context switch or because a previously executing driver completes its workload), Figure 4 The method starts at box 111.

[0077] As described above, at the start of a period (block 110), slice usage and priority are reset (in block 112). Slice usage may be stored as part of the time slice state information, and this may be stored separately from or as part of the time slice data structure described above.

[0078] When the driver begins execution (in box 111) or when the driver has been executed at the beginning of the period ("yes" in box 113), the remaining time allocation of the driver is calculated (box 406). This can include accessing the allocation data (i.e., data defining the portion of the current time period that has been allocated to the driver that has just started to execute) from the time slice data structure detailed above, and checking the time slice state information to determine whether any allocated portion has been used. The time slice state information may include the cumulative execution time of each active driver that has been executed in the current time period, and as described above, this is reset at the beginning of each period (in box 112). This remaining time allocation (as determined in box 406) is used to determine whether the driver is executed within its allocation (box 114), and if the driver is executed within its allocation ("yes" in box 114), the driver's slice timer is set (box 410). In some examples, the starting value of the slice timer is a predefined value (e.g., zero), but in other examples, a timestamp can be recorded when the timer is started (in box 410). If the driver is executing within its allocation ("yes" in block 114), then its priority is also increased (in block 115) as described above. If the driver is not executing within its allocation ("no" in block 114), then its priority is decreased (in block 118) as described above, and the driver continues to execute because, as described above, once the allocation is exhausted, the driver is free to run (i.e., its execution is independent of time slicing).

[0079] If the driver's slice timer expires before the driver completes executing its workload (block 418), the driver's priority is lowered (block 118) as described above, and the driver continues to execute until a context switch occurs, the driver completes its workload, or the period timer expires. When the timer expires (in block 418), the driver's time slice state information can be updated to set the driver's cumulative execution time in the current period to a maximum value, indicating that the driver has used all of its allocations in the current period.

[0080] If the driver completes its workload before the slice timer expires, the slice timer is stopped (box 414), and the priority of the driver is reset as described above (in box 116). When the slice timer is stopped (in box 414), a timestamp can be recorded, and the difference between this timestamp and any previously recorded first timestamp (from when the driver started executing), or the known starting value of the timer, can be used to update the driver's time slice state information to record the cumulative execution time of the driver in the current period. In other examples, different methods can be used to determine the execution time of the driver so that the cumulative execution time of the driver in the current period can be updated in the time slice state information. As described above, if the driver subsequently restarts execution in the same period, this time slice state information will be used (in box 406) to calculate the remaining time allocation of the driver, and the time slice state information will be reset at the beginning of the next period (in box 112).

[0081] An active driver can execute multiple workloads (where these workloads can be generated by different masters), and in such examples, the driver's workload is completed only when the last workload being executed is completed. Figure 5 As shown in the figure, Figure 4 A variation of the method shown in and described above. Figure 5 Methods and Figure 4 The method shown in differs only in that when a workload completes, it is determined whether the workload is the last workload of the executing driver (block 516), and only if it is the last workload ("yes" in block 516), the timer is stopped (in block 414) and the priority of the driver is reset (in block 116). If the completed workload is not the last workload, no action is taken on the timer, and this is re-evaluated when the next workload completes.

[0082] In order to track when the driver has completed its last workload, a workload counter may be used. This workload counter for the driver may be stored as part of the time slicing state information, or may be stored elsewhere. Where workload counters are used, these are reset (in box 112) at the start of each time period along with the slice usage and priority. The slice usage may be stored as part of the time slicing state information, and this may be stored separately from or as part of the time slicing data structure described above. If the driver is currently executing ("yes" in box 113), this means that the workload of the active driver is transferred from one period to the next, and since the workload counter has just been reset (in box 112), the workload counter of the driver is incremented. When a new workload of the active driver is selected for execution, the workload counter of the driver is incremented. Subsequently, when the workload of the driver is completed, the workload counter of the driver is decremented. If this causes the workload counter to transition from one to zero, this indicates that the driver has completed executing the last workload ("yes" in box 516), and the method may continue to stop the driver's timer (in box 414), as described above with reference to Figure 4 If the transition is anything other than one to zero, then the driver is still executing other workloads ("No" in block 516), and no additional action is taken (as described above).

[0083] In the above method, if the currently executing driver does not have an allocation in the new time slot (causing its priority to be reduced) and another active driver does have an allocation in the new time slot, then the workload that the driver was executing at the point where the time slot timer expires is transferred to the next time slot, and the driver is only context switched out at the beginning of the time slot. As described above, context switches on the GPU take time because the depth of the GPU pipeline needs to be exhausted, so increasing the amount of context switches performed increases latency and reduces the efficiency of the GPU. This limited amount of time spent performing context switches can mean that in the case where the driver is context switched out very close to the end of the time slot (such that the context switch has not completed when the time slot timer expires), the driver appears to still be executing at the end of the time slot, such as Figure 6 shown. Figure 6A period 600 is shown in which driver D0 executes, is then context-switched away (arrow 601), and driver D1 begins to execute. Shortly before the end of the period (as shown by arrow 602), driver D1 is context-switched away (arrow 604), causing the context switch to not be completed before the end of the period. This will cause the execution of the driver to be transferred to the next period, where its priority is immediately raised to within the upper limit range (in box 115), and will cause the driver to be context-switched back immediately after the context switch is completed. This introduces a period of unnecessary context switching (indicated by bracket 606) and reduces the efficiency of the GPU.

[0084] In order to solve this context switching delay and further improve the efficiency of the scheduling method, we can Figure 7 Modifications shown Figure 4 or Figure 5 Methods. Figure 7 As shown, once the driver has begun to execute within the remaining allocation ("yes" in block 114) and its priority has been increased (block 115), a timer is started (block 410). At this point, there are two possible situations, namely, a completion event or timer expiration. The completion event (in block 412) can be the completion of a context switch (CSW) that switches out the driver (e.g., this context switch was initiated before the start of the period in block 110) or the completion of the workload. If the timer expires, the priority of the driver is lowered as described above (in block 118).

[0085] In the event of a completion event, the method determines whether the completion event (e.g., context switch handoff or workload completion) is associated with the last workload of the driver (frame 516). If the workload associated with the completion event is not the last workload, no action is taken on the completion event, and this is re-evaluated when the next completion event occurs. However, if the completion event is indeed associated with the last workload ("yes" in frame 516, i.e., it is the completion of the context switch of the last workload of the driver or the completion of the last workload of the driver), the timer (414) is stopped, and data can be recorded / updated as described above.

[0086] If the completion event is the completion of a context switch ("yes" in block 715), the priority of the driver that was context switched out is reduced to the lower range (block 118). The driver's priority will not have been in the lower range because the context switch has occurred across a period boundary, so that if the driver has an allocation in the new period, the driver's priority is increased to the upper range (in block 115) (e.g., because it was reset at the beginning of the period and then immediately increased due to the driver executing within its new allocation).

[0087] If the completion event is not the completion of the context switch of the last workload ("No" in block 715), the priority of each active GPU driver is selectively reset or lowered (block 716). If the driver has remaining allocations within the current time period, the driver's priority is reset to its initial value (in block 716, in a manner similar to block 116). However, if the driver has no remaining allocations within the current time period, the driver's priority is lowered to the lower range (in block 716, in a manner similar to block 118).

[0088] Although Figure 7 shows the optimizations associated with latency in completing context switches. Figure 5 However, it should be understood that the optimization (i.e., blocks 715-716) may also be performed in Figure 4 is implemented in the method.

[0089] By introducing Figure 7 , the overall efficiency of the GPU is improved in the case where a context switch occurs very close to the end of a period, so that the context switch has not yet completed when the period timer expires. This is achieved by ensuring that the driver that has just been context switched has a priority within the lower limit ("yes" in block 715, followed by block 118), and by delaying resetting the priority until another completion event occurs (so that the context switch is not completed when the subsequent completion event is triggered). Figure 7 The priority is reset in box 716 at a subsequent moment of the method), and the driver that has just been context-switched cannot be immediately executed again.

[0090] In the above example, only one driver is executing at any one time, and only one driver's priority is within the upper limit at any one time. In a variation of the above method, drivers can be grouped into isolation groups, which include one or more drivers that can be executed simultaneously. Isolation is used to prevent OS failures from affecting each other. For example, if the client OS crashes, another OS can still continue to submit jobs to the GPU seamlessly. In the case of defining isolation groups, only one isolation group has a driver priority within the upper limit. In the case where drivers in the same isolation group are executed in parallel, the execution efficiency of the driver can be reduced due to the sharing of resources between the executing drivers. Therefore, the above method can be modified so that although each driver has a separate allocation (from box 108), the allocation portions of all drivers in the isolation group are summed, and then this total allocation of the isolation group (for example, in boxes 114 and 406) is used to determine whether the driver is executed within or outside its allocation portion. For example, given an isolation group comprising three drivers D0, D1, D2 having respective individual allocations during time periods of x%, y%, and z% of the time period, each of the three drivers is considered to have an allocation of (x+y+z)%.

[0091] The above method prevents workload starvation by enabling the allocation of a guaranteed minimum execution time to a driver while enabling the use of any priority-based scheduling algorithm (e.g., an existing priority-based scheduling algorithm can be used without any modification, or an improved priority-based scheduling algorithm developed in the future can also be used with the described method). By increasing and / or decreasing the priority by a predefined amount (as described above), the relative order of the priorities remains unchanged (e.g., even if there is no active driver with a remaining allocation with a workload to be executed, this also implements priority-based scheduling), and there is no need to store the initial priority. As long as the driver has an allocation in the next period, the method reduces costly context switches by enabling the executing driver to continue to execute across period boundaries (i.e., from one period to the next period). The method is flexible in its configuration (both in the allocation of time slices and the period length). These can be user-defined and / or system-defined, and can be dynamically adjusted in response to detected conditions within the GPU (e.g., the number of detected context switches and / or the detected frame rate of the driver's GUI).

[0092] The above method may be implemented within a GPU, for example, within a scheduler in the GPU or within logic associated with the scheduler. Fig. 9A computer system 800 is shown in which the graphics processing system described herein may be implemented. The computer system includes a CPU 802, a GPU 804, a memory 806, a neural network accelerator (NNA) 808, and other devices 814, such as a display 816, a speaker 818, and a camera 822. A driver is executed on the CPU 802. The GPU 804 includes a microprocessor 810 that may implement the above-described method, or the method may be implemented by another entity within the GPU. Fig. 9 In the example shown, the GPU also includes a repository 812 that stores time slice state information and / or time slice data structures. This repository 812 is part of the memory hierarchy within the computer system 800, and in other examples, it can be located elsewhere within the GPU (e.g., within the memory 806). The components of the computer system can communicate with each other via a communication bus 820.

[0093] Figure 8 The GPU is shown as including a number of functional blocks. This is merely schematic and is not intended to define a strict division between different logical elements of such an entity. Each functional block may be provided in any suitable manner. It should be understood that intermediate values ​​described herein as being formed by the scheduler need not be physically generated by the scheduler at any time, and may simply represent logical values ​​that conveniently describe the processing performed by the scheduler between its input and output. It should also be understood that although Figure 8 Particular combinations of elements are shown, but in other implementations, one or more of the depicted components may be omitted from the system.

[0094] The GPU and scheduler described herein may be included in hardware on an integrated circuit. The scheduler described herein may be configured to perform any of the methods described herein. Generally speaking, any of the functions, methods, techniques, or components described above may be implemented in software, firmware, hardware (e.g., fixed logic circuitry), or any combination thereof. The terms "module," "function," "component," "element," "unit," "block," and "logic" may be used herein to generally represent software, firmware, hardware, or any combination thereof. In the case of software implementation, a module, function, component, element, unit, block, or logic represents a program code that performs a specified task when executed on a processor. The algorithms and methods described herein may be performed by one or more processors that execute code, which causes the processor to perform the algorithm / method. Examples of computer-readable storage media include random access memory (RAM), read-only memory (ROM), optical disks, flash memory, hard disk storage, and other memory devices that may use magnetic, optical, and other technologies to store instructions or other data and may be accessed by a machine.

[0095] As used herein, the terms computer program code and computer readable instructions refer to any kind of executable code for a processor, including code expressed in machine language, interpreted language, or scripting language. Executable code includes binary code, machine code, byte code, code that defines an integrated circuit (e.g., a hardware description language or netlist), and code expressed in programming language code such as C, Java, or OpenCL. Executable code can be, for example, any kind of software, firmware, script, module, or library that, when properly executed, processed, interpreted, compiled, run in a virtual machine or other software environment, causes a processor of a computer system supporting the executable code to perform the tasks specified by the code.

[0096] A processor, computer or computer system may be any kind of device, machine or special purpose circuit, or a collection or part thereof, which has processing capabilities so that instructions can be executed. A processor may be or include any kind of general or special purpose processor, such as a CPU, GPU, NNA, system on chip, state machine, media processor, application specific integrated circuit (ASIC), programmable logic array, field programmable gate array (FPGA), etc. A computer or computer system may include one or more processors.

[0097] It is also intended to cover software that defines the configuration of hardware as described herein, such as HDL (Hardware Description Language) software, such as used for designing integrated circuits or for configuring programmable chips to implement desired functions. That is, a computer-readable storage medium may be provided having encoded thereon computer-readable program code in the form of an integrated circuit definition data set that, when processed (i.e., run) in an integrated circuit manufacturing system, configures the system to manufacture a GPU configured to perform any of the methods described herein, or to manufacture a GPU that includes any of the devices described herein. The integrated circuit definition data set may be, for example, an integrated circuit description.

[0098] Thus, a method of manufacturing a GPU as described herein at an integrated circuit manufacturing system may be provided. In addition, an integrated circuit definition data set may be provided that, when processed in an integrated circuit manufacturing system, enables the method of manufacturing a GPU to be performed.

[0099] The integrated circuit definition data set may be in the form of computer code, for example, as a netlist, code for configuring a programmable chip, as a hardware description language that defines hardware suitable for fabrication at any level in an integrated circuit, including as register transfer level (RTL) code; as a high-level circuit representation, such as Verilog or VHDL; and as a low-level circuit representation, such as OASIS (RTM) and GDSII. Higher-level representations (e.g., RTL) that logically define hardware suitable for fabrication in an integrated circuit may be processed at a computer system configured to generate a manufacturing definition of the integrated circuit in the context of a software environment that includes definitions of circuit elements and rules for combining those elements to generate a manufacturing definition of the integrated circuit so defined by the representation. As is typically the case with software executed at a computer system to define a machine, one or more intermediate user steps (e.g., providing commands, variables, etc.) may be required to configure the computer system to generate a manufacturing definition of the integrated circuit to execute code that defines the integrated circuit to generate the manufacturing definition of the integrated circuit.

[0100] Now about Fig. 9 An example of processing an integrated circuit definition data set in an integrated circuit manufacturing system to configure the system to manufacture a GPU is described.

[0101] Fig. 9 An example of an integrated circuit (IC) manufacturing system 902 configured to manufacture a GPU as described in any of the examples herein is shown. Specifically, the IC manufacturing system 902 includes a layout processing system 904 and an integrated circuit generation system 906. The IC manufacturing system 902 is configured to receive an IC definition data set (e.g., defining a GPU as described in any of the examples herein), process the IC definition data set, and generate an IC (e.g., which includes a GPU as described in any of the examples herein) based on the IC definition data set. Processing of the IC definition data set configures the IC manufacturing system 902 to manufacture an integrated circuit that includes a GPU as described in any of the examples herein.

[0102] The layout processing system 904 is configured to receive and process an IC definition data set to determine a circuit layout. Methods for determining a circuit layout based on an IC definition data set are known in the art and may, for example, involve synthesizing RTL code to determine a gate-level representation of a circuit to be generated, such as in terms of logic components (e.g., NAND, NOR, AND, OR, MUX, and FLIP-FLOP components). By determining location information for the logic components, the circuit layout may be determined by the gate-level representation of the circuit. This may be done automatically or with user involvement in order to optimize the circuit layout. When the layout processing system 904 has determined the circuit layout, the layout processing system may output the circuit layout definition to the IC generation system 906. The circuit layout definition may be, for example, a circuit layout description.

[0103] As is known in the art, the IC generation system 906 generates the IC according to the circuit layout definition. For example, the IC generation system 906 may implement a semiconductor device manufacturing process to generate the IC, which may involve a multi-step sequence of photolithography and chemical processing steps during which electronic circuits are gradually formed on a wafer made of semiconductor material. The circuit layout definition may be in the form of a mask that can be used in a photolithography process to generate the IC according to the circuit definition. Alternatively, the circuit layout definition provided to the IC generation system 906 may be in the form of a computer readable code that the IC generation system 906 can use to form a suitable mask for generating the IC.

[0104] The different processes performed by the IC manufacturing system 902 may all be implemented in one location, for example, by one party. Alternatively, the IC manufacturing system 902 may be a distributed system such that some processes may be performed at different locations and may be performed by different parties. For example, some of the following stages may be performed at different locations and / or by different parties: (i) synthesizing RTL code representing an IC definition data set to form a gate-level representation of a circuit to be generated; (ii) generating a circuit layout based on the gate-level representation; (iii) forming a mask based on the circuit layout; and (iv) using the mask to manufacture the integrated circuit.

[0105] In other examples, processing an integrated circuit definition data set at an integrated circuit manufacturing system may configure the system to manufacture a GPU without processing the IC definition data set to determine the circuit layout. For example, the integrated circuit definition data set may define a configuration of a reconfigurable processor (such as an FPGA), and processing the data set may configure the IC manufacturing system to generate a reconfigurable processor having the defined configuration (e.g., by loading the configuration data into the FPGA).

[0106] In some embodiments, the integrated circuit manufacturing definition data set, when processed in the integrated circuit manufacturing system, can cause the integrated circuit manufacturing system to produce an apparatus as described herein. Fig. 9 Configuring an integrated circuit manufacturing system in the manner described may enable the manufacture of devices as described herein.

[0107] In some examples, the integrated circuit definition data set may include software that runs on, or in combination with, hardware defined at the data set. Fig. 9 In the example shown in , the IC generation system can also be configured by the integrated circuit definition data set to load firmware onto the integrated circuit when manufacturing the integrated circuit according to the program code defined in the integrated circuit definition data set, or to otherwise provide the integrated circuit with program code for use with the integrated circuit.

[0108] When compared to known implementations, the implementation of the concepts set forth in this application in devices, equipment, modules and / or systems (and in the methods implemented herein) may result in performance improvements. Performance improvements may include one or more of improved computing performance, reduced latency, increased throughput and / or reduced power consumption. During the manufacture of such devices, equipment, modules and systems (e.g., in integrated circuits), a trade-off may be made between performance improvements and physical implementations to improve manufacturing methods. For example, a trade-off may be made between performance improvements and layout area to match the performance of known implementations, but using less silicon. For example, this may be accomplished by reusing functional blocks in a serial manner or sharing functional blocks between elements of devices, equipment, modules and / or systems. In contrast, the concepts set forth in this application that result in improvements in the physical implementation of devices, equipment, modules and systems (e.g., reduced silicon area) may be weighed against performance improvements. This may be accomplished, for example, by manufacturing multiple instances of a module within a predefined area budget.

[0109] Applicants hereby independently disclose each individual feature described herein and any combination of two or more such features, to the extent that such feature or combination can be implemented based on the specification as a whole in view of the common general knowledge of a person skilled in the art, regardless of whether such feature or combination of features solves any problem disclosed herein. In view of the foregoing description, it will be clear to a person skilled in the art that various modifications can be made within the scope of the invention.

Claims

1. A method for scheduling a plurality of active GPU drivers in a GPU, each of the active GPU drivers having an initial priority, and comprising: For one or more active GPU drivers among the plurality of active GPU drivers, allocating a portion of the scheduling period to the active GPU driver; Selecting an active GPU driver for execution according to a priority-based scheduling algorithm; In response to the active GPU driver executing within its assigned portion, increasing a priority of the active GPU driver; In response to the active GPU driver completing its workload within its allocated portion, resetting a priority of the active GPU driver; In response to the active GPU driver executing within its entire allocated portion, lowering the priority of the active GPU driver; as well as At the beginning of each scheduling period, reset the priority of each active GPU driver to its initial priority.

2. The method according to claim 1, wherein: Increasing the priority of the active GPU driver includes increasing the priority of the active GPU driver by a first predefined amount, and wherein decreasing the priority of the active GPU driver includes decreasing the priority of the active GPU driver by a second predefined amount.

3. The method according to claim 2, wherein: Each priority value is represented using a two's complement number, and increasing the priority of the active GPU driver by a first predefined amount includes setting a first reserved bit in the value indicating the priority of the active GPU driver, and wherein decreasing the priority of the active GPU driver by a second predefined amount includes setting a second reserved bit in the value indicating the priority of the active GPU driver.

4. The method according to claim 3, wherein: Resetting the priority of the active GPU driver includes clearing a first reserved bit and a second reserved bit in a value indicating the priority of the active GPU driver.

5. The method according to claim 1, further comprising: For one or more active GPU drivers of the plurality of active GPU drivers, the portion of a scheduling period allocated to the active GPU driver in a next scheduling period is changed.

6. The method according to claim 5, wherein: The portion of the scheduling period allocated to the active GPU driver within the next scheduling period is changed in response to a first detected system condition.

7. The method according to claim 6, wherein: The first detected system condition is a reduction in a frame rate of the active GPU driver. The method of claim 1 , further comprising defining an initial length of the scheduling period.

9. The method of claim 1, further comprising changing the length of the next scheduled period.

10. The method according to claim 9, wherein: The length of the next scheduled period is changed in response to a second detected system condition.

11. The method according to claim 10, wherein: The second detected system condition relates to a number of detected context switch events.

12. The method according to claim 1, wherein: The portion of the scheduling period is allocated to the active GPU driver according to user-defined parameters.

13. The method according to claim 1, further comprising: In response to the active GPU driver starting execution: calculating a remainder of the allocated portion using slice usage data indicating a cumulative execution time of the active GPU driver during the scheduling period; If the remainder of the allocated portion is positive, determining whether the active GPU driver is executing within its allocated portion; as well as In response to determining that the active GPU driver is executing within its allocated portion, starting a timer for the active GPU driver, and In response to the active GPU driver completing its workload within its allocated portion, Stop the timer of the active GPU driver, And wherein the method further comprises resetting the slice usage data of each active GPU driver at the beginning of each scheduling period.

14. The method according to claim 13, further comprising: In response to the active GPU driver completing the workload within its assigned portion, selectively resetting or lowering the priority of each other active GPU driver; as well as In response to the active GPU driver completing a context switch of a workload, a priority of the active GPU driver is lowered.

15. The method according to claim 1, further comprising: In response to the active GPU driver starting execution: calculating a remainder of the allocated portion using slice usage data indicating a cumulative execution time of the active GPU driver during the scheduling period; If the remainder of the allocated portion is positive, determining whether the active GPU driver is executing within its allocated portion; as well as In response to determining that the active GPU driver is executing within its allocated portion, starting a timer for the active GPU driver, and In response to the active GPU driver completing the workload within its allocated portion, determining whether the completed workload was the last workload of the active GPU driver; and In response to determining that the completed workload was the last workload of the active GPU driver, stopping a timer of the active GPU driver, And wherein the method further comprises resetting the slice usage data of each active GPU driver at the beginning of each scheduling period.

16. The method according to claim 15, further comprising: In response to the active GPU driver completing a last workload within its assigned portion, selectively resetting or lowering the priority of each other active GPU driver; as well as In response to the active GPU driver completing a context switch of a last workload, the priority of the active GPU driver is lowered.

17. The method of claim 13, further comprising determining that the active GPU driver has executed within its entire allocated portion when the time elapsed since the timer for the active GPU driver was started is equal to the remaining portion of the calculation for the allocated portion.

18. A GPU comprising a microprocessor configured to execute the method according to any one of claims 1-17.

19. The GPU of claim 18, wherein: The GPU is embodied in hardware on an integrated circuit.

20. A computer-readable storage medium having computer-readable code encoded thereon, the computer-readable code being configured to cause the method according to any one of claims 1-17 to be performed when the code is executed.

Images