Apparatus and method for improving performance of switchable graphics systems, energy consumption based applications, and power / thermal budgets of real-time systems - Patents.com

Abstract

The switchable graphics management scheme uses performance / watt information for both the iGPU and dGPU, along with system real-time resources such as the SoC (system-on-chip) thermal budget and system power budget, to determine the appropriate GPU for rendering a task. The scheme uses this threshold power point information, along with system resources, to determine the GPU optimized for rendering tasks for every application and use case. Therefore, the scheme adapts to each system design based on the capabilities of that particular system.

Description

[Technical Field]

[0001] Priority claims This application claims the benefit of priority to U.S. Provisional Application No. 62 / 889,511, filed August 20, 2019, and entitled "Apparatus and Method To Improve Switchable Graphics System Performance And Energy Consumption Based Applications And Real-Time System Power / Thermal Budgets," which is incorporated by reference in its entirety.

[0002] This application relates to an apparatus and method for improving the performance of switchable graphics systems, energy consumption based applications, and power / thermal budgets of real-time systems. [Background technology]

[0003] In existing switchable graphics systems, the decision of an application to use integrated graphics (iGPU) or discrete graphics (dGPU) for task rendering is determined solely by the graphics software driver and the operating system (OS). The driver / OS that decides between iGPU and dGPU for task execution has no information about the GPU's performance-per-watt capability, nor about system resources such as memory configuration, SoC (system-on-chip) thermal budget, or battery power budget, which are key parameters that affect both GPU performance and energy consumption. [Brief explanation of the drawings]

[0004] Embodiments of the present disclosure will be more fully understood from the detailed description given below and the accompanying drawings of various embodiments of the present disclosure, which should not be construed as limiting the disclosure to the particular embodiments, but are for purposes of illustration and understanding only. [Figure 1] 1 is a block diagram of a data processing system equipped with an apparatus for improving memory access performance between a shared local memory (SLM) and a system global memory (SGM) in accordance with some embodiments of the present disclosure. [Figure 2] FIG. 1 is a block diagram of a processor having one or more processor cores, an integrated memory controller, and an integrated graphics processor, and equipped with equipment for improving memory access performance between an SLM and an SGM, in accordance with some embodiments of the present disclosure. [Figure 3] FIG. 1 is a block diagram of a graphics processor, which may be a discrete graphics processing unit or may be a graphics processor integrated with multiple processing cores, according to some embodiments of the present disclosure. [Figure 4] FIG. 1 is a block diagram of a graphics processing engine (GPE) for a graphics processor, according to some embodiments of the present disclosure. [Figure 5] FIG. 1 is a block diagram of another embodiment of a graphics processor associated with an execution unit. [Figure 6] FIG. 1 illustrates thread execution logic including an array of processing elements used in some embodiments of a GPE. [Figure 7] FIG. 2 is a block diagram illustrating a graphics processor execution unit instruction format in accordance with some embodiments of the present disclosure. [Figure 8] FIG. 1 is a block diagram of another embodiment of a graphics processor including a graphics pipeline, a media pipeline, a display engine, thread execution logic, and a rendering output pipeline. [Figure 9A] FIG. 2 is a block diagram illustrating a command format for a graphics processor, according to some embodiments. [Figure 9B] FIG. 2 is a block diagram of a command sequence for a graphics processor according to some embodiments of the present disclosure. [Figure 10]FIG. 1 illustrates a graphics software architecture for a data processing system according to some embodiments of the present disclosure. [Figure 11] FIG. 1 illustrates the architecture and memory structure of a conventional OpenCL workgroup. [Figure 12] This is a chart showing the performance versus power consumption of iGPU and dGPU. [Figure 13] This is a chart showing the performance versus power consumption of iGPU and dGPU. [Figure 14A] 1 is a flowchart of a switchable graphics power management scheme, according to some embodiments. [Figure 14B] 1 is a flowchart of a switchable graphics power management scheme, according to some embodiments. [Figure 15] FIG. 1 illustrates a computer system according to some embodiments. [Figure 16] 1 illustrates a smart device or computer system or SoC (System on a Chip) in accordance with the apparatus, methods and systems of various embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0005] Existing solutions compare applications at launch with a list of applications in a driver. Based on the comparison, the driver determines which iGPU or dGPU to use for rendering the application. For example, a standard set of applications is pre-tested to determine whether they should use the dGPU for rendering by comparing the power and performance of the same applications on the iGPU, and the applications are categorized and listed in the driver accordingly. In some cases, the dynamic link library (DLL) associated with an application is pre-coded to use either the iGPU or the dGPU. Therefore, the driver and / or OS selects a GPU based on the DLL information. A user can override the driver's and / or OS's decision to select a GPU, which may involve manually changing settings.

[0006] There are many system-level factors that affect GPU performance and energy consumption. For example, different switchable graphics system designs will have different combinations of iGPUs and dGPUs from different vendors. The skew, system thermal and power envelope, and memory configuration will be unique for each design. Here, skew refers to the variation in power drawn or thermal capacity from typical or nominal values. Therefore, pre-test methods for characterizing application performance and power will be highly system-specific. Generalizing this driver / OS-based solution may not be efficient for all designs.

[0007] Pre-characterization of applications and listing them in a driver may not cover all applications and use cases. For example, it is virtually impossible to test all applications available to users before listing them in a driver. A program profile may only cover a few standard and representative applications.

[0008] Previous solutions use a lookup table-like mechanism for the driver to determine the GPU for rendering. In this type of implementation, when multiple core- and graphics-intensive applications are launched together, the system may lack a mechanism for ascertaining the overall power and performance of the GPU. Existing switchable graphics systems lack the hardware (HW) or software (SF) intelligence to use real-time system conditions (thermal, power budget, etc.) and examine the iGPU / dGPU performance / watt capabilities to determine the optimal GPU for task execution. Due to this limitation, the GPU driver cannot guarantee optimized GPU utilization for all use cases and applications. Therefore, existing approaches for drivers to determine the GPU (graphics processing unit) for rendering a task are not efficient (both in terms of energy and performance) for all use cases.

[0009] In a switchable graphics system, the power and performance of the iGPU and dGPU are unique to each system design, including the GPU's thermal design power (TDP), stock keeping units (SKUs), vendor, and / or system power and / or thermal envelope. The dGPU is known to have much higher rendering capabilities and be optimized for medium- to high-intensity applications in terms of power. Similarly, the iGPU's rendering capabilities are relatively lower than those of the dGPU, and it is optimized for low- to medium-intensity applications in terms of power. From this baseline, the iGPU is required up to a certain point (e.g., a threshold power point) where its performance is the same as that of the dGPU but with much lower power consumption. After this threshold power point, the dGPU's performance, as well as its power consumption, are higher than that of the iGPU. This threshold power point is unique to each system, as it depends on the iGPU and dGPU selected for a particular system. The threshold power point also depends on the system's memory, thermal envelope, power budget, etc.

[0010] To address the gaps associated with existing driver-based approaches, some embodiments describe a novel switchable graphics management scheme that uses performance / watt information for both the iGPU and dGPU along with system real-time resources such as the SoC (system-on-chip) thermal budget, system power budget, etc. to determine the appropriate GPU for rendering a task. The scheme of some embodiments uses this threshold power point information along with system resources to determine the optimized GPU for task rendering for all applications and use cases. As such, the scheme of various embodiments adapts to each system design based on the capabilities of that particular system, unlike existing solutions that are generalized to all systems.

[0011] Based on the iGPU and dGPU capabilities of that particular system, real-time SoC thermal limits, and system power capabilities, the algorithm can determine to select the appropriate GPU to improve system performance or energy consumption, as described in Case 1 and Case 2 below.

[0012] In Case 1 (e.g., switching a low-end graphics application to run on the dGPU to improve system performance), consider that the SoC core computation logic is processing a high-power consumption task. In this case, if a user launches a graphics application that is intended to use the internal graphics according to driver / OS instructions, then in existing switchable graphics systems, the SoC power management will throttle core processing, which corresponds to the graphics workload and includes the package TDP (thermal design power). This is a trade-off between computer performance and graphics workload. The scheme of various embodiments can keep track of such a scenario and feed this information back to the driver / OS so that the dGPU can be used to render GFX applications with low to medium workloads, allowing the SoC core to continue its computational activity without throttling (shifting) down.

[0013] In Case 2 (e.g., a similar algorithm can decide to switch an application from dGPU to iGPU rendering by evaluating graphics workload power against GPU performance / watt information), consider that the driver / OS selects the dGPU to render the application. While the application is running on the dGPU, the scheme of various embodiments obtains the real-time average power consumed by the dGPU. When comparing the GPU's pre-characterized power with the performance data, if the measured power of the dGPU is below a certain threshold power point, then the algorithm initiates a context switch from the dGPU to the iGPU for rendering, thereby reducing energy consumption with the same performance. Similarly, if multiple low-end graphics applications are using the iGPU according to an existing driver / OS decision and the resulting iGPU power is above the threshold power point, then the algorithm can also invoke when all GPU rendering needs to be switched to the dGPU, thereby improving performance.

[0014] Thus, best performance or optimal energy consumption is achieved by taking into account real-time system parameters. End users benefit in the form of improved performance or extended battery life in various use case scenarios, which are described in detail herein. Other technical advantages will be apparent from the various embodiments and figures.

[0015] In the following description, numerous details are discussed to provide a more thorough explanation of the embodiments of the present disclosure. However, it will be apparent to those skilled in the art that the embodiments of the present disclosure may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form, rather than in detail, in order to avoid obscuring the embodiments of the present disclosure.

[0016] Note that in the corresponding drawings of the embodiments, signals are represented by lines. Some lines may be thickened to indicate more constituent signal paths and / or may have arrows at one or more ends to indicate the direction of primary information flow. Such representations are not intended to be limiting. Rather, the lines are used in connection with one or more exemplary embodiments to facilitate understanding of a circuit or logic unit. As dictated by design needs or preferences, the represented signals may actually include one or more signals that may travel in either direction and be implemented with any suitable type of signaling scheme.

[0017] Throughout this specification and in the claims, the term "connected" means a direct connection, such as an electrical, mechanical, or magnetic connection, between the things connected, without any intermediate devices.

[0018] The term "coupled" means a direct or indirect connection, such as a direct electrical, mechanical, or magnetic connection between things connected, or an indirect connection through one or more passive or active intermediary devices.

[0019] The term "adjacent" as used herein generally refers to something that is next to (e.g., immediately adjacent or nearby, with one or more things between them) or a location adjacent to (e.g., adjacent to) another.

[0020] The term "circuit" or "module" may refer to one or more passive and / or active components arranged to cooperate with each other to provide a desired function.

[0021] The term "signal" may refer to at least one current signal, voltage signal, magnetic signal, or data / clock signal. The meanings of "a," "an," and "the" include plural references. The meaning of "in" includes "in" and "on."

[0022] The term "scaling" generally refers to converting a design (schematic and layout) from one process technology to another, which may result in a reduced layout area. In some cases, scaling also refers to upsizing a design from one process technology to another, which may result in an increased layout area. The term "scaling" also generally refers to downsizing or upsizing layouts and devices within the same technology node. The term "scaling" can also refer to adjusting (e.g., slowing down or speeding up—i.e., scaling down or up, respectively) another parameter, such as signal frequency relative to power supply levels.

[0023] The terms "substantially," "close," "approximately," "near," and "about" generally refer to within + / - 10% of a target value.

[0024] Unless otherwise specified, the use of ordinal adjectives such as "first," "second," and "third" to describe a common object merely indicates that different instances of a similar object are being referred to and is not intended to imply that the objects so described need be in a given order, temporally, spatially, ranked, or otherwise.

[0025] For purposes of this disclosure, the phrases "A and / or B" and "A or B" mean (A), (B), or (A and B). For purposes of this disclosure, the phrase "A, B, and / or C" means (A), (B), (C), (A and B), (A and C), (B and C), or (A, B, and C).

[0026] Terms such as "left," "right," "front," "rear," "upper," "lower," "above," "below," and the like in the detailed description and claims (if any) are used for descriptive purposes and are not necessarily used to describe permanent relative positions.

[0027] It is noted that elements of a figure having the same reference number (or name) as elements of another figure may operate or function in a similar manner as described, but are not limited to such.

[0028] For purposes of the embodiments, the transistors of the various circuit and logic blocks described herein are metal-oxide-semiconductor (MOS) transistors or their derivatives, where a MOS transistor includes a drain, a source, a gate, and a bulk terminal. Transistors and / or MOS transistor derivatives also include other devices that implement transistor functions, such as Tri-Gate and FinFET transistors, Gate All Around Cylindrical Transistors, Tunneling FETs (TFETs), Square Wire or Rectangular Ribbon Transistors, Ferroelectric FETs (FeFETs), or carbon nanotube or spintronic devices. The symmetrical source and drain terminals of a MOSFET are the same terminal and are used interchangeably herein. In contrast, TFET devices have asymmetrical source and drain terminals. Those skilled in the art will understand that other transistors, such as bipolar junction transistors (BJT PNP / NPN), BiCMOS, CMOS, etc., can be used without departing from the scope of the present disclosure.

[0029] 1 illustrates a block diagram of a data processing system 100 according to some embodiments. Data processing system 100 includes one or more processors 102 and one or more graphics processors 108 and may be a single-processor desktop system, a multi-processor workstation system, or a server system having multiple processors 102 or processor cores 107. In some embodiments, data processing system 100 is a system-on-chip integrated circuit (SoC) for use in mobile, handheld, or embedded devices.

[0030] An embodiment of data processing system 100 may include or be incorporated into a server-based gaming platform, a gaming console including a game and media console, a mobile gaming console, a handheld gaming console, or an online gaming console. In some embodiments, data processing system 100 is a mobile phone, a smartphone, a tablet computing device, or a mobile internet device. Data processing system 100 may also include, be coupled to, or be integrated into a wearable device, such as a smartwatch wearable device, a smart eyewear device, an augmented reality device, or a virtual reality device. In some embodiments, data processing system 100 is a television or set-top box device having one or more processors 102 and a graphical interface generated by one or more graphics processors 108.

[0031] In some embodiments, the one or more processors 102 each include one or more processor cores 107 for processing instructions that, when executed, perform system and user software operations. In some embodiments, each of the one or more processor cores 107 is configured to process a particular instruction set 109. The instruction set 109 may facilitate Complex Instruction Set Computing (CISC), Reduced Instruction Set Computing (RISC), or Very Long Instruction Word (VLIW) computing. Each of the multiple processor cores 107 can process a different instruction set 109, which may include instructions to facilitate emulation of other instruction sets. The processor cores 107 may also include other processing devices, such as a digital signal processor (DSP).

[0032] In some embodiments, processor 102 includes cache memory 104. Depending on the architecture, processor 102 may have a single internal cache or multiple levels of internal cache. In some embodiments, cache memory is shared among various components of processor 102. In some embodiments, processor 102 also uses an external cache (e.g., a level 3 (L3) cache or last level cache (LLC)) (not shown), which may be shared among processor cores 107 using known cache coherency techniques. Processor 102 also includes a register file 106, which may include different types of registers (e.g., integer registers, floating-point registers, status registers, and instruction pointer registers) for storing different types of data. Some registers may be general-purpose registers, while other registers may be specific to the design of processor 102.

[0033] In some embodiments, processor 102 is coupled to processor bus 110 to transmit data signals between processor 102 and other components in system 100. System 100 uses an exemplary "hub" system architecture that includes memory controller hub 116 and input / output (I / O) controller hub 130. Memory controller hub 116 facilitates communication between memory devices and other components of system 100, while I / O controller hub (ICH) 130 provides connectivity to I / O devices via a local I / O bus.

[0034] In some embodiments, memory device 120 may be a dynamic random-access memory (DRAM) device, a static random-access memory (SRAM) device, a flash memory device, or other memory device with suitable performance to function as process memory. Memory 120 may store data 122 and instructions 212 for use by processor 102 when executing processes. Memory controller hub 116 also couples to an optional external graphics processor 112, which may communicate with one or more graphics processors 108 within processor 102 to perform graphics and media operations.

[0035] The ICH 130 allows peripherals to connect to the memory 120 and the processor 102 via a high-speed I / O bus. The I / O peripherals include an audio controller 146, a firmware interface 128, a wireless transceiver 126 (e.g., Wi-Fi, Bluetooth), a data storage device 124 (e.g., a hard disk drive, flash memory, etc.), and a legacy I / O controller for coupling legacy (e.g., Personal System 2 (PS / 2)) devices to the system. One or more Universal Serial Bus (USB) controllers 142 connect input devices such as a keyboard and mouse 144 combination. A network controller 134 may also be coupled to the ICH 130. In some embodiments, a high-performance network controller (not shown) couples to the processor bus 110.

[0036] 2 shows a block diagram of an embodiment of a processor 200 having one or more processor cores 202A-N, an integrated memory controller 214, and an integrated graphics processor 208. It is noted that elements in FIG. 2 having the same reference numbers (or names) as elements in other figures may operate or function in a similar manner as described, but are not limited to such.

[0037] Processor 200 may include additional cores, up to additional core 202N, represented by dashed boxes. Each of cores 202A-N includes one or more internal cache units 204A-N. In some embodiments, each core also has access to one or more shared cache units 206.

[0038] In some embodiments, internal cache units 204A-N and shared cache unit 206 represent a cache memory hierarchy within processor 200. The cache memory hierarchy may include at least one level of instruction and data cache within each core and one or more levels of shared mid-level cache, such as a level 2 (L2), level 3 (L3), level 4 (L4), or other level cache, with the highest level cache before external memory classified as a last level cache (LLC). In some embodiments, cache coherency logic maintains coherency between the various cache units 106 and 204A-N.

[0039] In some embodiments, processor 200 may also include one or more bus controller units 216 and a set of system agents 210. The one or more bus controller units manage a set of peripheral buses, such as one or more peripheral component interconnect buses (e.g., PCI, PCI Express). In some embodiments, system agent 210 provides management functions for various processor components. In some embodiments, system agent 210 includes one or more integrated memory controllers 214 for managing access to various external memory devices (not shown).

[0040] In some embodiments, one or more of cores 202A-N include support for simultaneous multithreading. In such embodiments, system agent 210 includes components for coordinating and operating cores 202A-N during multithreaded processing. In some embodiments, system agent 210 may further include a power control unit (PCU), which includes logic and components for coordinating the power state of cores 202A-N and graphics processor 208.

[0041] In some embodiments, processor 200 further includes a graphics processor 208 for performing graphics processing operations. In some embodiments, graphics processor 208 couples to a system agent unit 210 that includes a set of shared cache units 206 and one or more integrated memory controllers 214. In some embodiments, a display controller 211 couples to graphics processor 208 to drive graphics processor output to one or more coupled displays. In some embodiments, display controller 211 may be a separate module coupled to the graphics processor via at least one interconnect, or may be integrated within graphics processor 208 or system agent 210.

[0042] In some embodiments, a ring-based interconnect unit 212 is used to couple the internal components of processor 200, although alternative interconnect units such as point-to-point interconnects, switched interconnects, or other technologies, including technologies well known in the art, can be used. In some embodiments, graphics processor 208 couples to ring interconnect 212 via I / O link 213.

[0043] The exemplary I / O link 213 represents at least one of several types of I / O interconnects, including an on-package I / O interconnect that facilitates communication between various processor components and a high-performance embedded memory module 218, such as an eDRAM module. In some embodiments, each of the cores 202-N and the graphics processor 208 uses the embedded memory module 218 as a shared last-level cache.

[0044] In some embodiments, cores 202A-N are homogeneous cores that execute the same instruction set architecture. In other embodiments, cores 202A-N are heterogeneous with respect to instruction set architecture (ISA), where one or more of cores 202A-N execute a first instruction set while at least one of the other cores executes a subset of the first instruction set or a different instruction set.

[0045] In some embodiments, processor 200 may be part of or implemented on one or more substrates using any of several process technologies, such as complementary metal-oxide semiconductor (CMOS), bipolar junction / complementary metal-oxide semiconductor (BiCMOS), or N-type metal-oxide semiconductor logic (NMOS). Additionally, processor 200 may be implemented on one or more chips or as a system-on-chip (SoC) integrated circuit having the illustrated components in addition to other components.

[0046] 3 shows a block diagram of one embodiment of a graphics processor 300, which may be a discrete graphics processing unit or may be a graphics processor integrated with multiple processing cores. It is noted that those elements in FIG. 3 that have the same reference numbers (or names) as elements in other figures may operate or function in a manner similar to that described, but are not limited to such.

[0047] In some embodiments, the graphics processor communicates with registers on the graphics processor via a memory-mapped I / O interface and via commands placed in processor memory. In some embodiments, the graphics processor 300 includes a memory interface 314 for accessing memory. In some embodiments, the memory interface 314 may be an interface to local memory, one or more internal caches, one or more shared external caches, and / or system memory.

[0048] In some embodiments, graphics processor 300 also includes a display controller 302 for driving display output data to a display device 320. In some embodiments, display controller 302 includes hardware for one or more overlay planes for displaying and composing multiple layers of video or user interface elements. In some embodiments, graphics processor 300 includes a video codec engine 306 that encodes, decodes, or transcodes media to, from, or between one or more media decoding formats, including, but not limited to, Moving Picture Experts Group (MEPG) formats such as MPEG-2, Advanced Video Coding (AVC) formats such as H.264 / MPEG-4 AVC, Society of Motion Picture & Television Engineers (SMPTE) 421M / VC-1, Joint Photographic Experts Group (JPEG) formats such as JPEG, Motion JPEG (MJPEG) formats, etc.

[0049] In some embodiments, graphics processor 300 includes a block image transfer (BLIT) engine 304 for performing two-dimensional (2D) rasterizer operations, including, for example, bit-boundary block transfer. In some embodiments, 2D graphics operations are performed using one or more components of a graphics processing engine (GPE) 310. In some embodiments, GPE 310 is a computation engine for performing graphics operations, including three-dimensional (3D) graphics operations and media operations, etc.

[0050] In some embodiments, GPE 310 includes a 3D pipeline 312 for performing 3D operations such as rendering three-dimensional images and scenes using processing functions that operate on 3D primitive shapes (e.g., rectangles, triangles, etc.). In some embodiments, 3D pipeline 312 includes programmable and fixed function elements that perform various tasks within the elements and / or spawn execution threads into 3D / media subsystem 315. While 3D pipeline 312 may be used to perform media operations, embodiments of GPE 310 also include a media pipeline 316 that is specifically used to perform media operations such as video post-processing and image enhancement.

[0051] In some embodiments, the media pipeline 316 includes a fixed function or programmable logic unit for performing one or more specialized media operations, such as video decode acceleration, video deinterlacing, and video encode acceleration, instead of or on behalf of the video codec engine 306. In some embodiments, the media pipeline 316 further includes a thread spawning unit for spawning threads for execution in the 3D / media subsystem 315. The spawned threads perform computations for the media operations on one or more graphics execution units included in the 3D / media subsystem 315.

[0052] In some embodiments, the 3D / media subsystem 315 includes logic for executing threads created by the 3D pipeline 312 and the media pipeline 316. In some embodiments, the pipelines send thread execution requests to the 3D / media subsystem 315, which includes thread dispatch logic that arbitrates the various requests and dispatches them to available thread execution resources. The execution resources include an array of graphics execution units for processing the 3D and media threads. In some embodiments, the 3D / media subsystem 315 includes one or more internal caches for thread instructions and data. In some embodiments, the subsystem also includes shared memory, including registers and addressable memory, for sharing data between threads and storing output data.

[0053] Figure 4 shows a block diagram of an embodiment of a GPE 510 for a graphics processor. It is noted that elements in Figure 4 having the same reference numbers (or names) as elements in other figures can operate or function in a similar manner as described, but are not limited to such.

[0054] In some embodiments, GPE 510 is a version of GPE 310 described with respect to Figure 3. Returning to Figure 4, in some embodiments, GPE 410 includes a 3D pipeline 412 and a media pipeline 416, which may be different from or similar to the implementations of 3D pipeline 312 and media pipeline 316, respectively, of Figure 3.

[0055] Returning to FIG. 4 , in some embodiments, the GPE 510 couples to a command streamer 403 that provides a command stream to the GPE 3D and media pipelines 412, 416. In some embodiments, the command streamer 403 is coupled to memory, which may be system memory or one or more internal and shared cache memories. In some embodiments, the command streamer 403 receives commands from memory and sends the commands to the 3D pipeline 412 and / or the media pipeline 416. The 3D and media pipelines process the commands by performing operations through logic within the respective pipelines or by dispatching one or more execution threads to the execution unit array 414. In some embodiments, the execution unit array 414 is scalable, whereby the array includes a variable number of execution units based on the target power and performance levels of the GPE 410.

[0056] In some embodiments, the sampling engine 430 couples to memory (e.g., cache memory or system memory) and the execution unit array 414. In some embodiments, the sampling engine 430 provides a memory access mechanism for the scalable execution unit array 414 that allows the execution array 414 to read graphics and media data from memory. In some embodiments, the sampling engine 430 includes logic for performing specialized image sampling operations on the media.

[0057] In some embodiments, specialized media sampling logic in the sampling engine 430 includes a denoising / deinterlacing module 432, a motion estimation module 434, and an image scaling and filtering module 436. In some embodiments, the denoising / deinterlacing module 432 includes logic for performing one or more denoising or deinterlacing algorithms on the decoded video data. The deinterlacing logic combines alternating fields of interlaced video content into a single video frame. The denoising logic reduces or removes data noise from the video and image data. In some embodiments, the denoising and deinterlacing logic are motion adaptive and use spatial or temporal filtering based on the amount of motion detected in the video data. In some embodiments, the denoising / deinterlacing module 432 includes dedicated motion detection logic (e.g., within the motion estimation engine 434).

[0058] In some embodiments, the motion estimation engine 434 provides hardware acceleration for video operations by performing video acceleration functions such as motion vector estimation and prediction on video data. The motion estimation engine determines motion vectors that represent transformations of image data between successive video frames. In some embodiments, a graphics processor media codec uses the video motion estimation engine 434 to perform operations on video at the macroblock level, a level that may otherwise be computationally intensive to perform using a general-purpose processor. In some embodiments, the motion estimation engine 434 is generally available to the graphics processor component to support video decoding and processing functions that are sensitive to or adaptive to the direction or magnitude of motion in the video data.

[0059] In some embodiments, the image scaling and filtering module 436 performs image processing operations to improve the visual quality of the generated images and videos. In some embodiments, the scaling and filtering module 436 processes the image and video data during sampling operations before providing the data to the execution unit array 414.

[0060] In some embodiments, the GPE 510 includes a data port 444 that provides an additional mechanism for the graphics subsystem to access memory. In some embodiments, the data port 444 facilitates memory access for operations including render target writes, constant buffer reads, scratch memory space reads / writes, and media surface accesses. In some embodiments, the data port 444 includes a cache memory space for caching accesses to memory. The cache memory can be a single data cache or can be divided into multiple caches (e.g., a render buffer cache, a constant buffer cache, etc.) for multiple subsystems that access memory through the data port. In some embodiments, threads executing on execution units in the execution unit array 414 communicate with the data port by exchanging messages over a data distribution interconnect that couples each subsystem of the GPE 410.

[0061] Figure 5 shows a block diagram 500 of another embodiment of a graphics processor associated with an execution unit. It is noted that elements in Figure 5 having the same reference numbers (or names) as elements in other figures may operate or function in a similar manner as described, but are not limited to such.

[0062] In some embodiments, the graphics processor includes a ring interconnect 502, a pipeline front end 504, a media engine 537, and graphics cores 580A-N. In some embodiments, the ring interconnect 502 couples the graphics processor to other processing units, including other graphics processors or one or more general-purpose processor cores. In some embodiments, the graphics processor is one of many processors integrated within a multi-core processing system.

[0063] In some embodiments, the graphics processor receives batches of commands via ring interconnect 502. The incoming commands are interpreted by command streamer 503 in pipeline front end 504. The graphics processor includes scalable execution logic for performing 3D geometry processing and media processing via graphics cores 580A-N. For 3D geometry processing commands, command streamer 503 supplies the commands to geometry pipeline 536. For at least some media processing commands, command streamer 503 supplies the commands to video front end 534, which couples with media engine 537. In some embodiments, media engine 537 includes a video quality engine (VQE) 530 for video and image post-processing and a multi-format encoding / decoding (MFX) 533 engine that provides hardware-accelerated encoding and decoding of media data. In some embodiments, geometry pipeline 536 and media engine 537 each spawn execution threads for thread execution resources provided by at least one graphics core 580A.

[0064] The graphics processor includes scalable thread execution resources characterized by modular cores 580A-N (sometimes referred to as core slices), each having multiple sub-cores 550A-N, 560A-N (sometimes referred to as core sub-slices). The graphics processor can have any number of graphics cores 580A-N. In some embodiments, the graphics processor includes at least a graphics core 580A having a first sub-core 550A and a second sub-core 560A. In another embodiment, the graphics processor is a low-power processor including a single sub-core (e.g., 550A). In some embodiments, the graphics processor includes multiple graphics cores 580A-N, each including a set of first sub-cores 550A-N and a set of second sub-cores 560A-N. Each sub-core in the set of first sub-cores 550A-N includes at least a first set of execution units 552A-N and media / texture samplers 554A-N. Each sub-core in the set of second sub-cores 560A-N includes at least a second set of execution units 562A-N and samplers 564A-N. In some embodiments, each sub-core 550A-N, 560A-N shares a set of shared resources 570A-N. In some embodiments, the shared resources include shared cache memory and pixel manipulation logic. Other shared resources may also be included in various embodiments of the graphics processor.

[0065] Figure 6 illustrates thread execution logic 600, including an array of processing elements, for use in one embodiment of a graphics processing engine. It is noted that elements in Figure 6 that have the same reference numbers (or names) as elements in other figures may operate or function in a similar manner as described, but are not limited to such.

[0066] In some embodiments, thread execution logic 600 includes a pixel shader 602, a thread dispatcher 604, an instruction cache 606, a scalable execution unit array including multiple execution units 608A-N, a sampler 610, a data cache 612, and a data port 614. In some embodiments, the included components are interconnected via an interconnect fabric that links each component. In some embodiments, thread execution logic 600 includes one or more connections to memory, such as system memory or cache memory, via one or more of the instruction cache 606, the data port 614, the sampler 610, and the execution unit array 608A-N. In some embodiments, each execution unit (e.g., 608A) is an individual vector processor capable of executing multiple simultaneous threads and processing multiple data elements in parallel per thread. In some embodiments, execution unit array 608A-N includes any number of individual execution units.

[0067] In some embodiments, the execution unit arrays 608A-N are primarily used to execute "shader" programs. In some embodiments, the execution units in the arrays 608A-N execute an instruction set that includes native support for many standard 3D graphics shader instructions, so that shader programs from graphics libraries (e.g., Direct3D and OpenGL) run with minimal translation. The execution units support vertex and geometry processing (e.g., vertex programs, geometry programs, vertex shaders), pixel processing (e.g., pixel shaders, fragment shaders), and general-purpose processing (e.g., compute shaders, media shaders).

[0068] Each execution unit in the execution unit array 608A-N operates on an array of data elements. The number of data elements is the "execution size," or the number of channels for the instruction. An execution channel is a logical unit of execution for accessing, masking, and flow control of data elements within an instruction. The number of channels is independent of the number of physical arithmetic logic units (ALUs) or floating-point units (FPUs) in a particular graphics processor. In some embodiments, the execution units 608A-N support integer and floating-point data types.

[0069] The execution unit instruction set includes single instruction, multiple data (SIMD) instructions. Various data elements can be stored in registers as packed data types, and the execution unit processes the various elements based on the data size of the elements. For example, when operating on a 256-bit wide vector, the 256 bits of the vector are stored in a register, and the execution unit operates on the vector as four individual 64-bit packed data elements (quadword (QW) sized data elements), eight individual 32-bit packed data elements (doubleword (DW) sized data elements), sixteen individual 16-bit packed data elements (word (W) sized data elements), or thirty-two individual 8-bit data elements (byte (B) sized data elements). However, different vector widths and register sizes are possible.

[0070] One or more internal instruction caches (e.g., 606) are included in the thread execution logic 600 for caching thread instructions for the execution units. In some embodiments, one or more data caches (e.g., 612) are included for caching thread data during thread execution. In some embodiments, a sampler 610 is included to provide texture sampling for 3D operations and media sampling for media operations. In some embodiments, the sampler 610 includes specialized texture or media sampling functions for processing texture or media data during the sampling process before providing the sampled data to the execution units.

[0071] During execution, the graphics and media pipelines send thread start requests to thread execution logic 600 via thread spawning and dispatch logic. In some embodiments, thread execution logic 600 includes a local thread dispatcher 604 that arbitrates thread start requests from the graphics and media pipelines and instantiates the requested threads on one or more execution units 608A-N. For example, the geometry pipeline (e.g., 536 in FIG. 5) dispatches vertex processing, tessellation, or geometry processing threads to thread execution logic 600. Returning to FIG. 6, in some embodiments, thread dispatcher 604 can also handle runtime thread generating requests from executing shader programs.

[0072] Once a group of geometric objects has been processed and rasterized into pixel data, a pixel shader 602 is invoked to further compute output information and write the results to an output surface (e.g., a color buffer, depth buffer, stencil buffer, etc.). In some embodiments, the pixel shader 602 computes values ​​for various vertex attributes that are interpolated across the rasterized object. In some embodiments, the pixel shader 602 then executes an API-provided pixel shader program. To execute the pixel shader program, the pixel shader 602 dispatches threads to execution units (e.g., 608A) via the thread dispatcher 604. In some embodiments, the pixel shader 602 uses texture sampling logic in the sampler 610 to access texture data in texture maps stored in memory. Arithmetic operations on the texture data and input geometry data either compute pixel color data for each geometry fragment or discard one or more pixels from further processing.

[0073] In some embodiments, data port 614 provides a memory access mechanism for thread execution logic 600 to output processed data to memory for processing in the graphics processor output pipeline. In some embodiments, data port 614 includes or couples to one or more cache memories (e.g., data cache 612) to cache data for memory access via the data port.

[0074] Figure 7 shows a block diagram illustrating a graphics processor execution unit instruction format 700 according to some embodiments of the present disclosure. In some embodiments, the graphics processor execution unit supports an instruction set that includes instructions in multiple formats. Solid boxes indicate components that are typically included in execution unit instructions, while dashed lines include components that are optional or included in only a subset of the instructions. The instruction format 700 illustrated is a macro-instruction in that it is an instruction that is supplied to an execution unit, as opposed to a micro-operation that results from instruction decoding after the instruction has been processed.

[0075] In some embodiments, the graphics processor execution units natively support instructions in 128-bit format 710. A 64-bit compacted instruction format 730 is available for some instructions based on the selected instruction, instruction options, and number of operands. The native 128-bit format 710 provides access to all instruction options, but some options and operations are restricted to the 64-bit format 730. The native instructions available in the 64-bit format 730 vary depending on the embodiment. In some embodiments, the instructions are partially compressed using a set of index values ​​in index field 713. The execution unit hardware looks up a set of compression tables based on the index values ​​and uses the compression table outputs to reconstruct the native instructions into the 128-bit format 710.

[0076] For each format, the instruction opcode 712 specifies the operation the execution unit performs. The execution unit executes each instruction in parallel across multiple data elements of each operand. For example, in response to an add instruction, the execution unit simultaneously performs an add operation across each color channel representing a texture or picture element. By default, the execution unit executes each instruction across all data channels of an operand. In some embodiments, the instruction control field 712 allows control of certain execution options, such as channel selection (e.g., conditional execution control (predication)) and data channel order (e.g., swizzle). For 128-bit instructions 710, the execution size field 716 limits the number of data channels that are executed in parallel. In some embodiments, the execution size field 716 is not available for use with the 64-bit compressed instruction format 730.

[0077] Some execution unit instructions have up to three operands, including two source (src) operands, src0 722 and src1 722, and one destination 718. In some embodiments, the execution units support dual-destination instructions, where one of the destinations is implicit. Data manipulation instructions may have a third source operand (e.g., SRC2 724), in which case the instruction opcode JJ12 determines the number of source operands. The last source operand of an instruction may be an immediate (e.g., hard-coded) value passed with the instruction.

[0078] In some embodiments, instructions are grouped based on opcode bit fields to simplify opcode decoding 740. In the case of 8-bit opcodes, bits 4, 5, and 6 allow the execution unit to determine the type of opcode. The exact opcode grouping shown is merely an example. In some embodiments, the move and logic opcode group 742 includes data movement and logic instructions (e.g., move (mov), compare (cmp)). In some embodiments, the move and logic group 742 share five most significant bits (MSBs), where move (mov) instructions are of the form 000000xxxxb (e.g., 0x0x) and logic instructions are of the form 0001xxxxb (e.g., 0x01). The flow control instruction group 744 (e.g., call, jump (jmp), etc.) includes instructions of the form 0010xxxxb (e.g., 0x20). The miscellaneous instruction group 746 contains a mix of instructions, including synchronization instructions (e.g., wait, send) in the format of 0111xxxxb (e.g., 0x30). The parallel math instruction group 748 contains component-wise arithmetic instructions (e.g., add, multiply (mul)) in the format of 0100xxxxb (e.g., 0x40). The parallel math group 748 performs arithmetic operations in parallel across data channels. The vector math group 750 contains arithmetic instructions (e.g., dp4) in the format of 0101xxxxb (e.g., 0x50). The vector math group performs arithmetic operations such as calculating dot products of vector operands.

[0079] Figure 8 is a block diagram 800 of another embodiment of a graphics processor including a graphics pipeline 820, a media pipeline 830, a display engine 840, thread execution logic 850, and a rendering output pipeline 870. It is noted that elements in Figure 8 having the same reference numbers (or names) as elements in other figures can operate or function in a similar manner as described, but are not limited to such.

[0080] In some embodiments, the graphics processor is a graphics processor in a multi-core processing system that includes one or more general-purpose processing cores. The graphics processor is controlled by register writes to one or more control registers (not shown) or via commands issued to the graphics processor via a ring interconnect 802. In some embodiments, the ring interconnect 802 couples the graphics processor to other processing components, such as other graphics processors or general-purpose processors. Commands from the ring interconnect 802 are interpreted by a command streamer 803, which provides instructions to individual components of the graphics pipeline 820 or media pipeline 830.

[0081] In some embodiments, command streamer 803 directs the operation of a vertex fetcher 805 component, which reads vertex data from memory and executes vertex processing commands provided by command streamer 803. In some embodiments, vertex fetcher 805 provides the vertex data to vertex shader 807, which performs coordinate space transformations and lighting operations on each vertex. In some embodiments, vertex fetcher 805 and vertex shader 807 execute vertex processing instructions by dispatching execution threads to execution units 852A, 852B via thread dispatcher 831.

[0082] In some embodiments, the execution units 852A, 852B are arrays of vector processors with instruction sets for performing graphics and media operations. In some embodiments, the execution units 852A, 852B have an associated L1 cache 851 that is local to each array or shared between the arrays. The cache can be configured as a data cache, an instruction cache, or a single cache partitioned to contain data and instructions in different partitions.

[0083] In some embodiments, graphics pipeline 820 includes a tessellation component for performing hardware-accelerated tessellation of 3D objects. Programmable hull shader 811 configures the tessellation operations. Programmable domain shader 817 provides back-end evaluation of the tessellation output. Tessellator 813 operates in the direction of hull shader 811 and includes special-purpose logic for generating a set of detailed geometric objects based on a coarse geometric model provided as input to graphics pipeline 820. In some embodiments, tessellation components 811, 813, and 817 can be bypassed if tessellation is not used.

[0084] In some embodiments, a complete geometric object may be processed by the geometry shader 819 via one or more threads dispatched to the execution units 852A, 852B, or may proceed directly to the clipper 829. In some embodiments, the geometry shader 819 operates on entire geometric objects, rather than vertices or patches of vertices as in earlier stages of the graphics pipeline. The geometry shader 819 receives input from the vertex shader 807 when tessellation is disabled. In some embodiments, the geometry shader 819 is programmable by a geometry shader program to perform geometry tessellation when the tessellation unit is disabled.

[0085] Before rasterization, the vertex data is processed by a clipper 829, which is either a fixed-function clipper or a programmable clipper with clipping and geometry shader functionality. In some embodiments, a rasterizer 873 in the rendering output pipeline 870 dispatches pixel shaders to convert geometric objects into their per-pixel representations. In some embodiments, pixel shader logic is included in the thread execution logic 850.

[0086] The graphics engine has an interconnect bus, interconnect fabric, or some other interconnect mechanism that allows data and messages to be passed between the major components of the graphics engine. In some embodiments, execution units 852A, 852B and associated caches 851, texture and media sampler 854, and texture / sampler cache 858 are interconnected via data port 856 to perform memory accesses and communicate with the rendering output pipeline components of the graphics engine. In some embodiments, sampler 854, caches 851, 858, and execution units 852A, 852B each have a separate memory access path.

[0087] In some embodiments, the render output pipeline 870 includes a rasterizer and depth test component 873 that converts vertex-based objects into their associated pixel-based representations. In some embodiments, the rasterizer logic includes a windower / masker unit for performing fixed-function triangle and line rasterization. In one embodiment, associated render and depth buffer caches 878, 879 are also available. In some embodiments, a pixel operations component 877 performs pixel-based operations on the data, although in some cases pixel operations related to 2D operations (e.g., bit-block image transfer with blending) are performed by the 2D engine 841 or are replaced at display time by the display controller 843 using an overlay display surface. In some embodiments, a shared L3 cache 875 is available to all graphics components, which allows data sharing without using main system memory.

[0088] In some embodiments, graphics processor media pipeline 830 includes a media engine 837 and a video front end 834. In some embodiments, video front end 834 receives pipeline commands from command streamer 803. In some embodiments, media pipeline 830 includes a separate command streamer. In some embodiments, video front end 834 processes media commands before sending the commands to media engine 837. In some embodiments, the media engine includes a thread spawning function that spawns threads for dispatch to thread execution logic 850 via thread dispatcher 831.

[0089] In some embodiments, the graphics engine includes a display engine 840. In some embodiments, the display engine 840 is external to the graphics processor and couples to the graphics processor via a ring interconnect 802 or some other interconnect bus or fabric. In some embodiments, the display engine 840 includes a 2D engine 841 and a display controller 843. In some embodiments, the display engine 840 includes special purpose logic that can operate independently of the 3D pipeline. In some embodiments, the display controller 843 couples to a display device (not shown), which may be a system-integrated display device, such as a laptop computer, or an external display device attached via a display device connector.

[0090] In some embodiments, the graphics pipeline 820 and media pipeline 830 are configurable to perform operations based on multiple graphics and media programming interfaces and are not specific to any one application programming interface (API). In some embodiments, driver software for the graphics processor translates API calls specific to a particular graphics or media library into commands that can be processed by the graphics processor. In various embodiments, support is provided for the Open Graphics Library (OpenGL) and Open Computing Language (OpenCL) supported by the Khronos Group, Microsoft's Direct3D library, or, in one embodiment, both OpenGL and D3D. Support for the Open Source Computer Vision Library (OpenCV) may also be provided. Future APIs with compatible 3D pipelines are also supported if a mapping from the future API's pipeline to the graphics processor's pipeline can be created.

[0091] Figure 9A shows a block diagram illustrating a command format 900 for a graphics processor according to some embodiments, and Figure 9B shows a block diagram of a command sequence 910 for a graphics processor according to some embodiments of the present disclosure. It is noted that elements in Figures 9A-9B that have the same reference numbers (or names) as elements in other figures can operate or function in a similar manner as described, but are not limited to such.

[0092] The solid-lined boxes in Figure 9A indicate components typically included in graphics commands, while the dashed lines include components that are optional or included in only a subset of graphics commands. The example graphics processor command format 900 of Figure 9A includes data fields for identifying the target client 902 of the command, the command operation code (opcode) 904, and data associated with the command 906. In some embodiments, a sub-opcode 905 and a command size 908 are also included in some commands.

[0093] In some embodiments, client 902 specifies a client unit of the graphics device that will process the command data. In some embodiments, a command parser in the graphics processor examines the client field of each command to condition further processing of the command and route the command data to the appropriate client unit. In some embodiments, the client units of the graphics processor include a memory interface unit, a rendering unit, a 2D unit, a 3D unit, and a media unit. Each client unit has a corresponding processing pipeline that processes commands. When a command is received by a client unit, the client unit reads the opcode 904 and, if present, the sub-opcode 905 to determine the operation to perform. The client unit executes the command using information in the data 906 field of the command. Some commands are expected to specify the size of the command via an explicit command size 908. In some embodiments, the command parser automatically determines the size of at least some commands based on the command opcode. In some embodiments, commands are aligned via double-word multiples.

[0094] In some embodiments, the flowchart in FIG. 9B illustrates a sample command sequence 910. While the blocks of flowchart 910 are shown in a particular order, the order of operations can be changed. Thus, the illustrated embodiments can be performed in a different order, and some actions / blocks can be performed in parallel. Some of the listed blocks and / or operations are optional, according to certain embodiments. The presented block numbers are for clarity and are not intended to dictate the order of operations in which the various blocks must occur. Furthermore, operations from the various flows can be utilized in various combinations.

[0095] In some embodiments, software or firmware of a data processing system featuring an embodiment of a graphics processor uses versions of the command sequences shown to set up, execute, and terminate a set of graphics operations. While a sample command sequence is shown and described for illustrative purposes, embodiments are not limited to these commands or this command sequence. Furthermore, commands may be issued as a batch of commands within a command sequence such that the graphics processor processes the sequence of commands in an at least partially concurrent manner.

[0096] In some embodiments, the sample command sequence 910 begins with a pipeline flush command 912, causing any active graphics pipelines to complete commands currently pending for that pipeline. In some embodiments, the 3D pipeline 922 and the media pipeline 924 do not operate simultaneously. A pipeline flush is executed, causing the active graphics pipelines to complete pending commands. In some embodiments, in response to the pipeline flush, the graphics processor's command parser pauses command processing until the active drawing engines complete pending operations and the associated read caches are invalidated. Optionally, data in the rendering cache that is marked "dirty" may be flushed to memory. In some embodiments, the pipeline flush command 912 may be used for pipeline synchronization or before placing the graphics processor in a low-power state.

[0097] In some embodiments, the pipeline select command 913 is used when a command sequence requires the graphics processor to explicitly switch pipelines. In some embodiments, the pipeline select command 913 is only needed once within an execution context before issuing a pipeline command, unless the context is to issue commands to both pipelines. In some embodiments, a pipeline flush command 912 is needed immediately before a pipeline switch via the pipeline select command 913.

[0098] In some embodiments, pipeline control commands 914 are used to configure the graphics pipeline for operation and to program the 3D pipeline 922 and the media pipeline 924. In some embodiments, pipeline control commands 914 configure the pipeline state of the active pipeline. In some embodiments, pipeline control commands 914 are used for pipeline synchronization and to clear data from one or more cache memories in the active pipeline before processing a batch of commands.

[0099] The return buffer state command 916 is used to configure a set of return buffers for each pipeline to write data to. Some pipeline operations require the allocation, selection, or configuration of one or more return buffers to which the operation writes intermediate data during processing. The graphics processor uses one or more return buffers to store output data and also to perform cross-thread communication. In some embodiments, the return buffer state 916 includes selecting the size and number of return buffers to use for a set of pipeline operations.

[0100] The remaining commands in the command sequence differ based on the active pipeline for the operation. Based on the pipeline decision 920, the command sequence is tailored to either the 3D pipeline 922, starting with a 3D pipeline state 930, or the media pipeline 924, starting with a media pipeline state 940.

[0101] The 3D pipeline state 930 commands include 3D state setting commands for vertex buffer states, vertex element states, certain color states, depth buffer states, and other state variables that should be configured before processing 3D primitive commands. The values ​​of these commands are determined at least in part based on the particular 3D API in use. In some embodiments, the 3D pipeline state 930 commands can also selectively disable or bypass certain pipeline elements if those elements are not used.

[0102] In some embodiments, 3D primitive 932 commands are used to submit 3D primitives to be processed by the 3D pipeline. Commands and associated parameters passed to the graphics processor via 3D primitive 932 commands are forwarded to the graphics pipeline's vertex fetch function. The vertex fetch function uses the 3D primitive 932 command data to generate vertex data structures. The vertex data structures are stored in one or more return buffers. In some embodiments, 3D primitive 932 commands are used to perform vertex operations on 3D primitives via vertex shaders. To process vertex shaders, 3D pipeline 922 dispatches shader execution threads to the graphics processor's execution units.

[0103] In some embodiments, the 3D pipeline 922 is triggered via an execute 934 command or event. In some embodiments, a register write triggers command execution. In some embodiments, execution is triggered via a "go" or "kick" command in a command sequence. In one embodiment, command execution is triggered using a pipeline synchronization command to flush the command sequence through the graphics pipeline. The 3D pipeline performs geometry processing of 3D primitives. Once the operations are complete, the resulting geometric objects are rasterized and a pixel engine colors the resulting pixels. Additional commands that control pixel shading and pixel backend operations may also be included in these operations.

[0104] In some embodiments, the sample command sequence 910 follows the path of the media pipeline 924 as it performs media operations. In general, the specific use and manner of programming the media pipeline 924 depends on the media or computational operations to be performed. Certain media decoding operations may be offloaded to the media pipeline during media decoding. The media pipeline may also be bypassed, and media decoding may be performed in whole or in part using resources provided by one or more general-purpose processing cores. In some embodiments, the media pipeline also includes elements for general-purpose graphics processing unit (GPGPU) operation, where the graphics processor is used to perform SIMD vector operations using computational shader programs not explicitly related to rendering graphics primitives.

[0105] In some embodiments, the media pipeline 924 is configured in a similar manner to the 3D pipeline 922. A set of media pipeline state commands 940 is dispatched or placed in a command queue before the media object commands 942. In some embodiments, the media pipeline state commands 940 contain data for configuring the media pipeline elements used to process the media objects. This includes data for configuring the video decoding and video encoding logic in the media pipeline, such as encoding or decoding formats. In some embodiments, the media pipeline state commands 940 also support the use of one or more pointers to "indirect" state elements that contain a batch of state settings.

[0106] In some embodiments, the media object command 942 provides a pointer to a media object for processing by the media pipeline. The media object includes a memory buffer containing video data to be processed. In some embodiments, all media pipeline state must be valid before issuing the media object command 942. Once the pipeline state is configured and the media object command 942 is queued, the media pipeline 924 is triggered via an execute 934 command or an equivalent execute event (e.g., a register write). The output from the media pipeline 924 can then be post-processed by operations provided by the 3D pipeline 922 or the media pipeline 924. In some embodiments, GPGPU operations are configured and executed in a similar manner to media operations.

[0107] Figure 10 illustrates a graphics software architecture 1000 for a data processing system according to some embodiments of the present disclosure. It is noted that elements in Figure 10 having the same reference numbers (or names) as elements in other figures may operate or function in a manner similar to that described, but are not limited to such.

[0108] In some embodiments, the software architecture includes a 3D graphics application 1010, an operating system 1020, and at least one processor 1030. In some embodiments, the processor 1030 includes a graphics processor 1032 and one or more general-purpose processor cores 1034. In some embodiments, the graphics application 1010 and the operating system 1020 each execute within system memory 1050 of the data processing system.

[0109] In some embodiments, the 3D graphics application 1010 includes one or more shader programs that include shader instructions 1012. The shader language instructions may be in a high-level shader language, such as High Level Shader Language (HLSL) or OpenGL Shader Language (GLSL). The application also includes executable instructions 1014 in a machine language suitable for execution by the general-purpose processor core 1034. The application also includes graphics objects 1016 defined by vertex data.

[0110] In some embodiments, operating system 1020 may be one of Microsoft's Microsoft® Windows® operating systems, a proprietary UNIX®-like operating system, or an open-source UNIX®-like operating system that uses a variant of the Linux® kernel. When the Direct3D API is used, operating system 1020 uses a front-end shader compiler 1024 to compile HLSL shader instructions 1012 into a low-level shader language. Compilation may be just-in-time compilation, or the application may perform shared ahead-of-time compilation. In one embodiment, high-level shaders are compiled into low-level shaders during compilation of 3D graphics application 1010.

[0111] In some embodiments, user mode graphics driver 1026 may include a back-end shader compiler 1027 for converting shader instructions 1012 into a hardware-specific representation. When the OpenGL API is used, shader instructions 1012 in the GLSL high-level language are passed to user mode graphics driver 1026 for compilation. In some embodiments, user mode graphics driver 1026 communicates with kernel mode graphics driver 1029 using kernel mode functions 1028 of the operating system. In some embodiments, kernel mode graphics driver 1029 communicates with graphics processor 1032 to dispatch commands and instructions.

[0112] To the extent various operations or functions are described herein, they may be described or defined as hardware circuits, software code, instructions, configurations, and / or data. Content may be embodied in hardware logic, directly executable software ("object" or "executable" format), source code, high-level shader code designed to run on a graphics engine, or low-level assembly language code within the instruction set of a particular processor or graphics core. The software content of the embodiments described herein may be provided via a product storing the content or via a method of operating a communications interface to transmit data through the communications interface.

[0113] A non-transitory machine-readable storage medium can cause a machine to perform the described functions or operations and includes any mechanism that stores information in a form accessible by a machine (e.g., a computing device, an electronic system, etc.), such as recordable / non-recordable media (e.g., read-only memory (ROM), random-access memory (RAM), magnetic disk storage media, optical storage media, flash memory devices, etc.). A communication interface includes any mechanism that interfaces to either a wired, wireless, optical, etc. medium for communicating with another device, such as a memory bus interface, a processor bus interface, an Internet connection, a disk controller, etc. A communication interface is configured by providing configuration parameters or sending signals, preparing the communication interface to provide data signals describing software content. A communication interface can be accessed via one or more commands or signals sent to the communication interface.

[0114] The various components described may be means for performing the described operations or functions. Each component described herein includes software, hardware, or a combination thereof. Components may be implemented as software modules, hardware modules, dedicated hardware (e.g., application-specific hardware, application-specific integrated circuits (ASICs), digital signal processors (DSPs), etc.), embedded controllers, hardwired circuits, etc. In addition to what is described herein, various modifications can be made to the disclosed embodiments and implementations of the present invention without departing from the scope thereof. Therefore, the illustrations and examples herein should be construed in an illustrative, rather than a limiting, sense. The scope of the present disclosure should be considered solely by reference to the claims that follow.

[0115] 11 illustrates a conventional OpenCL workgroup and memory structure architecture 1100. Architecture 1100 is a simplified architecture showing system global memory (SGM) 1101 and shared memories 1102-1 through 1103-N. SGM 1101 may be memory managed by a general processing unit, where each shared memory is associated with a single workgroup having one or more work items.

[0116] In a traditional OpenCL memory structure, workgroups share their own shared local memory (SLM). A workgroup consists of a defined number of work items. These work items are executed by execution units. The memory space within a workgroup is an SLM. Architecture 1100 illustrates "N" workgroups (e.g., workgroups 1102-1 through 1102-N) and corresponding "N" SLMs (e.g., SLMs 206-1 through 206-N).

[0117] In architecture 1100, the results of computations by each work item (e.g., 1101-1A-1101-1N) are collected and stored in an SLM (e.g., 206-1), and then one or more work items (e.g., 1102-1) in a workgroup are responsible for writing the data from the SLM (e.g., 206-1) to a global system memory (SGM) 218 ​​via a bus (e.g., a double data rate (DDR) compliant bus specified by the Joint Electron Device Engineering Council (JEDEC) Solid State Technology Association). Because there are many atomic operations, writing from an SLM (e.g., 1102-1) to SGM 1101 can take time. The performance degradation of atomic operations is exacerbated, especially when there are multiple processors or multiple devices.

[0118] As mentioned above, the Threshold Power Point (TPP) is unique for each switchable graphics system. The TPP is the crossover point, above which the dGPU performance improves significantly, and below which the iGPU performance is the same as the dGPU but consumes less energy. Below we present lab data where the GPU power / performance on a switchable graphics system (KBL-G) is recorded by running a set of applications ranging from low to high loads on the iGPU, and confirms that the same is repeated on the dGPU.

[0119] Figure 12 shows a chart 1200 illustrating the performance versus power consumption of an iGPU and a dGPU. Figure 13 shows a chart 1300 illustrating the performance versus power consumption of an iGPU and a dGPU.

[0120] Both of these graphs in Figures 12 and 13 show a comparison of power and performance for the iGPU and dGPU used to render different applications ranging from low to high power. The vertical dotted bars represent the iGPU performance score 1201 and the dGPU performance score 1202. The solid bars represent the iGPU power 1203 and the dGPU power 1204. Based on this data, there exists a threshold power point (TPP) of 11 W (the horizontal dotted line in the graph in Figure 12), below which the iGPU performance score 1201 is the same as the dGPU performance score 1202, but at much lower power (the 11 applications from left to right in the graph in Figure 12). In this case, when rendering an application, if the GPU consumes less than the average power of 11 W, then running the application on the iGPU can reduce energy consumption without compromising performance. Conversely, when the GPU power consumption (shown as iGPU power 1203 and dGPU power 1204) is higher than 11 W (e.g., applications 12 and 13 in the graph of FIG. 12 and all applications in the graph of FIG. 13), performance improves by using the dGPU to render all tasks. This threshold power point is unique to each system, as it depends on the iGPU and dGPU selected for a particular system, as well as on system memory, thermal envelope, power budget, etc. Note that the 11 W threshold power point (TPP) is merely an example, and other values ​​for the TPP will be determined based on the particular system.

[0121] The benefits of switchable graphics management of various embodiments over existing driver / OS-based GPU selection are evident in the graphs of Figure 12, which show that for the three applications in the first graph (e.g., Galaxy Control, Sniper Fury, and Battle of War Planes), existing driver / OS-based implementations select the dGPU for rendering, but using the iGPU for rendering these applications results in the same performance but significantly lower energy. For example, for the Galaxy Control application, the dGPU achieves a performance score of 61 at an average power consumption of approximately 6W, while the iGPU achieves the same performance score of 61 at an average power consumption of approximately 3W.

[0122] 14A-14B show flowcharts 1400 and 1420, respectively, of a switchable graphics power management scheme according to some embodiments. The switchable graphics power management scheme of various embodiments uses inputs from the system. Examples of system inputs include power and performance characterization of the iGPU and dGPU for several standard applications, as well as real-time information on system parameters such as SoC thermal capability, system power capability, etc. Flowcharts 1400 and 1420 use the GPU power / performance information to determine the appropriate GPU (iGPU and dGPU) for rendering.

[0123] As shown in the graphs of FIGS. 12 and 13, the power and performance characterization of the iGPU and dGPU for several standard applications is used to find the threshold power point of the GPU. FIGS. 14A-14B use this threshold power point (TPP) to further determine the appropriate GPU (e.g., iGPU or dGPU) for different tasks and use cases. Few standard applications that stress the GPU from low to high loads are prescriptive, and OEMs / ODMs (original equipment manufacturers / original design manufacturers) use these applications to find the threshold power point for their system. The threshold power point information is then passed to a graphics power management algorithm (e.g., via the BIOS or an embedded controller on the platform). The graphics power management algorithm of FIGS. 14A-14B can be implemented by software, hardware, or a combination thereof. In some embodiments, the graphics power management algorithm is implemented by a driver in the OS or kernel space. In some embodiments, the TPP and other parameters of the graphics power management algorithm are controlled by the user software space (a level of abstraction above the operating system space). In some embodiments, the graphics power management algorithm is executed by a power management unit of a graphics processor or system-on-chip.

[0124] In some embodiments, the graphics power management algorithm receives real-time information (e.g., power telemetry) of system parameters such as SoC thermal capabilities, system power supply capabilities, etc. In some cases, the power telemetry may be readily available information and no new hardware is required to obtain it. The flowchart illustrates a switchable graphics management control flow that considers the average power consumed by a GPU along with other system parameters (such as the power / thermal envelope) to determine the appropriate GPU to render a task, according to some embodiments.

[0125] The scheme of FIGS. 14A-14B can also learn from the power profile of applications rendered using existing driver / OS-based methods of switchable GFX and use this profile information to determine appropriate GPU selection upon future application restarts. GPU switching to optimize GPU usage based on the scheme of FIGS. 14A-14B can be achieved in many ways. Two methods are described below. One method is to dynamically switch GPUs while rendering tasks are in progress through smart interaction between the driver and the OS. This ensures seamless GPU switching without causing any visual glitches to the user.

[0126] When an application is launched (as shown in block 1401), the process begins with existing approaches, where the driver / OS determines which GPU (e.g., iGPU and dGPU) to render to, as shown in block 1402. Once the GPU execution units begin processing data, various embodiment schemes obtain GPU power consumption information from voltage regulator telemetry and / or other sources (e.g., scan chains, design-for-test (DFT) circuits, etc.). In some embodiments, various schemes calculate an exponentially weighted moving average (EWMA) on this real-time power data (from voltage regulator telemetry and / or other sources) to find the average power consumption of the GPU. The EWMA can be calculated as follows: EWMA1=EWMA t-1 +(Δt / τ)(P t -EWMA t-1 )···(1)

[0127] EWMA is a method for finding the average value of dynamic data by considering the instantaneous (t) value along with weighting of the previous (t-1) data. Typically, most graphics workloads are bursty in nature and require high power for short periods of time. Therefore, the problem of frequent GPU switching can be addressed by the EWMA averaging method. This averaging method is useful for applications where burst power consumption occurs frequently or for events with a high duty cycle of high power consumption to find such event periods. The scheme of various embodiments periodically samples this data to understand the duty cycle of the power profile.

[0128] If the task has a power profile that frequently crosses over a threshold power point (TPP) based on the duty cycle of the power profile, then in block 1403, it is determined whether the GPU EWMA power is above the TPP. If the GPU EWMA power is above the TPP, the process proceeds to block 1421, as indicated by identifier A, to use the dGPU for rendering, thereby ensuring that frequent context switches between the iGPU / dGPU do not occur and also ensuring that performance does not degrade. If the GPU EWMA power is above the TPP, the process proceeds to block 1427, as indicated by identifier B, to use the iGPU for rendering. If the GPU workload is bursty and the EWMA power frequently transitions back and forth above the threshold power point, then in block 1403, the scheme examines the duty cycle of the EWMA power profile and selects the GPU for rendering accordingly, thus avoiding frequent context switches.

[0129] At block 1421, a determination is made as to whether the driver and / or OS selected the dGPU for rendering. If the driver and / or OS selected the dGPU for rendering, the process proceeds to block 1422. At block 1422, a determination is made as to the capabilities of the system power supply. If the system power supply (e.g., a voltage regulator) can support the power consumption of the dGPU, the process proceeds to block 1423, where the dGPU is used for rendering the task. If the system power supply cannot support the power consumption of the dGPU, the process proceeds to block 1425. At block 1425, a GPU context switch is initiated in the driver and / or OS to select the iGPU for rendering. The process then proceeds to block 1426, where the iGPU is used for rendering the task. If the driver and / or OS does not select the dGPU for rendering at block 1421, the process proceeds to block 1424. At block 1424, a GPU context switch is initiated in the driver and / or OS to select the dGPU for rendering. The process then proceeds to block 1422 where the system power capability is determined as discussed herein.

[0130] At block 1427, a determination is made as to whether the driver and / or OS selected the iGPU for rendering. If the driver and / or OS selected the iGPU for rendering, the process proceeds to block 1428. At block 1428, a determination is made as to the thermal limitations of the SoC. If the SoC is thermally limited for the computation of a processor core of the SoC, the process proceeds to block 1429, where the GPU initiates a context switch with the driver and / or OS to select the iGPU for rendering. The process then proceeds to block 1424. The thermal limitations may be determined using data or measurements from a thermal sensor and / or a power management unit. The thermal limitations may correspond to a temperature of the processor core that is substantially the throttle temperature (e.g., the temperature at which the processor core is throttled). If the SoC is not thermally limited for the computation of a processor core of the SoC, the process proceeds to block 1426, where the iGPU is used to render the task. If the driver and / or OS does not select the iGPU for rendering, the process proceeds to block 1430. At block 1430, the GPU initiates a context switch with the driver and / or OS to select the iGPU for rendering. The process then proceeds to block 1428.

[0131] In some embodiments, a machine-readable medium is provided having instructions stored thereon that, when executed, cause a graphics processing unit (GPU) to perform a method for selecting whether an iGPU or a dGPU will perform a rendering task, the method including: stressing the GPU with various applications to determine a thermal power point (TPP); adaptively applying performance-per-watt information of both the integrated graphics processing unit (iGPU) and the discrete graphics processing unit (dGPU) and the TPP to determine whether the iGPU or the dGPU will perform the rendering task; and, upon selecting either the iGPU or the dGPU, selecting whether the iGPU or the dGPU will perform the rendering task according to the performance-per-watt information and the TPP.

[0132] In some embodiments, a machine-readable medium includes instructions stored thereon that, when executed, cause a GPU to perform a method including receiving telemetry information before determining whether the iGPU or the dGPU will perform a rendering task. In some embodiments, the machine-readable medium includes instructions stored thereon that, when executed, cause the GPU to perform a method including determining an average power consumption of the GPU via instantaneous power data and previous power data received through the telemetry information. In some embodiments, the machine-readable medium includes instructions stored thereon that, when executed, cause the GPU to perform a method including determining whether the average power consumption is greater than the TPP, and if the average power consumption is greater than the TPP, selecting the dGPU to perform the rendering task.

[0133] In some embodiments, a machine-readable medium includes instructions stored thereon that, when executed, cause a GPU to perform a method including selecting an iGPU to perform a rendering task when average power consumption is less than the TPP. In some embodiments, the machine-readable medium includes instructions stored thereon that, when executed, cause a GPU to perform a method including determining whether an iGPU or a dGPU will perform a rendering task according to a duty cycle of average power consumption when average power consumption has more than a threshold number of low and high transitions. In some embodiments, the machine-readable medium includes instructions stored thereon that, when executed, cause a GPU to perform a method including requesting an operating system or driver to select an iGPU to perform a rendering task when it is determined that a power source is incapable of supporting the power consumption of the dGPU. In some embodiments, the machine-readable medium includes instructions stored thereon that, when executed, cause a GPU to perform a method including requesting an operating system or driver to select a dGPU to perform a rendering task when it is determined that a processor core of the GPU is thermally limited.

[0134] FIG. 15 illustrates a simplified computer system 1500 according to some embodiments. System 1500 illustrates a display, such as a DisplayPort (DP) or HDMI (High Definition Multimedia Interface) 1503, that connects to a CPU 1505 (which may include a GPU and a memory controller hub (MCH)) via an LVDS 1501 (Low Voltage Differential Signaling, Flat Panel Display Link, Liquid Crystal Display), a Visual Graphics System (VGS) 1502, and a Platform Controller Hub (PCH) 1504. A dGPU 1506 connects to the CPU 1505 via a Peripheral Component Interconnect Express (PCIe). System memory 1507 connects to the CPU 1505, while local memory 1508 connects to the dGPU 1506. The display is connected to the iGPU display pipe via the display connection. Regardless of which display adapter processes the data, the display content is pushed through the iGPU display pipe. This allows for seamless dynamic context switching between GPUs. System 1500 demonstrates that the principle of switchable graphics helps in seamlessly transitioning between iGPU and dGPU without changing display pipes / ports.

[0135] If the system uses a different display architecture, then another method for GPU switching is that after finding a suitable GPU for rendering, the scheme of Figures 14A-14B indicates to the user via an OS pop-up message if the user wants to switch to a GPU optimized for rendering. If the user decides to switch GPUs, then the driver / OS further performs the action of switching GPUs. This is a simpler option from the perspective of software driver and OS interaction, but may not be seamless.

[0136] Figure 16 illustrates a smart device or computer system or SoC (system on a chip) that includes the apparatus, methods, and systems of various embodiments. It is noted that elements in Figure 16 that have the same reference numbers (or names) as elements in other figures can operate or function in a similar manner as described, but are not limited to such.

[0137] In some embodiments, device 2400 represents any suitable computing device, such as a computer tablet, a mobile phone or smartphone, a laptop, a desktop, an Internet of Things (IoT) device, a server, a wearable device, a set-top box, a wireless-enabled e-reader, etc. It will be understood that certain components are shown generically and that not all components of such a device are shown in device 2400.

[0138] In one example, device 2400 includes a system on a chip (SoC) 2401. An example boundary of SoC 2401 is shown using dotted lines in FIG. 16 , and several example components are shown as being included within SoC 2401, although SoC 2401 may include any suitable components of device 2400.

[0139] In some embodiments, device 2400 includes a processor 2404. Processor 2404 may include one or more physical devices, such as a microprocessor, application processor, microcontroller, programmable logic device, processing core, or other processing means. The processing operations performed by processor 2404 include the execution of an operating platform or operating system on which applications and / or device functions execute. The processing operations may include operations related to I / O (input / output) with a human user or other devices, operations related to power management, operations related to connecting computing device 2400 to another device, etc. The processing operations may also include operations related to audio I / O and / or display I / O.

[0140] In some embodiments, the processor 2404 includes multiple processing cores (also referred to as cores) 2408a, 2408b, 2408c. While only three cores 2408a, 2408b, 2408c are shown in FIG. 16, the processor 2404 may include any other suitable number of processing cores, e.g., tens or hundreds of processing cores. The processor cores 2408a, 2408b, 2408c may be implemented on a single integrated circuit (IC) chip. Additionally, the chip may include one or more shared and / or private caches, buses or interconnects, graphics and / or memory controllers, or other components.

[0141] In some embodiments, processor 2404 includes cache 2406. In one example, sections of cache 2406 may be dedicated to individual cores 2408 (e.g., a first section of cache 2406 dedicated to core 2408a, a second section of cache 2406 dedicated to core 2408b, etc.). In one example, one or more sections of cache 2406 may be shared between two or more cores 2408. Cache 2406 may be divided into different levels, e.g., a level 1 (L1) cache, a level 2 (L2) cache, a level 3 (L3) cache, etc.

[0142] In some embodiments, processor core 2404 may include a fetch unit for fetching instructions (including instructions with conditional branches) for execution by core 2404. The instructions may be fetched from any storage device, such as memory 2430. Processor core 2404 may also include a decode unit for decoding the fetched instructions. For example, the decode unit may decode the fetched instructions into multiple micro-operations. Processor core 2404 may include a schedule unit for performing various operations related to storing the decoded instructions. For example, the schedule unit may hold data from the decode unit until the instruction is ready to be dispatched, e.g., until all source values ​​of the decoded instruction are available. In one embodiment, the schedule unit may schedule the decoded instructions for execution and / or issue (or dispatch) the decoded instructions to the execution units.

[0143] The execution units may execute dispatched instructions after they are decoded (e.g., by a decode unit) and dispatched (e.g., by a schedule unit). In one embodiment, the execution units may include multiple execution units (e.g., an image calculation unit, a graphics calculation unit, a general-purpose calculation unit, etc.). The execution units may also perform various arithmetic operations such as addition, subtraction, multiplication, and / or division, and may include one or more arithmetic logic units (ALUs). In one embodiment, a coprocessor (not shown) may perform various arithmetic operations in combination with the execution units.

[0144] Additionally, the execution units may execute instructions out of order. Thus, in one embodiment, the processor core 2404 may be an out-of-order processor core. The processor core 2404 may also include a retirement unit. The retirement unit may retire executed instructions after they have been committed. In one embodiment, retiring an executed instruction may cause the processor state to be committed from the execution of the instruction, physical registers used by the instruction to be deallocated, and so on. The processor core 2404 may also include a bus unit that enables communication between components of the processor core 2404 and other components via one or more buses. The processor core 2404 may also include one or more registers for storing data accessed by various components of the core 2404, such as values ​​related to assigned app priorities and / or subsystem state (mode) associations.

[0145] In some embodiments, device 2400 includes connection circuitry 2431. For example, connection circuitry 2431 includes hardware devices (e.g., wireless and / or wired connectors and communication hardware) and / or software components (e.g., drivers, protocol stacks), for example, to enable device 2400 to communicate with external devices. Device 2400 can be isolated from external devices, such as other computing devices, wireless access points, or base stations.

[0146] In one example, the connection circuit 2431 may include multiple different types of connections. Generalizing, the connection circuit 2431 may include cellular connection circuitry, wireless connection circuitry, etc. The cellular connection circuitry of the connection circuit 2431 generally refers to cellular network connections provided by a wireless carrier, such as those provided via a GSM (Global System for Mobile Communications) or variants or derivatives, a CDMA (Code Division Multiple Access) or variants or derivatives, a TDM (Time Division Multiplexing) or variants or derivatives, a 3rd Generation Partnership Project (3GPP) Universal Mobile Telecommunications System (UMTS) system or variants or derivatives, a 3GPP Long Term Evolution (LTE) system or variants or derivatives, a 3GPP LTE-Advanced (LTE-A) system or variants or derivatives, a 5th Generation (5G) wireless system or variants or derivatives, a 5G mobile network system or variants or derivatives, a 5G New Radio (NR) system or variants or derivatives, or other cellular service standard. The wireless connection circuitry (or wireless interface) of the connection circuitry 2431 refers to a wireless connection that is not cellular and can include a personal area network (such as Bluetooth, Near Field, etc.), a local area network (such as Wi-Fi), and / or a wide area network (such as WiMax), and / or other wireless communications. In one example, the connection circuitry 2431 can include a network interface, such as a wired or wireless interface, such that, for example, an embodiment of the system can be incorporated into a wireless device, such as a mobile phone or personal digital assistant.

[0147] In some embodiments, device 2400 includes a control hub 2432, which represents hardware devices and / or software components related to interaction with one or more I / O devices. For example, processor 2404 can communicate with one or more of a display 2422, one or more peripheral devices 2424, storage device 2428, one or more other external devices 2429, etc. via control hub 2432. Control hub 2432 can be a chipset, a platform (control) controller hub (PCH), etc.

[0148] For example, control hub 2432 represents one or more connection points for additional devices to connect to device 2400, through which, for example, a user may interact with the system. For example, devices that may be attached to device 2400 (e.g., device 2429) include a microphone device, a speaker or stereo system, an audio device, a video system or other display device, a keyboard or keypad device, or other I / O devices for use in a particular application, such as a card reader or other device.

[0149] As described above, the control hub 2432 can interact with audio devices, the display 2422, and the like. For example, input via a microphone or other audio device can provide input or commands to one or more applications or functions of the device 2400. Furthermore, audio output can be provided instead of or in addition to display output. In another example, if the display 2422 includes a touchscreen, the display 2422 can also function as an input device and be managed at least in part by the control hub 2432. There may also be additional buttons or switches on the computing device 2400 to provide I / O functions managed by the control hub 2432. In one embodiment, the control hub 2432 manages devices such as an accelerometer, a camera, a light sensor or other environmental sensors, or other hardware that may be included in the device 2400. The input can be part of direct user interaction or can also provide environmental input to the system to affect the system's operation (such as filtering noise, adjusting the display for brightness detection, applying a flash to the camera, or other features).

[0150] In some embodiments, the control hub 2432 can couple to various devices using any suitable communication protocol, such as Peripheral Component Interconnect Express (PCIe), Universal Serial Bus (USB), Thunderbolt, High Definition Multimedia Interface (HDMI), Firewire, etc.

[0151] In some embodiments, display 2422 represents hardware (e.g., display devices) and software (e.g., drivers) components that provide a visual and / or tactile display for a user to interact with device 2400. Display 2422 may include a display interface, a display screen, and / or a hardware device used to provide a display to a user. In some embodiments, display 2422 includes a touchscreen (or touchpad) device that provides both output and input to a user. In one example, display 2422 may communicate directly with processor 2404. Display 2422 may be one or more of an internal display device, such as within a mobile electronic device or laptop device, or an external display device attached via a display interface (e.g., DisplayPort, etc.). In one embodiment, display 2422 may be a head-mounted display (HMD), such as a stereoscopic display device for use in virtual reality (VR) or augmented reality (AR) applications.

[0152] In some embodiments, although not shown, in addition to (or instead of) the processor 2404, the device 2400 may include a graphics processing unit (GPU) that includes one or more graphics processing cores, which may control one or more aspects of displaying content on the display 2422.

[0153] In some embodiments, one or more drivers 2454 implement a switchable graphics management scheme that uses performance / watt information for both integrated graphics (iGPU) or discrete graphics (dGPU) along with the system's real-time resources, such as the SoC (system-on-chip) thermal budget, system power budget, etc., to determine the appropriate GPU for rendering a task. The scheme uses this threshold power point information along with the system resources to determine the optimized GPU for rendering tasks for every application and use case. As such, the scheme adapts to each system design based on the capabilities of that particular system.

[0154] The control hub 2432 (or platform controller hub) may include hardware interfaces and connectors as well as software components (eg, drivers, protocol stacks) for making peripheral connections to, for example, peripheral devices 2424 .

[0155] It will be appreciated that device 2400 can be a peripheral to other computing devices as well as have peripherals connected to other computing devices. Device 2400 may have a "docking" connector for connecting to other computing devices for purposes such as managing (e.g., downloading and / or uploading, modifying, synchronizing) content on device 2400. Additionally, the docking connector allows device 2400 to connect to certain peripherals, allowing computing device 2400 to control content output to, for example, audiovisual or other systems.

[0156] In addition to proprietary docking connectors or other proprietary connection hardware, device 2400 can provide peripheral connectivity via common or standards-based connectors. Common types include Universal Serial Bus (USB) connectors (which can include any of several different hardware interfaces), DisplayPort, including MiniDisplayPort (MDP), High Definition Multimedia Interface (HDMI), Firewire, or other types.

[0157] In some embodiments, the connection circuitry 2431 may be coupled to a control hub 2432, for example, in addition to or instead of being directly coupled to the processor 2404. In some embodiments, the display 2422 may be coupled to the control hub 2432, for example, in addition to or instead of being directly coupled to the processor 2404.

[0158] In some embodiments, the device 2400 includes a memory 2430 coupled to the processor 2404 via a memory interface 2434. The memory 2430 includes a memory device for storing information in the device 2400.

[0159] In some embodiments, memory 2430 includes equipment for maintaining stable clocking, as described with reference to various embodiments. Memory can include non-volatile (state does not change when power to the memory device is interrupted) and / or volatile (state is indeterminate when power to the memory device is interrupted) memory devices. Memory device 2430 can be dynamic random-access memory (DRAM) devices, static random-access memory (SRAM) devices, flash memory devices, phase-change memory devices, or other memory devices with performance suitable for functioning as process memory. In one embodiment, memory 2430 can operate as system memory for device 2400, storing data and instructions for use by one or more processors 2404 when executing applications or processes. Memory 2430 can store application data, user data, music, photos, documents, or other data, as well as system data (long-term or temporary) related to the execution of applications and functions of device 2400.

[0160] Elements of various embodiments and examples are also provided as a machine-readable medium (e.g., memory 2430) for storing computer-executable instructions (e.g., instructions for performing other processes discussed herein). The machine-readable medium (e.g., memory 2430) may include, but is not limited to, flash memory, optical disks, CD-ROMs, DVD-ROMs, RAM, EPROMs, EEPROMs, magnetic or optical cards, phase-change memory (PCM), or other types of machine-readable media suitable for storing electronic or computer-executable instructions. For example, embodiments of the present disclosure may be downloaded from a remote computer (e.g., a server) to a requesting computer (e.g., a client) as a computer program (e.g., BIOS), which may be transferred by data signal over a communications link (e.g., a modem or network connection).

[0161] In some embodiments, device 2400 includes temperature measurement circuitry 2440, for example, to measure the temperatures of various components of device 2400. In one example, temperature measurement circuitry 2440 may be embedded in, coupled to, or attached to various computing devices whose temperatures need to be measured and monitored. For example, temperature measurement circuitry 2440 may measure the temperatures of one or more of (or within) cores 2408a, 2408b, 2408c, voltage regulator 2414, memory 2430, a motherboard of SoC 2401, and / or any suitable component of device 2400.

[0162] In some embodiments, the device 2400 includes a power measurement circuit 2442, for example, to measure power consumed by one or more components of the device 2400. In one example, in addition to or instead of measuring power, the power measurement circuit 2442 may measure voltage and / or current. In one example, the power measurement circuit 2442 may be embedded in, coupled to, or attached to various components whose power, voltage, and / or current consumption is to be measured and monitored. For example, the power measurement circuit 2442 may measure power, current, and / or voltage supplied by one or more voltage regulators 2414, power supplied to the SoC 2401, power supplied to the device 2400, power consumed by the processor 2404 (or any other component) of the device 2400, etc.

[0163] In some embodiments, device 2400 includes one or more voltage regulation circuits, commonly referred to as voltage regulators (VRs) 2414. VRs 2414 generate signals at appropriate voltage levels that can be supplied to operate any appropriate components of device 2400. By way of example only, VRs 2414 are shown providing signals to processor 2404 of device 2400. In some embodiments, VRs 2414 receive one or more voltage identification (VID) signals and generate voltage signals at appropriate levels based on the VID signals. Various types of VRs can be utilized for VRs 2414. For example, VRs 2414 include "buck" VRs, "boost" VRs, combinations of buck and boost VRs, low dropout (LDO) regulators, switching DC-DC regulators, constant-on-time controller-based DC-DC regulators, etc. Buck VRs are commonly used in power supply applications where an input voltage needs to be converted to an output voltage by a ratio less than one. Boost VRs are commonly used in power supply applications where an input voltage needs to be converted to an output voltage by a ratio greater than one. In some embodiments, each processor core has its own VR controlled by the PCU 2410a / b and / or PMIC 2412. In some embodiments, each core has a network of distributed LDOs that provide efficient control for power management. The LDOs can be digital, analog, or a combination of digital and analog LDOs. In some embodiments, the VR 2414 includes a current tracking device to measure the current through the power rails.

[0164] In some embodiments, device 2400 includes one or more clock generator circuits, generally referred to as clock generator 2416. Clock generator 2416 generates clock signals at appropriate frequency levels that may be provided to any appropriate components of device 2400. By way of example only, clock generator 2416 is shown providing clock signals to processor 2404 of device 2400. In some embodiments, clock generator 2416 receives one or more frequency identification (FID) signals and generates clock signals at appropriate frequencies based on the FID signals.

[0165] In some embodiments, device 2400 includes a battery 2418 that powers various components of device 2400. By way of example only, battery 2418 is shown powering processor 2404. Although not shown, device 2400 may include charging circuitry for recharging the battery based on alternating current (AC) power received from, for example, an AC adapter.

[0166] In some embodiments, device 2400 includes a power control unit (PCU) 2410 (also referred to as a power management unit (PMU), power controller, etc.). In one example, some sections of PCU 2410 may be implemented by one or more processing cores 2408, and these sections of PCU 2410 are symbolically depicted using dotted boxes and labeled PCU 2410a. In one example, some other sections of PCU 2410 may be implemented outside of processing core(s) 2408, and these sections of PCU 2410 are symbolically depicted using dotted boxes and labeled PCU 2410b. PCU 2410 can perform various power management operations of device 2400. PCU 2410 can include hardware interfaces, hardware circuits, connectors, registers, etc., as well as software components (e.g., drivers, protocol stacks) for performing various power management operations of device 2400.

[0167] In some embodiments, device 2400 includes a power management integrated circuit (PMIC) 2412, for example, to perform various power management operations for device 2400. In some embodiments, PMIC 2412 is a reconfigurable power management IC (RPMIC) and / or an Intel® Mobile Voltage Positioning (IMVP) chip. In one example, the PMIC is in an IC chip separate from processor 2404. The PMIC can perform various power management operations for device 2400. PMIC 2412 can include hardware interfaces, hardware circuits, connectors, registers, etc., and software components (e.g., drivers, protocol stacks) to perform various power management operations for device 2400.

[0168] In one example, device 2400 includes one or both of PCU 2410 or PMIC 2412. In one example, either one of PCU 2410 or PMIC 2412 may be absent from device 2400, and therefore these components are shown using dotted lines.

[0169] Various power management operations of device 2400 may be performed by PCU 2410, by PMIC 2412, or by a combination of PCU 2410 and PMIC 2412. For example, PCU 2410 and / or PMIC 2412 may select a power state (e.g., a P-state) of various components of device 2400. For example, PCU 2410 and / or PMIC 2412 may select a power state (e.g., in accordance with the Advanced Configuration and Power Interface (ACPI) specification) of various components of device 2400. By way of example only, PCU 2410 and / or PMIC 2412 may transition various components of device 2400 into a sleep state, an active state, an appropriate C-state (e.g., a C0 state in accordance with the ACPI specification, or another appropriate C-state). In one example, the PCU 2410 and / or the PMIC 2412 can control the voltage output by the VR 2414 and / or the frequency of the clock signal output by the clock generator, for example, by outputting a VID signal and / or an FID signal, respectively. In one example, the PCU 2410 and / or the PMIC 2412 can control features related to battery power usage, charging of the battery 2418, and power saving operation.

[0170] The clock generator 2416 may include a phase-locked loop (PLL), a frequency-locked loop (FLL), or any suitable clock source. In some embodiments, each core of the processor 2404 has its own clock source. As such, each core can operate at a frequency independent of the operating frequencies of the other cores. In some embodiments, the PCU 2410 and / or PMIC 2412 perform adaptive or dynamic frequency scaling or adjustment. For example, the clock frequency of a processor core may be increased if the core is not operating at its maximum power consumption threshold or limit. In some embodiments, the PCU 2410 and / or PMIC 2412 determines the operating state of each core of the processor and, if the PCU 2410 and / or PMIC 2412 determines that a core is operating below its target performance level, opportunistically adjusts the frequency and / or power supply voltage of that core without the core clocking source (e.g., that core's PLL) losing lock. For example, if a core is drawing less current from the power rails than the total current allocated to that core or processor 2404, then the PCU 2410 and / or PMIC 2412 can temporarily increase the power drawn for that core or processor 2404 (e.g., by increasing the clock frequency and / or power supply voltage level) to allow the core or processor 2404 to perform at a higher performance level. Thus, the voltage and / or frequency can be temporarily increased for the processor 2404 without compromising product reliability.

[0171] In one example, the PCU 2410 and / or PMIC 2412 can perform power management operations based at least in part on receiving measurements from, for example, the power measurement circuit 2442, the temperature measurement circuit 2440, the charge level of the battery 2418, and / or other suitable information that can be used for power management. To that end, the PMIC 2412 is communicatively coupled to one or more sensors to sense / detect various values / fluctuations of one or more factors that affect the power / thermal behavior of the system / platform. Examples of the one or more factors include current, voltage droop, temperature, operating frequency, operating voltage, power consumption, inter-core communication activity, etc. One or more of these sensors may be provided in physical proximity to (and / or in thermal contact / coupled with) one or more components or logic / IP blocks of the computer system. Further, in at least one embodiment, the sensors may be directly coupled to the PCU2410 and / or PMIC2412, enabling the PCU2410 and / or PMIC2412 to manage processor core energy based at least in part on values ​​detected by one or more sensors.

[0172] An exemplary software stack for device 2400 is also shown (although not all elements of the software stack are shown). By way of example only, processor 2404 may execute application program 2450, operating system 2452, one or more power management (PM) specific application programs (e.g., commonly referred to as PM applications 2458), etc. PM applications 2458 may also be executed by PCU 2410 and / or PMIC 2412. OS 2452 may also include one or more PM applications 2456a, 2456b, 2456c. OS 2452 may also include various drivers 2454a, 2454b, 2454c, etc., some of which may be specific to power management purposes. In some embodiments, device 2400 may further include a basic input / output system (BIOS) 2420. The BIOS 2420 may communicate with the OS 2452 (eg, via one or more drivers 2454), which may communicate with the processor 2404, etc.

[0173] For example, one or more of PM applications 2458, 2456, drivers 2454, BIOS 2420, etc. may be used to perform power management specific tasks, such as controlling the voltage and / or frequency of various components of device 2400, controlling the wake-up state, sleep state, and / or other suitable power state of various components of device 2400, controlling battery power usage, charging of battery 2418, features related to power saving operation, etc.

[0174] In some embodiments, the battery 2418 is a lithium metal battery that includes a pressure chamber that allows for the application of uniform pressure to the battery. The pressure chamber is supported by a metal plate (such as a pressure equalization plate) that is used to apply uniform pressure to the battery. The pressure chamber may contain pressurized gas, elastic material, spring plates, etc. The outer plate of the pressure chamber is free to flex and is constrained at its edges by the (metal) outer plate, but still applies uniform pressure to the plate compressing the battery cells. The pressure chamber applies uniform pressure to the battery, and this pressure is used to enable, for example, a high energy density battery with a 20% longer battery life.

[0175] In some embodiments, the pCode executing on the PCU 2410a / b has the ability to enable additional computational and telemetry resources for runtime support of the pCode. Here, pCode refers to firmware executed by the PCU 2410a / b to manage the performance of the SoC 2401. For example, the pCode may set the processor frequency and appropriate voltage. Portions of the pCode are accessible via the OS 2452. In various embodiments, mechanisms and methods are provided to dynamically change energy performance preference (EPP) values ​​based on workload, user behavior, and / or system conditions. There may be a well-defined interface between the OS 2452 and the pCode. The interface may allow or facilitate software configuration of some parameters and / or provide hints to the pCode. As an example, the EPP parameters may inform the pCode algorithms as to whether performance or battery life is more important.

[0176] This support can be achieved by including machine learning support as part of OS2452 and adjusting the EPP values ​​the OS suggests to the hardware (e.g., various components of SoC2401) based on machine learning predictions, or by delivering machine learning predictions to pCode in a manner similar to that done by Dynamic Tuning Technology (DTT) drivers. In this model, OS2452 can visualize the same set of telemetry available in DTT. As a result of DTT machine learning hint settings, pCode can adjust its internal algorithms to achieve optimal power and performance results according to the machine learning predictions for the activation type. For example, pCode can increase its responsibility for processor utilization changes to enable faster response to user activity, or it can increase its energy savings bias by reducing its responsibility for processor utilization or saving more power and increasing the performance lost by adjusting energy saving optimizations. This approach helps conserve more battery life when the enabled type of activity results in a loss of performance levels beyond what the system can enable. The pCode may include a dynamic EPP algorithm that receives two inputs, one from the OS2452 and the other from software such as the DTT, and can selectively choose to provide higher performance and / or responsiveness. As part of this method, the pCode may enable options in the DTT that tailor the DTT's response to different types of activity.

[0177] References herein to "an embodiment," "one embodiment," "some embodiments," or "other embodiments" mean that a particular feature, structure, or characteristic described in connection with an embodiment is included in at least some embodiments, but not necessarily in all embodiments. Various occurrences of "an embodiment," "one embodiment," or "some embodiments" do not necessarily all refer to the same embodiments. When the specification states that a component, feature, structure, or characteristic "may include," "could include," or "can include," that particular component, feature, structure, or characteristic does not (necessarily) need to be included. When the specification or claims refer to "a" or "an" element, this does not mean that there is only one element. When the specification or claims refer to "additional" elements, this does not exclude the presence of multiple additional elements.

[0178] Furthermore, particular features, structures, functions, or characteristics may be combined in any suitable manner in one or more embodiments. For example, a first embodiment may be combined with a second embodiment whenever particular features, structures, functions, or characteristics associated with the two embodiments are not mutually exclusive.

[0179] While the present disclosure has been described in conjunction with specific embodiments thereof, many alternatives, modifications, and variations of such embodiments will be apparent to those skilled in the art in light of the foregoing description. The embodiments of the present disclosure are intended to embrace all such alternatives, modifications, and variations that fall within the broad scope of the appended claims.

[0180] Furthermore, well-known power / ground connections to integrated circuit (IC) chips and other components may or may not be shown in the presented figures for ease of illustration and explanation and so as not to obscure the present disclosure. Furthermore, layouts may be shown in block diagram form to avoid obscuring the present disclosure, and in recognition of the fact that details regarding the implementation of such block diagram layouts will vary greatly depending on the platform on which the present disclosure is to be implemented (i.e., such details should be well within the purview of one skilled in the art). Where specific details (e.g., circuits) are shown to illustrate exemplary embodiments of the present disclosure, it should be apparent to one skilled in the art that the present disclosure can be practiced without these specific details or with variations thereof. Thus, the description should be considered illustrative, rather than limiting.

[0181] The following examples relate to further embodiments. Details of the examples can be used anywhere in one or more embodiments. All optional features of the devices described herein can also be implemented in the context of a method or process. Examples can be combined in any combination. For example, Example 4 can be combined with Example 2.

[0182] Example 1: A graphics processor includes an integrated graphics processing unit (iGPU); a discrete graphics processing unit (dGPU); logic that adaptively applies performance per watt information of both the iGPU and the dGPU; and a thermal power point (TPP) that determines whether the iGPU or the dGPU performs a rendering task.

[0183] Example 2: The graphics processor of example 1, wherein the logic receives telemetry information before determining whether the iGPU or the dGPU will perform a rendering task.

[0184] Example 3: The graphics processor of example 2, wherein the logic determines an average power consumption of the graphics processor via instantaneous power data and previous power data received via telemetry information.

[0185] Example 4: The graphics processor of example 3, wherein the logic determines whether the average power consumption is greater than the TPP, and if the average power consumption is greater than the TPP, the logic selects the dGPU to perform the rendering task.

[0186] Example 5: The graphics processor of example 4, wherein the logic selects the iGPU to perform rendering tasks if the average power consumption is less than the TPP.

[0187] Example 6: The graphics processor of Example 3, wherein when the average power consumption has more than a threshold number of low transitions and high transitions, the logic determines whether the iGPU or the dGPU performs the rendering task according to the duty cycle of the average power consumption.

[0188] Example 7: The graphics processor of example 4, wherein if the logic determines that the power supply cannot support the power consumption of the dGPU, the logic requests an operating system or driver to select the iGPU to render the task.

[0189] Example 8: The graphics processor of example 5, wherein if the logic determines that a processor core of the graphics processor is thermally limited, the logic requests an operating system or driver to select a dGPU to render the task.

[0190] Example 9: The graphics processor of example 1, wherein before the logic determines whether the iGPU or the dGPU will perform the rendering task, the operating system or driver determines whether the iGPU or the dGPU will perform the rendering task.

[0191] Example 10: The graphics processor of example 1, wherein the TPP is determined by stressing the graphics processor with various applications.

[0192] Example 11: The graphics processor of example 1, wherein the TPP is passed to a BIOS or an embedded controller.

[0193] Example 12: A machine-readable medium storing instructions that, when executed, cause a graphics processing unit (GPU) to perform a method including: stressing the GPU with various applications to determine a thermal power point (TPP); adaptively applying performance-per-watt information and TPP of both an integrated graphics processing unit (iGPU) and a discrete graphics processing unit (dGPU) to determine whether the iGPU or the dGPU will perform a rendering task; and selecting whether the iGPU or the dGPU will perform the rendering task according to the performance-per-watt information and TPP.

[0194] Example 13: The machine-readable medium of example 12, storing instructions that, when executed, cause the GPU to perform a method, the method including receiving telemetry information before determining whether the iGPU or the dGPU will perform a rendering task.

[0195] Example 14: The machine-readable medium of Example 13, storing instructions that, when executed, cause the GPU to perform a method that includes determining an average power consumption of the GPU via instantaneous power data and previous power data received via telemetry information.

[0196] Example 15: The machine-readable medium of example 14, storing instructions that, when executed, cause the GPU to perform a method including determining whether average power consumption is greater than the TPP, and selecting a dGPU to perform the rendering task if the average power consumption is greater than the TPP.

[0197] Example 16: The machine-readable medium of example 15 storing instructions that, when executed, cause the GPU to perform a method including selecting the iGPU to perform the rendering task if the average power consumption is less than the TPP.

[0198] Example 17: The machine-readable medium of Example 14, storing instructions that, when executed, cause the GPU to perform a method that includes determining whether the iGPU or the dGPU will perform a rendering task according to a duty cycle of average power consumption when the average power consumption has more than a threshold number of low transitions and high transitions.

[0199] Example 18: The machine-readable medium of Example 15, storing instructions that, when executed, cause the GPU to perform a method including requesting an operating system or driver to select the iGPU for rendering tasks if it is determined that the power supply cannot support the power consumption of the dGPU.

[0200] Example 19: The machine-readable medium of Example 16, storing instructions that, when executed, cause the GPU to perform a method, including requesting an operating system or driver to select a dGPU for rendering tasks when a processor core of the GPU is determined to be thermally limited.

[0201] Example 20: A system includes a memory; a graphics processing unit (GPU) coupled to the memory; and a wireless interface that enables the GPU to communicate with another device, wherein the GPU is as described in any one of Examples 1 to 11.

[0202] An Abstract is provided to allow the reader to ascertain the nature and gist of the technical disclosure. The Abstract is submitted with the understanding that it will not be used to limit the scope or meaning of the claims. The following claims are incorporated into the Detailed Description, with each claim standing on its own as a separate embodiment.

Claims

1. A graphics processor, comprising: Integrated Graphics Processing Unit (iGPU) and A discrete graphics processing unit (dGPU) and logic for determining a power consumption of the iGPU when the iGPU starts processing data for an application, and for determining whether to request an operating system or driver to select the dGPU instead of the iGPU to run the application when the power consumption exceeds a threshold; the power consumption is an exponentially weighted moving average power consumption of the iGPU, The threshold is set so that performance of the iGPU is equal to performance of the dGPU until the power consumption of the iGPU exceeds the threshold, and when the power consumption of the iGPU exceeds the threshold, the performance of the iGPU falls below the performance of the dGPU. Graphics processor.

2. To determine the power consumption, the logic comprises: Receives telemetry information from the voltage regulator; The graphics processor of claim 1 , further comprising: a processor configured to determine an average power consumption of the graphics processor via current power data and previous power data received via the telemetry information.

3. The graphics processor of claim 1, wherein the iGPU has a duty cycle based on the number of times the power consumption exceeds the threshold, and the logic determines whether to request that the operating system or driver select the dGPU instead of the iGPU based on the duty cycle.

4. The graphics processor of claim 1, wherein if the logic determines that the power supply cannot support the power consumption of the dGPU when the power consumption of the iGPU exceeds the threshold, the logic enables the iGPU to continue running the application.

5. The graphics processor of claim 1, wherein when the power consumption of the iGPU exceeds the threshold, and the logic determines that a processor core of the graphics processor is thermally limited, the logic enables the iGPU to continue running the application.

6. 2. The graphics processor of claim 1, wherein before the logic determines the power consumption of the iGPU, the operating system or driver selects the iGPU over the dGPU for executing the application.

7. The graphics processor of claim 1 , wherein the logic comprises a graphics power management algorithm implemented by software, hardware, or a combination thereof.

8. A non-transitory machine-readable medium having instructions stored thereon that, when executed, cause a graphics processing unit (GPU) to perform a method, the method including: Stressing an integrated graphics processing unit (iGPU) and a discrete graphics processing unit (dGPU) with various applications; determining performance of the iGPU, performance of the dGPU, and power consumption of the iGPU while applying a load to each of the various applications; determining one or more applications of the variety of applications, where the performance of the iGPU is degraded relative to the performance of the iGPU in other applications of the variety of applications while the performance of the dGPU is not degraded relative to the performance of the dGPU in other applications of the variety of applications; determining a threshold power point (TPP) based on the power consumption of the iGPU when the performance of the iGPU is degraded while the performance of the dGPU is not degraded; and passing the TPP to a graphics power management algorithm. Machine-readable medium.

9. The machine-readable medium of claim 8, wherein the method further includes determining the power consumption of the iGPU as an average power consumption based on current power data and previous power data.

10. The machine-readable medium of claim 9, wherein the method further includes a step of determining the power consumption of the iGPU as an exponentially weighted moving average power consumption.

11. The machine-readable medium of claim 10, wherein when the power consumption of the iGPU is less than the TPP, the graphics power management algorithm is configured to select the iGPU to perform a rendering task.

12. The machine-readable medium of claim 9, wherein the TPP is based on a duty cycle of the iGPU, the duty cycle being based on the number of times the power consumption of the iGPU exceeds the TPP.

13. 1. A system comprising: Memory, a general purpose processor coupled to the memory; a graphics processing unit (GPU) coupled to the general-purpose processor; The GPU is a graphics processor according to any one of claims 1 to 6. system.

Images