Faultless gpu switching at multiplexer

Abstract

When switching between multiple graphics processing units (GPUs) [130, 135] at a multiplexer (MUX), the rendering device [105] signals the display device [170] to capture and replay the current frame to hold a static image. Replaying the current frame while the MUX switch is in progress makes the user experience smooth, so that screen blanking or artifacts are not perceived.

Description

Background Technology

[0001] A typical processing system uses a graphics processing unit (GPU) to generate images for display on a display panel. Based on information received from a central processing unit (CPU) or other processing units, the GPU generates a series of frames and renders those frames for a display (e.g., a computer monitor). Some GPUs are capable of higher performance than others and can render higher-intensity graphics in shorter time periods. However, such high-performance GPUs consume more power than lower-performance GPUs, which are useful for saving power during scenes with lower-intensity graphics. To take advantage of the graphics capabilities of high-performance GPUs and the power savings of lower-performance GPUs, some processing systems employ multiple GPUs with different performance and power-saving characteristics. Attached Figure Description

[0002] This disclosure can be better understood by referring to the accompanying drawings, and many of its features and advantages will be apparent to those skilled in the art. The same reference numerals are used in different drawings to denote similar or identical items.

[0003] Figure 1 It is a block diagram of a processor that uses a multiplexer to switch between multiple graphics processing units (GPUs) when the display panel is using a panel playback protocol, according to some implementation schemes.

[0004] Figure 2 These are frames used in some implementation schemes to determine which GPU to select for outputting pixel data to the display panel. Figure 1 A block diagram of the control logic components of the processor.

[0005] Figure 3 The message flow between the GPU control logic unit, the active GPU, and the display panel for the panel playback protocol is shown when switching GPUs at a multiplexer, according to some implementation schemes.

[0006] Figure 4 This is a block diagram of a connection between a processor and a display panel, according to some implementation schemes, for signaling the display panel to a panel playback protocol when the GPU is switched at the multiplexer.

[0007] Figure 5 This is a flowchart illustrating a method, according to some embodiments, for using a panel replay protocol when switching frames of pixel data output to a display panel at a multiplexer. Detailed Implementation

[0008] In some multi-GPU configurations, a lower-performance GPU is permanently attached to the display panel, and high-graphics-intensity content is rendered by the high-performance GPU and then copied or streamed to the lower-performance GPU for output to the display panel. However, the overhead associated with copying or streaming rendered content to the lower-performance GPU impacts performance and results in lower frame rates that may adversely affect the user experience.

[0009] Figures 1 to 5 This paper illustrates a technique for using a panel replay protocol (PRP) for display devices when switching between multiple graphics processing units (GPUs) at a multiplexer (MUX). Switching between GPUs at the MUX reduces the overhead associated with multi-GPU configurations, where a lower-performance GPU is permanently connected to the display device, and content rendered by a high-performance GPU is copied or streamed to the lower-performance GPU for output to the display device. However, switching between GPUs at the MUX is time-consuming, during which the display device may blank or display artifacts observable to the user. Using a panel replay protocol (where the display panel captures and replays the most recently displayed frame to maintain a static image of the most recently displayed frame while the MUX switching is in progress) provides a smooth user experience, making screen blanking or artifacts imperceptible and enabling low-latency single-frame switching between GPUs. Furthermore, during the GPU switching time, the active GPU uses Advanced Link Power Management (ALPM) to power off the link between the GPU and the display device, thus saving power and improving efficiency.

[0010] Figure 1 A processing system 100, including a rendering device 105, is illustrated according to some embodiments. This rendering device employs a MUX 140 to switch between a low-power GPU 130 and a high-performance GPU 135, while simultaneously performing a panel playback protocol with a display device 170. The processing system 100 is typically configured to execute a set of instructions (e.g., a computer program), such as an application 115, to perform specified tasks of an electronic device. Examples of such tasks include controlling various aspects of the operation of the electronic device, displaying information to a user to provide a specified user experience, communicating with other electronic devices, and so on. Therefore, in different embodiments, the processing system 100 is used for one of a variety of types of electronic devices, such as desktop computers, laptop computers, servers, game consoles, tablets, smartphones, and so on. In some embodiments, the rendering device 105 includes a panel VDD 150 and a backlight power supply 155. The panel VDD 150 is configured to power panel logic components of the display device 170, and the backlight power supply 155 is configured to power the backlight of the display device 170.

[0011] To support the execution of the instruction set, the rendering device 105 includes multiple processor cores, such as a central processing unit (CPU) 110. In some implementations, each processor core includes one or more instruction pipelines to fetch instructions, decode instructions into corresponding operations, schedule operations to one or more execution units, execute operations, and exit operations. During instruction execution, the CPU 110 generates graphics operations and other operations associated with the visual display of information. Based on these operations, the CPU 110 sends data to multiple graphics processing units (GPUs) (in...) Figure 1 The GPU (shown as the low-power GPU 130 and the high-performance GPU 135) provides commands and data. Although in Figure 1 The diagram shows two GPUs, but in some implementations, the rendering device 105 includes more than two GPUs.

[0012] GPUs 130 and 135 are typically configured to receive commands and data associated with graphics and other display operations from multiple processor cores. Based on the received commands, GPUs 130 and 135 perform operations to generate frames for display. Examples of operations include vector operations, drawing operations, etc. In some implementations, the low-power GPU 130 is implemented as an accelerated processing unit (APU) and is configured to conserve power when rendering frames with low graphics intensity. On the other hand, the high-performance GPU 135 is configured to render frames with high graphics intensity (e.g., in video games) and consumes more power than the low-power GPU 130. In some implementations, the high-performance GPU 135 is capable of rendering frames at a higher frame rate than the low-power GPU 130. The low-power GPU 130 and the high-performance GPU 135 are connected to a multiplexer (MUX) 140, which switches between the low-power GPU 130 and the high-performance GPU 135 to output video frames to the display device 170, such that only one of the low-power GPU 130 and the high-performance GPU 135 (referred to herein as the active GPU) outputs the rendered frame at a time.

[0013] Control logic unit 120 is typically configured to determine, based on input from application 115, commands received from CPU 110, and input from power monitor 125, which of the low-power GPU 130 and high-performance GPU 135 will render each frame. For example, if control logic unit 120 determines, based on input from application 115 and commands received from CPU 110, that a video game involving graphics-intensive frames has been launched, then control logic unit 120 determines that high-performance GPU 135 should render those frames. If low-power GPU 130 was already active before the video game was launched, then control logic unit 120 determines that a switch between low-power GPU 130 and high-performance GPU 135 will occur at MUX 140. Control logic unit 120 is further configured to signal display device 170 when a switch between GPUs 130 and 135 is about to occur.

[0014] Conversely, if control logic 120 receives an indication from power monitor 125 that battery power is below a threshold, control logic 120 determines that low-power GPU 130 should render frames to increase battery life. If high-performance GPU 135 was already the initially active GPU before the low battery power indication, control logic 120 determines that a switch from high-performance GPU 135 to low-power GPU 130 will occur at MUX 140. Control logic 120 and power monitor 125 are implemented as hard-coded or programmable logic, one or more processors executing software / firmware instructions, or any combination thereof.

[0015] Each rendered frame output from the active GPU is buffered in a frame buffer or other storage component (not shown) of the rendering device 105. The active GPU then operates to transmit the pixel data representing the buffered frame, along with associated metadata, to the display device 170 line by line via interconnect 160.

[0016] Display device 170 is a display device typically configured to visually display an image on a panel based on frames generated by GPUs 130 and 135. Therefore, in different embodiments, display device 170 is a liquid crystal display (LCD) device, an organic light-emitting diode (OLED) device, and the like. As those skilled in the art will understand, display device 170 is typically configured to periodically display the most recent frame generated by the active GPU by refreshing display device 170 using pixel data received from the active GPU. Display device 170 includes a frame buffer (not shown) and is capable of executing a panel playback protocol (PRP).

[0017] To execute the panel replay protocol, display device 170 captures the current frame from the active GPU and stores it in a frame buffer. During PRP, the active GPU interrupts the supply of frames to display device 170, and display device 170 self-refreshes by periodically reading the captured frames from its frame buffer and supplying them for display on its panel. In response to the active GPU sending a frame with a real-time frame indication using PRP, display device 170 switches back to real-time frame transmission from the active GPU.

[0018] To facilitate a fault-free signal switching between the low-power GPU 130 and the high-performance GPU 135 at MUX 140 without blanking or artifacts, control logic 120 signals display device 170 to capture the current video frame at its frame buffer, and replays the captured frame in response to control logic 120 determining that a switching between GPUs 130 and 135 will occur at MUX 140. Upon receiving the captured frame signal, display device 170 begins capturing the current frame at its frame buffer. Once capture is complete, control logic 120 sends a replay frame signal to signal display device 170 to maintain a static image by continuously refreshing the panel using the captured frames. While display device 170 refreshes the panel using the captured frames, control logic 120 disables output from the active GPU, stops data transmission to display device 170 via interconnect 160, and initiates a switching from the active GPUs 130 and 135 to the other GPU 130 and 135. For example, if the low-power GPU 130 is the initially active GPU rendering the current frame, and the control logic unit 120 determines that it is necessary to switch to the high-performance GPU 135 based on the graphics intensity of the next frame, then once the display device 170 has started self-refreshing with the captured frame and switches to the high-performance GPU 135 at the MUX 140, the control logic unit 120 disables the output from the low-power GPU 130.

[0019] After the switching at MUX 140 is complete, control logic unit 120 powers on high-performance GPU 135. Once high-performance GPU 135 output is enabled, control logic unit 120 programs high-performance GPU 135 to send real-time frame signals to display device 170 to display new frames transmitted by high-performance GPU 135. In response to receiving the real-time frame signal, display device 170 resynchronizes to high-performance GPU 135 output.

[0020] In some implementations, GPUs 130 and 135 employ pseudo-timing synchronization mechanisms, such as reading the system time (not shown), to ensure a seamless transition from replaying a captured frame to displaying a real-time frame output by the newly active GPUs 130 and 135. For example, when output from the low-power GPU 130 is disabled during a transition, display device 170 uses its internal timing to replay the captured frame. When the high-performance GPU 135 sends a real-time frame signal, it uses the pseudo-timing synchronization mechanism to know when to begin outputting the real-time frame. As a result, the high-performance GPU 135 outputs the real-time frame in sync with the timing of the display device 170's output. As used herein, "synchronized" and "synchronously" refer to the relative alignment of a specific point in the display cycle of two or more devices within a specified amount of time (error tolerance).

[0021] In scenarios where the high-performance GPU 135 is the initially active GPU and a switch to the low-power GPU 130 is required—for example, due to low battery usage—the control logic unit 120 disables the output of the high-performance GPU 135, while the display device 170 self-refreshes with the captured frames and switches to the low-power GPU 130. Once the low-power GPU 130 output is enabled, it transmits new frames with real-time frame indications to the display device 170, and the display device 170 resynchronizes to the low-power GPU 130 output. Therefore, during the period when the low-power GPU 130 and the high-performance GPU 135 switch at the MUX 140, the display device 170 maintains a static image of the last captured frame output by the initially active GPU, resulting in a fault-free and artifact-free user experience.

[0022] Panel VDD 150 continues to supply power to the panel logic components of display device 170, and backlight power supply 155 continues to supply power to maintain backlight illumination of display device 170 during switching between GPUs 130 and 135 at MUX 140. In some embodiments, panel VDD 150 and backlight power supply 155 are supplied to display device 170 independently of MUX 140. In this way, the power supplied from panel VDD 150 to display device 170 and backlight power supply 155 remain unaffected during GPU switching at MUX 140.

[0023] Figure 2 It is based on some implementation plans. Figure 1A block diagram of portion 200 of the processing system 100 shows a control logic unit 120 of a rendering device 105 for determining which GPU to select to output frame pixel data to a display device 170. The control logic unit 120 includes a graphics intensity meter 225 and a GPU selector 235. The control logic unit 120 receives frame data 205 based on an application 115 executing at a CPU 110 (not shown) and power information 220 from a power monitor 125. The power monitor 125 includes a battery usage table 210.

[0024] Battery usage table 210 monitors whether the processing system 100 is operating in battery mode and the remaining battery power. Power monitor 125 compares the remaining battery power to a battery power threshold 215. Power monitor 125 provides power information 220 to control logic unit 120, indicating whether the remaining battery power is below the battery power threshold 215. In some embodiments, battery usage table 210 additionally monitors the battery power consumption rate, and power monitor 125 compares the battery power consumption rate to a battery power consumption rate threshold, and power information 220 includes an indication of whether the battery power consumption rate exceeds the battery power consumption rate threshold. Battery usage table 210 may be implemented as hard-coded or programmable logic, one or more processors executing software / firmware instructions, or any combination thereof.

[0025] Based on pixel data 205, the graphics intensity meter 225 calculates the graphics intensity level for each frame and compares it to a graphics intensity threshold 230. If the graphics intensity of a frame exceeds the graphics intensity threshold 230, the GPU selector 235 selects a high-performance GPU 235 to render that frame. In some implementations, if power information 220 indicates that the remaining battery power is below a battery power threshold 215, the GPU selector 235 overrides the selection of a high-performance GPU 135 (not shown) to render frames with graphics intensity exceeding the graphics intensity threshold 230, in order to increase battery life. If the graphics intensity of a frame is below the graphics intensity threshold 230, the GPU selector 235 selects a low-power GPU 130 (not shown) to conserve battery life. The graphics intensity meter 225 is implemented as hard-coded or programmable logic, one or more processors executing software / firmware instructions, or any combination thereof.

[0026] Figure 3A message flow 300 is shown between control logic 120, active GPU 330 (i.e., which of the low-power GPU 130 or the high-performance GPU 135 is currently active), and display device 170, according to some embodiments, for replaying captured frames using the Panel Replay Protocol (PRP) when GPUs 130 and 135 are switched at MUX 140. At time T1, display device 170 provides control logic 120 with an indication 302 that display device 170 supports PRP. After T1, control logic 120 determines that a GPU switch will occur for a frame at MUX 140 and provides active GPU 330 with an indication (not shown) that a GPU switch will occur at MUX 140 (from low-power GPU 130 to high-performance GPU 135 or from high-performance GPU 135 to low-power GPU 130). In response to receiving the instruction, at time T2, the active GPU 330 sends the capture frame signal 304 along with the current frame to the display device 170.

[0027] At time T3, in response to receiving signal 304 for capturing the current frame, display device 170 performs action 306 to capture the current frame at its frame buffer. After display device 170 has captured the current frame at its frame buffer, at time T4, the active GPU 330 sends a replay frame signal 308 to display device 170, signaling display device 170 to maintain the still image of the captured current frame. At time T5, in response to receiving replay frame signal 308, display device 170 performs action 310 to replay the current frame in each refresh cycle of display device 170 to maintain the still image, while control logic unit 120 performs action 312 to switch GPUs 130 and 135 at MUX 140. The action 312 of switching GPUs 130 and 135 at MUX 140 includes disabling output from the initially active GPUs 130 and 135 (i.e., GPUs 130 and 135 rendering the captured frames), switching GPUs 130 and 135 at MUX 140, powering on the initially inactive GPUs 130 and 135 (i.e., GPUs 130 and 135 not rendering the captured frames), and enabling the initially inactive (now newly active) GPUs 130 and 135 to output to the display device 170. Once the newly active GPUs 130 and 135 are able to output, at time T6, the active GPU 330 sends a real-time frame signal 314 and a new frame to the display device 170 to signal that the display device 170 is powered on and ready to accept input from the rendering device 105 via interconnect 160. In response to receiving the real-time frame signal 314, the display device 170 is powered on to be ready to receive input from the rendering device 105 via the interconnect 160 and resynchronize to the output of the newly active GPUs 130 and 135.

[0028] Figure 4 It is based on some implementation plans. Figure 1A block diagram of portion 400 of the processing system 100 shows the connection of interconnect 160 between rendering device 105 and display device 170 for signaling display device 170 to enter and exit panel self-refresh mode when GPUs 130, 135 are switched at multiplexer 140. Interconnect 160 includes pin groups 402, 404, 406, and 408. Pin group 402 is the main link through which active video signals are transmitted from rendering device 105 to display device 170. In some embodiments, capture frame signal 304 for capturing the current frame prior to GPU switching at MUX 140 is an information packet or metadata transmitted during the vertical blanking region of the current frame. In some embodiments, active GPU 330 uses the Advanced Link Power Management (ALPM) feature of eDP to put pin group 402 into sleep or power-off state during the time when GPUs 130, 135 are switched at MUX 140. Once the GPU switch is complete, the newly active GPUs 130 and 135 read the panel status to determine if the display device 170 is in ALPM sleep mode. The newly active GPUs 130 and 135 wake up pin group 402 and begin frame transmission to the display device 170.

[0029] Pin group 404 is an auxiliary (AUX) channel used by rendering device 105 to wake up display device 170 utilizing the ALPM feature of eDP and to transmit real-time frame signal 314 to display device 170 to display a new frame transmitted by the newly active GPUs 130, 135 after GPU switching at MUX 140 has been completed. In some embodiments, real-time frame signal 314 is a packet of information or metadata transmitted during the vertical blanking region of the new frame. In some embodiments, rendering device 105 does not use pin groups 402 and 404 during the time when GPU switching occurs at MUX 140.

[0030] Pin group 406 is used by the panel VDD 150 of rendering device 105 to power the panel logic components of display device 170. Similarly, pin group 408 is the channel through which backlight power supply 155 powers the backlight of display device 170. Pin groups 406 and 408 remain active during the time when GPU switching occurs at MUX 140, keeping display device 170 powered on and the panel backlight of display device 170 illuminated during GPU switching at MUX 140.

[0031] Figure 5This is a flowchart illustrating a method 500, according to some embodiments, for signaling a display device to perform a self-refresh with captured frames when the GPU switches frames of pixel data output to the display device at a multiplexer. In some embodiments, method 500 is performed by a processing system (such as...) Figure 1 The processing system 100 is implemented.

[0032] At block 502, control logic 120 receives an instruction 302 from display device 170 indicating that display device 170 supports panel playback protocols. At block 504, control logic 120 receives pixel data 205 for the current frame from CPU 110 based on the currently executing application 115. At block 506, control logic 120 determines the graphics intensity level of the frame. At block 508, control logic 120 receives power information 220 from power monitor 125. Based on the graphics intensity level and power information 220, control logic 120 determines at block 510 whether to switch GPUs 130, 135 at MUX 140 due to graphics requirements and / or power constraints. For example, if the low-power GPU 130 is the active GPU rendering a frame and outputting the rendered frame through the MUX 140, and the control logic 120 determines that the graphics intensity level of the next frame exceeds a threshold, and further determines that there is sufficient battery power, then the control logic 120 determines to switch to the high-performance GPU 135 at the MUX 140. However, if the remaining battery power is below the threshold, in some embodiments, the control logic 120 determines not to switch to the high-performance GPU 135 and keeps the low-power GPU 130 as the active GPU. Conversely, if the high-performance GPU 135 is the active GPU, and the control logic 120 determines that the graphics intensity level of the next frame does not exceed the threshold, or there is insufficient battery power to keep the high-performance GPU 135 as the active GPU, then the control logic 120 determines to switch to the low-power GPU 130 at the MUX 140.

[0033] At box 510, if control logic 120 determines that GPUs 130 and 135 will not be switched at MUX 140, the process flow continues back to box 504, where the next frame of pixel data is received. At box 510, if control logic 120 determines that GPUs 130 and 135 will be switched at MUX 140, the process flow continues to box 512. At box 512, the active GPUs 130 and 135 send a capture frame signal to display device 170 to capture the current frame and a replay frame signal to replay the captured frame. In response to receiving the capture frame signal, display device 170 captures the current frame at the frame buffer and refreshes the panel with the current frame. While display device 170 is replaying the current frame, at box 514, control logic 120 switches GPUs 130 and 135 at MUX 140. Once the switching at MUX 140 is complete, control logic 120 powers on the newly active GPUs 130 and 135. When the newly active GPUs 130 and 135 are able to output rendered frames, at frame 516, the newly active GPUs 130 and 135 send real-time frame signals to the display device 170 to display the new frames transmitted by the newly active GPUs 130 and 135. Upon receiving the real-time frame signals, the display device 170 resynchronizes to the output of the newly active GPUs 130 and 135.

[0034] As disclosed herein, in some embodiments, a method includes: signaling at a processor's rendering device to a display panel to capture and replay a first frame of pixel data output from a first graphics processing unit (GPU); in response to the display panel capturing and replaying the first frame, switching the output of pixel data from a first GPU to a second GPU; and in response to the completion of the switching, signaling to the display panel to display a second frame transmitted by the second GPU. In one aspect, the method includes: disabling the output of pixel data from the first GPU in response to the display panel replaying the first frame. In another aspect, signaling to the display panel to capture and replay the first frame includes: signaling to the display panel to capture the first frame in the metadata of the first frame; and signaling to the display panel to maintain a static image of the captured first frame.

[0035] In one aspect, the method includes: de-energizing the link between the rendering device and the display panel when switching from outputting pixel data from a first GPU to outputting pixel data from a second GPU to the display panel. In another aspect, the method includes: at a control logic unit of the processor, selecting either the first GPU or the second GPU to output pixel data for a frame based on at least one of a frame's graphics intensity and the processor's battery power, wherein the switching further responds to selecting the second GPU to output pixel data for the frame. In yet another aspect, the method includes: outputting pixel data for a frame from the first GPU in response to determining that the frame's graphics intensity is higher than a threshold, wherein the first GPU is a higher-performance GPU than the second GPU. In yet another aspect, the method includes: outputting pixel data for a frame from the second GPU in response to the frame's graphics intensity being lower than a threshold. In yet another aspect, the transmission of the second frame is synchronized between the second GPU and the display panel's internal timing.

[0036] In some implementations, a method includes: outputting pixel data from a first graphics processing unit (GPU) of a processor to a display panel; signaling the display panel to replay a current frame of the pixel data output from the first GPU; disabling the output of pixel data from the first GPU in response to the display panel replaying the current frame; switching to outputting pixel data from a second GPU to the display panel; and signaling the display panel to display a frame output from the second GPU in response to the second GPU outputting pixel data. In one aspect, the method includes: determining that the display panel can maintain a static image while disabling the output of pixel data from the first GPU. In another aspect, signaling the display panel to replay the current frame includes: signaling the display panel to capture a current frame of pixel data output from the first GPU at a frame buffer; and signaling the display panel to maintain a static image of the captured current frame.

[0037] In one aspect, the method includes: when switching from outputting pixel data from a first GPU to outputting pixel data to a display panel from a second GPU, de-energizing the link between the processor and the display panel. In another aspect, the method includes: at a control logic unit of the processor, selecting either the first GPU or the second GPU to output pixel data for a frame based on at least one of the graphics intensity of the frame and the processor's battery power. In yet another aspect, determining includes: in response to the graphics intensity of the frame being higher than a threshold, outputting pixel data for the frame from the first GPU, wherein the first GPU is a higher-performance GPU than the second GPU.

[0038] In one aspect, the method includes: outputting pixel data for the frame from a second GPU in response to the frame's graphics intensity falling below a threshold. In another aspect, the second GPU outputs pixel data in synchronization with the output of the display panel.

[0039] In some embodiments, a device includes: a first graphics processing unit (GPU); a second GPU; and control logic configured to switch between outputting pixel data from the first GPU and the second GPU to a display panel; wherein the first GPU is configured to signal the display panel to replay the current frame of the pixel data output from the first GPU in response to detecting that the device is switching from outputting pixel data from the first GPU to outputting pixel data from the second GPU to the display panel; and the second GPU is configured to signal the display panel to display a frame of the pixel data output from the second GPU in response to the second GPU outputting pixel data. In one aspect, the first GPU is further configured to disable the output of pixel data in response to the display panel capturing and replaying the current frame. In another aspect, in response to receiving an instruction from the control logic to switch from outputting pixel data from the first GPU to outputting pixel data to the display panel, the first GPU is further configured to signal the display panel to capture the current frame output from the first GPU at a frame buffer; and to signal the display panel to replay the current frame.

[0040] In one aspect, in response to the second GPU outputting pixel data, the second GPU is further configured to: signal the display panel to power on to a ready state to accept input from the device via the interconnect; and output pixel data to the display panel. In another aspect, the control logic is configured to select either the first GPU or the second GPU to output pixel data for a frame based on at least one of the frame's graphics intensity and the device's battery power. In yet another aspect, the control logic is further configured to: select the first GPU to output pixel data for a frame in response to the frame's graphics intensity exceeding a threshold, wherein the first GPU is a higher-performance GPU than the second GPU.

[0041] In some implementations, the above-described devices and techniques are implemented in systems including one or more integrated circuit (IC) devices (also known as integrated circuit packages or microchips), such as those referenced above. Figures 1 to 5The described processing system 100. Electronic design automation (EDA) and computer-aided design (CAD) software tools can be used in the design and manufacture of these IC devices. These design tools are typically represented as one or more software programs. One or more software programs include code executable by a computer system to manipulate the computer system to operate on code representing circuitry of one or more IC devices to perform at least a portion of a process for designing or adapting a manufacturing system to manufacture the circuitry. The code may include instructions, data, or a combination of instructions and data. Software instructions representing design or manufacturing tools are typically stored in a computer-readable storage medium accessible to the computing system. Similarly, code representing one or more stages of the design or manufacture of the IC device may be stored in and accessed from the same or different computer-readable storage media.

[0042] Computer-readable storage media can include any non-transitory storage medium or a combination of non-transitory storage media that can be accessed by a computer system during use to provide instructions and / or data to the computer system. Such storage media can include, but are not limited to, optical media (e.g., optical discs (CDs), digital versatile optical discs (DVDs), Blu-ray discs), magnetic media (e.g., floppy disks, magnetic tapes, or magnetic hard disks), volatile memory (e.g., random access memory (RAM) or cache), non-volatile memory (e.g., read-only memory (ROM) or flash memory), or microelectromechanical systems (MEMS) based storage media. Computer-readable storage media can be embedded in a computing system (e.g., system RAM or ROM), fixedly attached to a computing system (e.g., a magnetic hard disk drive), removably attached to a computing system (e.g., an optical disc or a USB-based flash memory), or coupled to a computer system via a wired or wireless network (e.g., a network-accessible storage device (NAS)).

[0043] In some implementations, certain aspects of the above-described techniques may be implemented by one or more processors of a processing system executing the software. The software includes one or more sets of executable instructions stored or otherwise tangibly embodied on a non-transitory computer-readable storage medium. The software may include instructions and certain data that, when executed by one or more processors, manipulate one or more processors to perform one or more aspects of the above-described techniques. The non-transitory computer-readable storage medium may include, for example, disk or optical disk storage devices, solid-state storage devices such as flash memory, cache memory, random access memory (RAM), or one or more other non-volatile memory devices. The executable instructions stored on the non-transitory computer-readable storage medium may be source code, assembly language code, object code, or other instruction formats that are interpreted or otherwise executed by one or more processors.

[0044] It should be noted that not all activities or elements described above in the general description are essential. A particular activity or part of the apparatus may not be essential, and one or more additional activities may be performed, or elements may be included in addition to those described. Furthermore, the order in which the activities are listed is not necessarily the order in which they are performed. Additionally, these concepts have been described with reference to specific embodiments. However, those skilled in the art will understand that various modifications and changes may be made without departing from the scope of this disclosure as set forth in the following claims. Therefore, the specification and drawings are to be considered illustrative rather than restrictive, and all such modifications are intended to be included within the scope of this disclosure.

[0045] The benefits, other advantages, and solutions to problems have been described above with respect to specific embodiments. However, the benefits, advantages, solutions to problems, and any features that may lead to or make any benefit, advantage, or solution appear or become more significant should not be construed as key, essential, or fundamental features of any or all claims. Furthermore, the specific embodiments disclosed above are merely illustrative, as the disclosed subject matter can be modified and practiced in different but equivalent ways that will be apparent to those skilled in the art who benefit from the teachings herein. No limitation is intended on the details of the constructions or designs shown herein, except as described in the following claims. Therefore, it will be apparent that the specific embodiments disclosed above can be altered or modified, and all such changes are considered to be within the scope of the disclosed subject matter. Therefore, the protection sought herein is set forth in the following claims.

Claims

1. A rendering method, comprising: In response to a comparison between the graphics intensity level of a pixel data frame and a graphics intensity threshold, the first graphics processing unit of the rendering device provides one or more signals to the display panel, instructing the display panel to capture and replay a first frame of pixel data output from the first graphics processing unit; In response to the display panel capturing and replaying the first frame, the control logic unit of the rendering device disables the pixel data output of the first graphics processing unit and enables the pixel data output of the second graphics processing unit of the rendering device. as well as In response to the output of pixel data enabled by the second graphics processing unit, the second graphics processing unit provides one or more signals to the display panel, instructing the display panel to display the second frame transmitted by the second graphics processing unit.

2. The method according to claim 1, wherein, Providing the display panel with one or more signals to instruct the display panel to capture and replay the first frame includes: The first frame is provided to the display panel by the first graphics processing unit, wherein the first frame includes metadata instructing the display panel to capture the first frame; and The first graphics processing unit provides a signal to the display panel, instructing the display panel to hold the captured static image of the first frame.

3. The method according to claim 1 or 2, further comprising: The link between the rendering device and the display panel is de-energized before the output of pixel data of the first graphics processing unit is disabled and the output of pixel data of the second graphics processing unit is enabled.

4. The method according to claim 1 or 2, further comprising: The control logic unit selects either the first graphics processing unit or the second graphics processing unit to output pixel data for the frame based on at least one of the frame's graphics intensity and the rendering device's battery power. The prohibition of the output of pixel data by the first graphics processing unit further responds to the selection of the second graphics processing unit to output pixel data for the frame.

5. The method according to claim 4, further comprising: In response to determining that the graphics intensity of the frame is higher than a threshold, pixel data for the frame is output from the first graphics processing unit, wherein the first graphics processing unit is a higher performance graphics processing unit than the second graphics processing unit.

6. The method according to claim 5, further comprising: In response to the frame's graphics intensity being lower than the threshold, pixel data for the frame is output from the second graphics processing unit.

7. The method according to claim 1 or 2, wherein the transmission of the second frame is synchronized between the second graphics processing unit and the internal timing of the display panel.

8. A rendering device, comprising: First graphics processing unit; Second graphics processing unit; as well as A control logic unit configured to, in response to the display panel capturing and replaying the first frame, disable pixel data output of the first graphics processing unit and enable pixel data output of the second graphics processing unit; in In response to a comparison of the graphics intensity level of a pixel data frame with a graphics intensity threshold, the first graphics processing unit is configured to provide one or more signals to the display panel, instructing the display panel to capture and replay the first frame of pixel data output from the first graphics processing unit; and The second graphics processing unit is configured to provide one or more signals to the display panel in response to the output of pixel data that enables the second graphics processing unit, instructing the display panel to display a second frame of pixel data output from the second graphics processing unit.

9. The rendering apparatus according to claim 8, wherein, In response to receiving a request from the control logic unit to disable the output of pixel data from the first graphics processing unit, the first graphics processing unit is further configured to: The first frame is provided to the display panel, wherein the first frame includes metadata instructing the display panel to capture the first frame; and A signal is provided to the display panel, instructing the display panel to replay the first frame.

10. The rendering apparatus according to claim 8 or 9, wherein, In response to the output of pixel data from the second graphics processing unit being enabled, the second graphics processing unit is further configured to: Provide a signal to the display panel, instructing the display panel to be powered on to a ready state to receive input from the rendering device via the interconnect; and Output pixel data to the display panel.

11. The rendering apparatus of claim 8 or 9, wherein the control logic component is configured to select either the first graphics processing unit or the second graphics processing unit to output pixel data for the frame based on at least one of the graphics intensity of the frame and the battery power of the rendering apparatus.

12. The rendering apparatus according to claim 8 or 9, wherein the control logic component is further configured to: In response to the frame having a graphics intensity higher than a threshold, the first graphics processing unit is selected to output pixel data for the frame, wherein the first graphics processing unit is a higher performance graphics processing unit than the second graphics processing unit.

13. The rendering apparatus of claim 8 or 9, wherein the control logic component is further configured to synchronize the transmission of the second frame between the second graphics processing unit and the internal timing of the display panel.

Images