TWI466099B - Method and apparatus to support a self-refreshing display device coupled to a graphics controller - Google Patents

Description

Method and apparatus for supporting a self-updating display coupled to a graphics controller

SUMMARY OF THE INVENTION The present invention generally relates to a display system, and more particularly to a method and apparatus for supporting a self-updating display coupled to a graphics controller.

Some newly designed displays have self-updating capabilities, wherein the display includes a local controller configured to generate video signals from a static cache frame that is independent of the digital video of the graphics controller. When in this self-refresh mode, the video signals are driven by the local controller to allow certain portions of a parallel processing system (eg, the graphics controller and communication bus) to be placed in a deep sleep state. To save electricity. Once in the self-updating mode, when the image to be displayed needs to be updated, control can be transferred to the graphics controller to allow the new video signal to be generated based on a new set of pixel data.

Conventional systems are arranged to initialize a variety of components that are connected to each other in series. For example, the central processing unit first causes a drive to make a call to wake up the communication bus. An initialization routine is executed to set the communication bus. Once the communication bus is operating in a normal state, the central processing unit causes a drive to make a call to wake up the graphics controller. The graphics controller then transmits a command to the graphics controller via the communication bus to initialize the graphics controller.

One disadvantage of the above technique is that each component of the parallel processing subsystem must be initialized sequentially before the next component can begin its initialization procedure. For example, when the communication bus is initialized, the graphics controller can remain idle to wait to receive commands transmitted over the communication bus. The described technique does not minimize the number of clock cycles that the graphics driver initializes when a deep sleep state is woken up. The extended initialization routine will cause the latent time of the graphics update and will cause distraction to the user of the computer system when entering and leaving a panel self-updating mode.

As previously mentioned, there is a need in the art for an improved technique to wake the graphics controller from a deep sleep state.

One embodiment of the present invention provides a method for setting an operational state of a graphics processing unit coupled to a self-updating display. The method includes the step of executing at least one job to set a first portion of an operational state of the graphics processing unit. The method further includes the steps of: determining whether a signal has been asserted to indicate that the graphics processing unit must perform a warm boot operation, and if the signal has been set, performing the warm boot operation to set the graphics processing unit A second portion of the operational state, or if the signal has not been set, performs a cold boot operation to set the second portion of the operational state of the graphics processing unit.

One benefit of this disclosure technique is that minimizing the setup time of a graphics processing unit when the display is operating in a panel self-refresh mode can reduce the latency associated with updating an image being displayed. Computer systems including displays with self-updating capabilities can often cause a graphics processing unit to enter and leave a deep sleep state. It is common for the graphics processing unit to leave the deep sleep state after a few seconds of entering the deep sleep state. Therefore, the configuration of the computer system is almost impossible to change since the graphics processing unit enters the deep sleep state. The disclosed technique explores this phenomenon by setting the operational state of the graphics processing unit rather than relying on the graphics driver to set the graphics processing unit each time the graphics processing unit is powered on.

Another benefit of the disclosed technique is that the graphics processing unit can be placed in parallel with other hardware and software components of the computer system. The graphics processing unit may not need to rely on a high speed communication bus before the graphics processing unit can be set up by using an auxiliary communication path or a dedicated non-volatile memory to load an instruction for setting the graphics processing unit. Successful initialization of (eg PCIe bus). Enabling the graphics processing unit to be individually set to reduce the initial The time required for the process and provide a better user experience.

In the following description, numerous specific details are set forth to provide a more complete understanding of the invention. However, it will be understood by those skilled in the art that the present invention may be practiced without one or more of these specific details. In other instances, well-known features are not described in order to avoid obscuring the invention.

System Overview

1 is a block diagram of a computer system 100 that is configured to implement one or more aspects of the present invention. Computer system 100 includes a central processing unit (CPU) 102 and a system memory 104 that communicate via an interconnect path including a memory bridge 105. The memory bridge 105 can be a north bridge wafer that is connected to an I/O (input/output) bridge 107 via a bus or other communication path 106 (e.g., a HyperTransport link). The I/O bridge 107 can be a south bridge chip that receives user input from one or more user input devices 108 (eg, a keyboard, mouse) and forwards the input via path 106 and memory bridge 105 to CPU 102. A parallel processing subsystem subsystem 112 is coupled to the memory bridge 105 via a bus or other communication path 113 (e.g., PCI Express, accelerated graphics, or HyperTransport coupling); in one embodiment, the parallel processing subsystem 112 A graphics subsystem that passes pixels to a display 110 (eg, a conventional CRT or LCD type monitor). A graphics driver 103 can be arranged to transmit graphics primitives over the communication path 113 such that the parallel processing subsystem 112 can generate pixel data to be displayed on the display 110. A system disk 114 is also coupled to the I/O bridge 107. A switch 116 provides a connection between the I/O bridge 107 and other components such as the network adapter 118 and the various embedded cards 120, 121. Other components (not explicitly shown) include USB or other port connections, CD drives, DVD drives, movie recording devices, and the like, which may also be coupled to I/O bridge 107. The communication paths interconnected to the various components of Figure 1 can be implemented using any suitable protocol, such as Such as PCI (Peripheral Component Interconnect), PCI Express (PCI Express, PCI-E), AGP (Accelerated Graphics Port), HyperTransport (Hyper Transport), or any other port or point-to-point communication Agreements, and connections between different devices may use different protocols as are known in the art.

In one embodiment, the parallel processing subsystem 112 incorporates circuitry optimized for graphics and video processing, including, for example, video output circuitry, and constitutes a graphics processing unit (GPU). In another embodiment, parallel processing subsystem 112 incorporates circuitry optimized for general processing, while retaining the underlying operational architecture, as will be described in more detail. In yet another embodiment, the parallel processing subsystem 112 can be integrated into one or more other system components, such as the memory bridge 105, the CPU 102, and the I/O bridge 107 to form a system-on-chip ( SoC, System on chip).

It will be appreciated that the systems shown herein are merely illustrative and that many variations and modifications are possible. The connection topology, including the number and configuration of bridges, the number of CPUs 102, and the number of parallel processing subsystems 112 can all be modified as needed. For example, in some embodiments, system memory 104 is directly coupled to CPU 102 rather than through a bridge, while other devices communicate with system memory 104 via memory bridge 105 and CPU 102. In other alternative topologies, parallel processing subsystem 112 is coupled to I/O bridge 107 or directly to CPU 102, rather than to memory bridge 105. In still other embodiments, I/O bridge 107 and memory bridge 105 can be integrated into a single wafer. Large specific embodiments may include two or more CPUs 102, and two or more parallel processing subsystems 112. The particular components shown herein are optional, for example, can support any number of embedded cards or peripheral devices. In some embodiments, switch 116 is omitted and network adapter 118 and embedded cards 120, 121 are directly connected to I/O bridge 107.

2A is a parallel processing subsystem 112 coupled to a display 110 having self-updating capabilities, in accordance with an embodiment of the present invention. As shown, Parallel processing subsystem 112 includes a graphics processing unit (GPU) 240 coupled to a graphics memory 242 via a DDR3 bus interface. Graphics memory 242 includes one or more frame buffers 244(0), 244(1)...244(N-1), where N is a frame buffer implemented in parallel processing subsystem 112. total. Parallel processing subsystem 112 is configured to generate video signals based on pixel data stored in frame buffer 244 and to transmit the video signals to display 110 via communication path 280. The communication path 280 can be any video interface known in the art, such as an embedded display port (eDP) interface or a low voltage differential signal (LVDS) interface.

GPU 240 may be arranged to receive graphics primitives from CPU 102 via communication path 113, such as via a PCIe bus. The GPU 240 processes the graphics primitives to generate a frame of pixel data for display on the display 110 and stores the pixel data frame in the frame buffer 244. Under normal operation, GPU 240 is configured to scan the pixel data from frame buffer 244 to produce a video signal for display on display 110. In one embodiment, GPU 240 is configured to generate a digital video signal and transmit the digital video signal to display 110 via a digital video interface, such as via an LVDS, DVI, HDMI, or DisplayPort (DP) interface. In another embodiment, GPU 240 can be configured to generate an analog video signal and transmit the analog video signal to display 110 via an analog video interface, such as via a VGA or DVI-A interface. In a specific embodiment where the communication path 280 employs an analog video interface, the display 110 can sample the analog video signal using one or more analog to digital converters to convert the received analog video signal into a digital video signal.

As shown in FIG. 2A, the display 110 includes a timing controller (TCON) 210, a self-refresh controller (SRC) 220, and a liquid crystal display (LCD) device 216. One or more row drivers 212, one or more column drivers 214, and one or more local frame buffers 224(0), 224(1)...224(M-1), where M is at the display The total number of local frame buffers in 110. When TCON 210 generates video The sequence signal is used to drive the LCD device 216 via the row driver 212 and the column driver. Row driver 212, column driver 214, and LCD device 216 can be any conventional row driver, column driver, and LCD device known in the art. As also shown, the TCON 210 can transmit pixel data to the row driver 212 and column driver 214 via a communication interface, such as via a mini LVDS interface.

The SRC 220 is arranged to generate a video signal to be displayed on the LCD device 216 based on the pixel data stored in the local frame buffer 224. In normal operation, display 110 drives LCD device 216 based on the video signals received from parallel processing subsystem 112 over communication path 280. Conversely, when display 110 is operating in a panel self-refresh mode, display 110 drives LCD device 216 based on the video signals received from SRC 220.

GPU 240 can be configured to manage display 110 to convert to a panel self-refresh mode or to switch away from a panel self-updating mode. Ideally, operating the display 110 in a panel self-refresh mode during a graphical inactivity period may reduce the overall power consumption of the computer system 100. In a specific embodiment, in order to cause the display 110 to enter a panel self-refresh mode, the GPU 240 can transmit a message to the display 110 using an in-band signaling method, such as embedding a message in the digital video signals and then communicating. Path 280 is transmitted. In other embodiments, GPU 240 may transmit the message using a sideband signaling method, such as transmitting the message using an auxiliary communication channel. Figures 2B through 2D illustrate various signaling methods for signaling to display 110 to enter or leave a panel self-refresh mode.

Returning now to FIG. 2A, after receiving the message to enter the self-updating mode, display 110 caches the next pixel data frame received over communication path 280 in local frame buffer 224. Based on the pixel data stored in the local frame buffer 224, the display 110 converts the video signals generated by the GPU 240 that control the driving of the LCD device 216 to the video signals generated by the SRC 220. When the display 110 is in the panel self-refresh mode, the SRC 220 generates repeated video signals representative of the cached pixel data stored in the local frame buffer 224 for one or more consecutive video frames.

In order for display 110 to exit the panel self-refresh mode, GPU 240 transmits a similar message to display device 110, as in the foregoing similar manner that causes display 110 to enter the panel self-refresh mode. After receiving the message to leave the panel self-updating mode, the pixel locations associated with the video signals generated by GPU 240 and the SRC 220 associated with the LCD device 216 currently being used in the panel self-refresh mode The resulting pixel locations of the video signals produced, display 110 can be arranged to ensure that the two are aligned with each other. Once the pixel locations are aligned, the display can convert the video signals generated by the SRC 220 that control the driving of the LCD device 216 to the video signals generated by the GPU 240.

The amount of storage required to implement a self-updating capability may be based on the size of the uncompressed video frame used to continuously update the image on display 110. In one embodiment, display 110 includes a single local frame buffer 224(0) sized to receive an uncompressed pixel data frame on LCD device 216. The size of the frame buffer 224(0) may be based on the minimum number of bytes required to store an uncompressed pixel data frame to be displayed on the LCD device 216, which is the color depth of the resolution of the LCD device 216 itself. Multiply the result by the width multiplied by the height. For example, the size of the frame buffer 224(0) can be used to set an LCD device 216 with a WUXGA resolution (1920 x 1200 pixels) and a color depth of 24 bits per pixel (bpp). In this example, the amount of memory available in the local frame buffer 224(0) for self-updating pixel data cache must have at least 6750 kB of addressable memory (1920 ^* 1200 ^* 24 bpp; where 1 kb is equal to 1024 or 2 ¹⁰ bytes).

In another embodiment, the local frame buffer 224(0) may be smaller than the number of bytes needed to store an uncompressed pixel data frame to be displayed on the LCD device 216. In this example, the uncompressed pixel data frame can be compressed by the SRC 220, for example by encoding the run length of the uncompressed pixel data, and stored in the frame buffer 224(0) as compressed pixel data. In such a particular embodiment, SRC 220 can be configured to be generated for driving LCD device 216 The compressed video data is decoded before the video signals. In other embodiments, GPU 240 may compress the pixel data frame and then encode the compressed pixel data to transmit the digital video signal to display 110. For example, GPU 240 can be configured to encode the pixel data using an MPEG-2 format. In such a particular embodiment, SRC 220 may store the compressed pixel data in local frame buffer 224(0) in the compressed format and decode the compressed pixel prior to generating the video signals for driving LCD device 216. data.

Display 110 is capable of displaying 3D video data, such as stereoscopic video material. The stereoscopic video material includes a left view and a right view of the uncompressed pixel data of each 3D video frame. Each view is a picture that is captured at the same time for the same scene from different camera positions. Some displays are capable of displaying three or more views simultaneously, such as in certain types of autostereoscopic displays.

In one embodiment, display 110 can include a self-updating capability that is coupled to the stereoscopic video material. Each frame of the stereoscopic video material includes two uncompressed pixel data frames to be displayed on the LCD device 216. Each uncompressed pixel data frame can include pixel data at full resolution and color depth of the LCD device 216. In this particular embodiment, the local frame buffer 224(0) is sized to hold a frame of stereoscopic video material. For example, to store WUXGA resolution and uncompressed stereoscopic video data at 24 bpp color depth, the local frame buffer 224(0) must be at least 13500 kB of addressable memory (2 ^* 11920 ^* 1200 ^* 24 bpp) ). In addition, the local frame buffer 224 can include two frame buffers 224(0) and 224(1), each of which can store a single view of one of the uncompressed pixel data to be displayed on the LCD device 216. .

In still other embodiments, the SRC 220 can be configured to compress the stereoscopic video material and store the compressed stereoscopic video material in the local frame buffer 224. For example, the SRC 220 can compress the stereoscopic video material using Multiview Video Coding (MVC) as specified in the H.264/MPEG-4 AVC Video Compression Standard. In addition, the GPU 240 may first compress the stereoscopic video data and encode the digital video signals for transmission to the display 110. Compress video data.

In one embodiment, display 110 can include a dithering capability. The perturbation may allow display 110 to display more perceptible colors that exceed the hardware display specifications of LCD device 216. The temporal perturbation rapidly alternates the color of one pixel between two approximate colors in a color palette that can be used by the LCD device 216 such that the pixel is perceived as not being included in the usable color palette of the LCD device 216. A different color. For example, by rapidly alternating a pixel between white and black, the viewer can perceive it as gray. In a normal operating state, GPU 240 can be arranged to alternate pixel data in successive video frames such that the perceived colors in the image displayed by display 110 are available in the color palette of LCD device 216. Outside the scope. In a self-updating mode, display 110 can be configured to cache two consecutive frames of pixel data in local frame buffer 224. The SRC 220 can then be arranged to scan all of the two pixel data frames from the local frame buffer 224 in an alternating manner to produce the video signals to be displayed on the LCD device 216.

FIG. 2B illustrates a communication path 280 implementing an embedded DisplayPort interface in accordance with an embodiment of the present invention. Embedded DisplayPort (eDP) is a standard digital video interface for internal displays, such as an internal LCD device in a laptop. Communication path 280 includes a primary link (eDP) that includes 1, 2 or 4 differential pairs (routes) for high frequency wide data transmission. The eDP interface also includes a panel enable signal (VDD), a backlight enable signal (Backlight_EN), a backlight pwm signal (Backlight_PWM), and a hot plug detection signal (HPD, Hot-plug detect) and a single Differential pairing auxiliary channel (Aux). The master is coupled to a one-way communication channel from GPU 240 to display 110. In one embodiment, GPU 240 can be configured to transmit video signals generated from pixel data stored in frame buffer 244 over a single route of the eDP master. In other embodiments, GPU 240 can be configured to transmit the video signals over 2 or 4 routes of the eDP master link.

The panel enable signal VDD can be connected from the GPU to the display 110 to be turned on. The power source in display 110. The backlight enable and backlight pwm signals control the intensity of the backlight in display 110 during normal operation. However, when display 110 is operating in a panel self-refresh mode, control of these signals must be managed by TCON 210 and changed by SRC 220 based on control signals received on the auxiliary communication channel (Aux). Those skilled in the art will appreciate that the backlight intensity can be controlled by pulse width modulation based on the backlight pwm signal (Backlight_PWM). In some embodiments, communication path 280 can also include a frame lock signal (FRAME_LOCK) that represents a vertical sync in the video signals generated by SRC 220. The FRAME_LOCK signal can be used to resynchronize the video signals generated by GPU 240 with the video signals generated by SRC 220.

The hot plug detection signal HPD can be a signal that is coupled to the GPU 240 by the display 110 for detecting a hot plug event or for transmitting an interrupt request by the display 110 to the GPU 240. To represent a hot plug event, the display sets the hot plug detect signal HPD to a high level to indicate that a display has been connected to the communication path 280. After the display is connected to the communication path 280, the display 110 can quickly set the hot plug detection signal HPD to a low level between 0.5 and 1 microsecond to issue an interrupt request.

The auxiliary channel Aux is a low frequency wide bidirectional half duplex data communication channel for transmitting command and control signals from the GPU 240 to the display 110 and from the display 110 to the GPU 240. In one embodiment, a message representative of display 110 having to enter or leave a panel self-refresh mode may be passed over the auxiliary channel. On the auxiliary channel, GPU 240 is a master device and display 110 is a slave device. In this configuration, the material or message can be transmitted from display 110 to GPU 240 using the following techniques. First, display 110 indicates to GPU 240 that display 110 transmits a message over the auxiliary channel by initiating an interrupt request above the hot plug detection signal HPD. When GPU 240 detects an interrupt request, GPU 240 transmits a transaction request message to display 110. Once the display 110 receives the transaction request message, the display 110 returns You should know the message. Once GPU 240 receives the notification message, GPU 240 can read one or more register values in display 110 to retrieve the data or message over the auxiliary channel.

Those skilled in the art will appreciate that communication path 280 can be implemented as a different video interface for transmitting video signals between GPU 240 and display 110. For example, the communication path 280 can be implemented as a high definition multimedia interface (HDMI) or a low voltage differential signaling (LVDS) video interface, such as open-LDI. The scope of the invention is not limited to an embedded DisplayPort video interface.

2C is a conceptual diagram of digital video signal 250 generated by GPU 240 transmitted over communication path 280, in accordance with an embodiment of the present invention. As shown, the digital video signal 250 is formatted for transmission over the four routes (251, 252, 253, and 254) of the primary connection of an eDP video interface. The master link of the eDP video interface can operate with one of three link symbol clock rates as specified by the eDP specification (162 MHz, 270 MHz or 540 MHz). In one embodiment, when a display 110 is coupled to the communication path 280, the GPU 240 sets the coupled symbol clock rate based on a joint training job that is executed to set the primary link. For each associated symbol clock cycle 255, 8b/10b encoding is used to encode one of the one-tuple 10-bit symbols of the data or control information and transmitted on each enabled route of the eDP interface.

The format of the digital video signal 250 enables the secondary data packet to be embedded directly into the digital video signal 250 that is transmitted to the display 110. In one embodiment, the secondary data packets may include messages transmitted from GPU 240 to display 110 that require display 110 to enter or exit a panel self-updating mode. These secondary data packets enable one or more aspects of the present invention to be implemented over the existing physical layer of the eDP interface. However, such embedded signal transmission can also be implemented in other packetized video interfaces, and is not limited to implementing a specific embodiment of an eDP interface.

The secondary data packet can be represented by the video signal represented by the digital video signal 250 The vertical or horizontal blank periods of the frame are embedded in the digital video signal 250. As shown in FIG. 2C, the digital video signal 250 is packed with a horizontal line of pixel data at a time. For each horizontal line of pixel data, the digital video signal 250 includes a blank start (BS) symbol during a first link clock cycle 255 (00), and a subsequent clock cycle of 255 (for a subsequent link). The 05) period includes a corresponding blank end (BE, Blanking end) framed symbol. The portion of the digital video signal 250 between the BS symbol at the coupled symbol clock cycle 255 (00) and the BE symbol at the associated symbol clock cycle 255 (5) corresponds to the horizontal blank period.

The control symbols and secondary data packets may be embedded in the digital video signal 250 during the horizontal blank period. For example, a VB-ID symbol is inserted after the BS symbol in the first joint symbol clock cycle 255 (01). The VB-ID symbol provides information about the display 110, for example, whether the primary video stream is in the vertical blank period or the vertical display period, whether the main video stream is an interlaced or sequential scan, and whether the primary video stream is The range of the double or odd range of the interlaced video. Immediately behind the VB-ID symbol, a video time stamp (Mvid7:0) and an audio time stamp (Maud7:0) can be individually embedded at the joint symbol clock cycles 255(02) and 255(03). During this horizontal blank period, dummy symbols may be embedded in the remaining periods of the associated symbol clock cycle 255 (04). The virtual symbol can be a specially reserved symbol representing that the embedded data is virtual material during the clock cycle of the linked symbol. The junction symbol clock cycle 255(04) may have a duration of some coupled symbol clock cycles such that the frame rate of the digital video signal 250 over the communication path 280 is equal to the update rate of the display 110.

During the joint symbol clock cycle 255 (04), the primary data packet can be embedded in the digital video signal 250 instead of the complex virtual symbol. A secondary data packet is framed by the special secondary start (SS, Secondary start) and secondary end (SE, Secondary end) framed symbols. The secondary data packet may include an audio data packet, link configuration information, or require display 110 to enter Or leave a message in a panel update mode.

The BE frame symbol is embedded in the digital video signal 250 to represent the beginning of the enabled pixel data of a horizontal line of the current video frame. As shown, the pixel data P0...PN has an RGB format of 8-bit per channel bit depth (bpc). The pixel data P0 of the first pixel associated with the horizontal line of the video is wrapped into the first path 251 at the symbol loop 255 (06) to 255 (08) of the symbol symbol rearward. The first portion of the pixel data P0 associated with the red channel is inserted into the first path 251 at the junction symbol clock cycle 255 (06), and the second portion of the pixel data P0 associated with the green channel is coupled. The symbol clock cycle 255 (07) is inserted into the first route 251, and the third portion of the pixel data P0 associated with the blue channel is inserted into the first symbol at the clock cycle 255 (08). In route 251. The pixel data P1 of the second pixel associated with the horizontal line of the video is packaged into the second route 252 at the joint symbol clock cycle 255 (06) to 255 (08), associated with the third pixel of the horizontal line of the video. The pixel data P2 is packed into the third route 253 at the joint symbol clock cycle 255 (06) to 255 (08), and the pixel data P3 of the fourth pixel associated with the horizontal line of the video is coupled to the symbol clock cycle 255. (06) to 255 (08) are packed into the fourth route 254. Subsequent pixel data of the horizontal line of the video is inserted into the routes 251-254 to pixel data P0 to P3 in a similar manner. In the last symbolic clock cycle that includes the valid pixel data, any unfilled routes can be filled with zeros. As shown, the third route 253 and the fourth route 254 may be filled with zeros at the joint symbol clock cycle 255 (13).

Starting from the pixel data of the uppermost horizontal line, the aforementioned data sequence is repeatedly presented for the pixel data of each horizontal line in the video frame. A video frame may include some horizontal lines above the frame that do not include enabled pixel data to be displayed on display 110. These horizontal lines contain the vertical blank period and are indicated in the digital video signal 250 by setting a bit in the VB-ID control symbol.

2D is a conceptual diagram of embedding a primary data packet 260 in a horizontal blank period of the digital video signal 250 of FIG. 2C in accordance with an embodiment of the present invention. A secondary data packet 260 can be embedded in the digital video signal 250 instead of a portion of the plurality of virtual symbols in the digital video signal 250. For example, the 2D graph shows the complex virtual symbols at the junction symbol clock cycles 265 (00) and 265 (04). GPU 240 may embed a level of start (SS) framed symbol at junction symbol clock cycle 265 (01) to indicate the beginning of primary data packet 260. This material associated with secondary data packet 260 is embedded at junction symbol clock cycle 265 (02). Each tuple of the data (SB0...SBN) associated with the secondary data packet 260 is embedded in one of the routes 251-254 of the digital video signal 250. Any time slot that is not filled with data can be filled with zeros. The GPU 240 then embeds the primary end (SE) framed symbol at the associated symbol clock cycle 265 (03).

In one embodiment, the secondary data package 260 can include a header and data to indicate that the display 110 must enter or leave a self-updating mode. For example, secondary data packet 260 can include a reserved header code to indicate that the packet is a panel self-updating packet. The secondary data packet may also include data to indicate whether the display 110 must enter or leave a panel self-refresh mode.

As described above, GPU 240 can transmit a message to display 110 via an in-band signaling method that uses digital communication channel 250 to transmit digital video signal 250 to display 110. In other embodiments, GPU 240 may transmit a message to display 110 via a sideband method, such as by using the auxiliary communication channel in communication path 280. Other embodiments may additionally include a dedicated communication path, such as an additional cable, for providing a signal to display 110 to enter or exit the panel self-refresh mode.

Figure 3 illustrates communication signals between the parallel processing subsystem 112 of the computer system 100 and a plurality of components in accordance with an embodiment of the present invention. As shown, the computer system 100 includes an embedded controller (EC), an SPI flash device 320, and a system basic input/output system (SBIOS, System basic input/output system 330, and a driver 340. The EC 310 can be an embedded controller that employs an advanced configuration and power interface (ACPI) that allows an operating system executing on the CPU 102 to set and control various components of the computer system 100. Power management. In a specific embodiment, the EC 310 allows the operating system executing on the CPU 102 to be coupled to the GPU 240 via the driver 340 even when the PCIe bus is off. For example, if GPU 240 and PCIe bus are turned off in a power save mode, the operating system executing on CPU 102 can transmit a notification ACPI event to EC 310 via driver 340 to instruct EC 310 to wake up GPU 240.

The computer system 100 can also include a plurality of displays 110, such as an internal display panel 110(0) and one or more external display panels 110(1), 110(N). Each of the one or more displays 110 can be coupled to GPU 240 via communication paths 280(0)...280(N). In one embodiment, each HPD signal included in communication path 280 is also coupled to EC 310. When the one or more displays 110 are operating in a panel self-refresh mode, the EC 310 can be responsible for monitoring the HPD if the EC 310 detects a hot plug event or an interrupt request from one of the displays 110 With wake up GPU 240.

In a specific embodiment, a FRAME_LOCK signal is included between internal display 110(0) and GPU 240. FRAME_LOCK transmits a synchronization signal to GPU 240 by display 110(0). For example, GPU 240 can synchronize the video signal generated by the pixel data in frame buffer 244 with the FRAME_LOCK signal. The FRAME_LOCK may indicate the start of the enable frame, such as by transmitting the TCON 210 to drive the vertical sync signal of the LCD device 216 to the GPU 240.

The EC 310 transmits the GPU_PWR and FB_PWR signals to a voltage regulator that provides a supply voltage to the GPU 240 and the frame buffer 244, respectively. The EC 310 also transmits the WARMBOOT, SELF_REF and RESET signals to the GPU 240 and receives a GPUEVENT signal from the GPU 240. most The EC 310 can then communicate with the GPU 240 via an I2C or SMBus data bus. The functionalities of these signals are described below.

The GPU_PWR signal controls the voltage regulator to provide a supply voltage to the GPU 240. When the display 110 enters a self-updating mode, an operating system executing on the CPU 102 can instruct the EC 310 to place a call to the drive 340 to stop powering it to the GPU 240. Driver 340 will then drive the GPU_PWR signal low to stop powering to GPU 240, thereby reducing the overall power consumption of computer system 100. Similarly, the FB_PWR signal controls the voltage regulator to provide a frame buffer 244 to supply voltage. When the display 110 enters the self-updating mode, the computer system 100 can also stop supplying power to the frame buffer 244, thereby further reducing the overall power consumption of the computer system 100. The FB_PWR signal is controlled in a manner similar to the GPU_PWR signal. During wake-up of GPU 240, the RESET signal can be set to keep GPU 240 in a reset state, while the voltage regulators that provide power to GPU 240 and frame buffer 244 are allowed to stabilize.

The WARMBOOT signal is set by the EC 310 to indicate that the GPU 240 must be restored by the SPI flash device 320 to an operational state rather than performing a complete cold start sequence. In one embodiment, when display 110 enters a panel self-refresh mode, GPU 240 may store a current state in SPI flash device 320 before being powered down. Upon being woken up, GPU 240 can load the stored status information from SPI flash device 320 to resume to an operational state. Loading the stored status information may reduce the time required to wake up GPU 240 relative to performing a complete cold boot sequence. Reducing the time required to wake up GPU 240 is beneficial during high frequency entry and exit from a panel self-updating mode.

The SELF_REF signal is set by the EC 310 when the display 110 is operating in a panel self-refresh mode. The SELF_REF signal is directed to GPU 240: display 110 is currently operating in a panel self-refresh mode, and communication path 280 must be isolated to prevent transient interruption of data stored in local frame buffer 224. In a specific embodiment, when the SELF_REF letter When the number is set, GPU 240 can connect communication path 280 to ground via a weak pull-down resistor.

This GPUEVENT signal can allow GPU 240 to indicate to the CPU 102 that an event has occurred, even when the PCIe bus is off. GPU 240 can set the GPUEVENT to alert system EC 310 to set up the I2C/SMBUS to initiate communication between GPU 240 and system EC 310. The I2C/SMBUS is a two-way communication bus that is configured as an I2C, SMBUS or other two-way communication bus to provide communication between the GPU 240 and the system EC 310. In one embodiment, the PCIe busbar can be turned off when the display 110 is operating in a panel self-refresh mode. Even when the PCIe bus is off, the operating system can notify the GPU 240 via the system EC 310 that an event, such as a cursor update or a screen update event, occurs.

4 is a state diagram 400 of a display 110 having a self-updating capability in accordance with an embodiment of the present invention. As shown, display 110 begins in a normal state 410. In the normal state 410, the display receives video signals from GPU 240. The TCON 210 drives the LCD device 216 using the video signals received from the GPU 240. In this normal operating state, display 110 monitors communication path 280 to determine if GPU 240 has issued a panel self-update entry request. If display 110 receives the panel self-update entry request, display 110 transitions to a wake-up frame buffer state 420.

In the wake frame buffer state 420, the display 110 wakes up the local frame buffer 224. If display 110 is unable to initialize local frame buffer 224, display 110 may transmit an interrupt request to GPU 240 indicating that display 110 is unable to enter the panel self-updating mode and display 110 returns to normal state 410. In one embodiment, display 110 may need to initialize the local frame buffer before the next video frame is received over communication path 280 (ie, before the next rising edge of the VSync signal generated by GPU 240). 224. Once display 110 has completed initializing local frame buffer 224, display 110 transitions to a fast frame state 430.

In the fast frame state 430, upon the next falling edge of the VSync signal generated by GPU 240, display 110 begins fetching one or more video frames in local frame buffer 224. In one embodiment, GPU 240 can write a value to a control register in display 110 to indicate how many consecutive video frames are to be stored in local frame buffer 224. After the display has stored the one or more video frames in the local frame buffer 224, the display 110 transitions to a self-updating state 440.

In the self-updating state 440, the display 110 enters a panel self-refresh mode in which the TCON 210 drives the LCD device 216 using the video signals generated by the SRC 220 based on the pixel data stored in the local frame buffer 224. Display 110 stops driving LCD device 216 based on the video signals generated by GPU 240. GPU 240 and communication path 280 can then be placed in a power save mode to reduce the overall power consumption of computer system 100. When in the self-updating state 440, the display 110 can monitor the communication path 280 to detect a panel self-refresh mode leaving request from the GPU 240. If display 110 receives a panel self-refresh request, display 110 transitions to a resynchronization state 450.

In resynchronization state 450, display 110 attempts to resynchronize the video signals generated by GPU 240 with the video signals generated by SRC 220. A variety of techniques for resynchronizing the video signals are described below in conjunction with Figures 9A-9C and 10-13. When display 110 has completed resynchronizing the video signals, display 110 transitions back to a normal state 410. In one embodiment, display 110 will cause local frame buffer 224 to transition to a local frame buffer state 460 where the power supplied to local frame buffer 224 is turned off.

In one embodiment, display 110 may be configured to quickly exit wake-up buffer state 420 and fast frame state 430 upon receipt of an exit panel self-update request. In both of these states, display 110 is still synchronized to the video signals generated by GPU 240. Therefore, the display 110 can be fast The ground transitions back to the normal state 410 without entering the resynchronization state 450. Once in the self-updating state 440, the display 110 needs to enter the resynchronization state 450 before returning to the normal state 410.

FIG. 5 is a state diagram 500 of a GPU 240 configured to control a display 110 to enter and exit a panel self-refresh mode, in accordance with an embodiment of the present invention. After initial configuration via a cold boot sequence, GPU 240 enters a normal state 510. In this normal state, GPU 240 generates a video signal that is transmitted to display 110 based on the pixel data stored in frame buffer 244. In one embodiment, GPU 240 monitors pixel data in frame buffer 244 to detect one or more progressive levels of idleness in the pixel data. For example, GPU 240 can compare the current pixel data frame in frame buffer 244 with the previous pixel data frame in frame buffer 244 to detect any graphical activity in the pixel data. If the pixel data is different between the two frames, graphics activity can be detected. In other embodiments, GPU 240 may detect the progressive level of idleness based on a factor other than the comparison of consecutive pixel data frames in frame buffer 244. If GPU 240 is unable to detect any graphics activity in the pixel data stored in frame buffer 244, GPU 240 may increment a counter to indicate the number of consecutive video frames that do not have any graphics activity. If the counter reaches a first threshold, GPU 240 transitions to a deep idle state 520.

In the deep idle state 520, the GPU 240 still produces a video signal for display on the display 110. However, GPU 240 operates in a power saving mode, such as by clock gating or power gating of certain processing portions of GPU 240, while maintaining portions of GPU 240 responsible for generating such enabled video signals. In addition, GPU 240 can transmit a message to display 110, requiring display 110 to drive LCD device 216 at a lower update rate. For example, GPU 240 may require display 110 to reduce the update rate from 75 Hz to 30 Hz, and GPU 240 may generate and transmit a video signal based on the lower update rate. GPU 240 may continue to monitor pixels in frame buffer 244 when operating in deep idle state 520 Graphical activity of the data. If GPU 240 detects a graphical activity, GPU 240 transitions back to normal state 510. In the deep idle state 520, GPU 240 may continue to increment the counter to determine the number of consecutive video frames that do not have any graphics activity. If the counter reaches a second threshold greater than the first threshold, GPU 240 transitions to a panel self-updating state 530.

In some embodiments, state diagram 500 does not include deep idle state 520. In these particular embodiments, when the counter reaches the second threshold, GPU 240 can transition directly from the normal state to the panel self-updating state 530. In still other embodiments, the EC 310, the graphics driver 103, or some other dedicated monitoring unit can monitor the pixel data in the frame buffer 244 and transmit a message to the GPU 240 over the I2C/SMBUS to indicate that One of the progressive levels of idleness detected.

In the panel self-updating state 530, the GPU 240 transmits the one or more video frames to be displayed to the display 110 during the panel self-updating mode. GPU 240 can monitor communication path 280 to detect if display 110 is unable to successfully enter the self-updating mode. In one embodiment, GPU 240 monitors the HPD signal to detect an interrupt request issued by display 110. If GPU 240 detects an interrupt request from display 110, GPU 240 may set the auxiliary channel of communication path 280 to receive communications from display 110. If display 110 indicates that entering the self-updating mode was not successful, GPU 240 may transition back to normal state 510. Otherwise, GPU 240 transitions to a deeper idle state 540. In another embodiment, GPU 240 may refuse to transition to a deeper idle state 540 and transition directly to GPU power off state 550. In these particular embodiments, GPU 240 will be fully powered down, regardless of whether display 110 enters a panel self-refresh mode.

In the deeper idle state 540, the GPU 240 can be placed in a sleep state and the transmitter side of the communication path 280 can be closed. Portions of GPU 240 may be clocked or power gated to reduce overall power consumption of computer system 100. Display 110 is responsible for updating the image displayed by display 110. In one In an embodiment, GPU 240 may continue to monitor the pixel data in frame buffer 244 to detect a level 3 idle. For example, when the pixel data in the frame buffer 244 cannot be updated, the GPU 240 can continue to increment the counter of each video frame. If GPU 240 detects graphics activity, such as by receiving a signal from EC 310 over I2C/SMBUS or receiving a signal from graphics driver 103 over the PCIe bus, GPU 240 transitions to resynchronization state 560. Conversely, if GPU 240 detects a level 3 idle in the pixel data, GPU 240 transitions to a GPU power off state 550.

In GPU power off state 550, EC 310 may turn off the voltage regulator that supplies power to GPU 240, thereby turning off GPU 240. The EC 310 can drive the GPU_PWR signal low to turn off the regulator supply GPU 240. In one embodiment, GPU 240 can store the current operational content in SPI flash device 320 to perform a warm boot procedure upon wake-up. In GPU power off state 550, a voltage regulator that supplies power to graphics memory 242 is also turned off. The EC 310 can drive the FB_PWR signal low to turn off the regulator supply graphics memory 242.

When GPU 240 is in a deeper idle state 540 or GPU power off state 550, GPU 240 may be instructed to wake up by EC 310 to update the image being displayed on display 110. For example, a user of computer system 100 can begin typing into an application that requires GPU 240 to update the image displayed on the display. In one embodiment, the driver 340 can instruct the EC 310 to set the GPU_PWR and FB_PWR signals to turn on the regulators to supply the GPU 240 and the frame buffer 244. When GPU 240 is turned on, GPU 240 will perform a boot sequence based on the state of the WARMBOOT signal and the RESET signal. If EC 310 sets the WARM_BOOT signal, GPU 240 can load a stored content from SPI flash device 320. Otherwise GPU 240 can perform a cold boot sequence. GPU 240 may also set the transmitter side of communication path 280 based on information stored in SPI flash device 320. After performing the boot sequence, GPU 240 can transmit a panel from the update request to the display The instructions are loaded for execution by the PMU 610. The instructions included in code 640, when executed by PMU 610, cause PMU 610 to set at least a portion of the operational state of GPU 240. These instructions can be hardwired to the integrated circuitry of GPU 240, such as a mask ROM, and are referred to by the skilled artisan as a bootstrap loader. Once the instructions included in code 640 have been executed, GPU 240 may be configured to receive material and instructions from graphics driver 103 via communication path 113, which when executed by PMU 610 causes PMU 610 to set one of the operational states of GPU 240. In two portions, GPU 240 is configured to receive graphics data and instructions from graphics driver 103 via communication path 113 and to generate video signals for display on display 110.

In a conventional system, various components of computer system 100 can be initialized in a serialized manner during a cold boot initialization procedure. For example, communication path 113 may be fully initialized to complete initialization of GPU 240 before GPU 240 receives the material and instructions from graphics driver 103. However, initialization of the communication path 113 may take a lot of time, thus increasing the latency between the need to wake up the GPU 240 to generate updated pixel data and to update an image being displayed on the display 110. For example, the initialization procedure for a PCIe bus may take up to 70-100 ms to complete. Because GPU 240 is unable to initialize, until the data and instructions are received from graphics driver 103 via communication path 113, GPU 240 is forced to wait until communication path 113 is fully set.

In order to minimize the time between when the initialization process begins and when the GPU 240 enters a normal operating state, initialization procedures associated with various components of the computer system 100 can be performed in parallel such that initialization of the GPU 240 does not require waiting for a communication path. 113 is completely set up. In one embodiment, the boot loader in code 640 can enable GPU 240 to communicate with EC 310 via I2C/SMBUS. GPU 240 can be configured to receive data and instructions from I2C/SMBUS from driver 340, which when executed by PMU 610 causes PMU 610 to set a second portion of the operational state of GPU 240, such that the GPU 240 is arranged to receive graphics data and instructions from graphics driver 103 via communication path 113 and to generate video signals for display on display 110. Therefore, the initialization of the GPU 240 and the communication path 113 is substantially simultaneous.

Once GPU 240 is fully set up, GPU 240 begins to generate a video signal to display on display 110 in response to graphics primitives and instructions received from graphics driver 103. At some point during this operation, GPU 240 may require display 110 to enter a panel self-refresh mode, enabling GPU 240 to enter a deep sleep state to minimize power consumption during extended periods of no graphics activity. In one embodiment, when the display 110 is operating in a panel self-refresh mode, the graphics driver 103 can be used to store the current operational state when the GPU 240 enters a deep sleep state (eg, a deeper idle state 540). For example, one or more values stored in the scratchpad file 630, as well as any other configuration information needed to fully define the current operational state of the GPU 240, such as the current counter value associated with each of the processing cores 620. , can be read by the graphics driver 103 and stored in the frame buffer 244. Alternatively, the information may be stored in other volatile or non-volatile memory accessible by graphics driver 103, such as system memory 104 or system disk 114. Once the current operational state of GPU 240 is stored, GPU 240 can transition to the deep sleep state.

In one embodiment, EC 310 may cause GPU 240 to be woken up when the image being displayed by display 110 needs to be updated. Upon waking up from the deep sleep state, GPU 240 may be configured to perform a warm boot initialization procedure instead of a full cold boot initialization procedure. Similar to the cold boot initialization procedure, the warm boot initialization procedure begins with the GPU 240 being set to read the boot loader in the code 640 for execution by the PMU 610. In a specific embodiment, the boot loader can cause the PMU 610 to check the WARMBOOT signal received from the EC 310. If the WARMBOOT signal is not set, then GPU 240 is set up in conjunction with the jobs described in the cold boot initialization procedure. However, if the WARMBOOT signal is set, GPU 240 110. GPU 240 then transitions to a resynchronization state 560.

In resynchronization state 560, GPU 240 begins generating video signals based on the pixel data stored in frame buffer 244. The video signals are transmitted to display 110 over communication path 280, and display 110 attempts to resynchronize the video signals generated by GPU 240 with the video signals generated by SRC 220. After the resynchronization of the video signals is complete, GPU 240 transitions back to normal state 510.

Graphics processing unit initialization example

Figure 6 illustrates various components of a graphics processing unit 240 in accordance with an embodiment of the present invention. As shown, GPU 240 includes a Power Management Unit (PMU) 610, one or more processing cores 620, a scratchpad file 630, and a code 640. PMU 610 is arranged to execute jobs for setting up multiple processing units in GPU 240. For example, PMU 610 can be configured to load a value into one or more registers in scratchpad file 630. The values loaded into the registers can be accessed by a transmitter interface of communication path 280 to cause GPU 240 to transmit data over communication path 280. The PMU 610 can also be configured to load values into an additional register in the scratchpad file 630 to load a stored operational state (i.e., a processing content) of the one or more processing cores 620. Although not described in detail, PMU 610 can be configured to perform other functions, such as initializing a receiving interface of communication path 113, or initializing one or more counters (not shown) in GPU 240.

In a normal cold boot initialization procedure, the EC 310 sets the GPU_PWR and FB_PWR signals and the RESET signal, as described above in conjunction with FIG. 3, which enables the supply of power to the GPU 240 and the memory 242. The device is turned on. The EC 310 continues to hold the RESET signal high for a short period of time to allow the supply voltage of the GPU 240 and the memory 242 to stabilize, and then the GPU 240 begins executing instructions when the RESET signal is pulled low by the EC 310.

Once the RESET signal transitions from high to low, GPU 240 is set to self-code 640 Set it up with a warm boot initialization program. The warm boot initialization routine can be set such that the PMU 610 checks for additional data and instructions in the SPI flash device 320 for setting up the GPU 240. As noted above, GPU 240 can be configured to store the current operational state (e.g., GPU state 660) in SPI flash device 320. Thus, in the warm boot initialization procedure, PMU 610 can be set to set the operational state of GPU 240 by GPU state 660. In contrast to performing a complete cold boot initialization procedure, loading a stored operational state representative of the operational state of GPU 240 prior to entering the deep sleep state may advantageously reduce initialization time.

In one embodiment, if the GPU 240 detects a difference in the physical configuration of the computer system 100 since the GPU 240 was placed in a deep sleep state, the warm boot initialization procedure can be aborted. When the WARMBOOT signal is set, the boot loader can be set such that the PMU 610 checks the GPU state 660 to determine if the physical configuration of the computer system 100 has changed. For example, GPU 240 can read the scratchpad in display 110 to check the EDID (Extended Display Identification Data) data to determine if display device 110 has changed since GPU 240 entered the deep sleep state. The PMU 610 can then calculate a checksum from the retrieved EDID data and compare the resulting value to a checksum stored in the GPU state 660, which is associated with the display 110 before the GPU 240 enters the deep sleep state. The EDID information. If the calculated check sum meets the checksum from GPU state 660, then PMU 240 may be configured to continue loading and executing the instructions from code 650 to perform the additional operations required to set up GPU 240. However, if the calculated checksum does not match the checksum from GPU state 660, the entity configuration representing computer system 100 may have changed, then PMU 610 may be set to abort the warm boot initialization procedure and execute Such operations associated with a complete cold boot initialization procedure are as described above.

In another embodiment, PMU 610 can be configured to minimize the number of updates to SPI flash device 320. The skilled person can understand that the flash memory is in The integrity of the memory may be corrupted by a limited number of program-erasing cycles (P/E cycles). For example, many conventional flash memory devices only guarantee the integrity of stored data within a 100,000 P/E cycle. If GPU 240 is set to erase and reprogram SPI flash device 320 each time GPU 240 is placed in a deep sleep state, SPI flash device 320 may eventually become unstable and GPU state 660 or code 650 may destroyed. Thus, upon entering a deep sleep state, GPU 240 may be configured to determine whether the current operational state of GPU 240 conforms to the operational state associated with GPU state 660. If the current operational state conforms to the operational state associated with GPU state 660, GPU 240 may be set to enter the deep sleep state without updating SPI flash device 320. However, if the current operational state does not conform to the operational state associated with GPU state 660, GPU 240 may reprogram SPI flash device 320 such that GPU state 660 may reflect the current operational state of GPU 240. Thus, a limited number of P/E cycles of the SPI flash device 320 will not run out prematurely, and the expected lifetime of the SPI flash device 320 can be extended beyond the expected life of the computer system 100.

In yet another embodiment, the code 650 can include a compression-decompression software (CODEC) that causes the PMU 610 to encode or decode instructions in the SPI flash device 320 when executed by the PMU 610. Or information. The memory requirements of the storage code 650 and the GPU state 660 may be quite large, such as 10-20 kilobytes (KB, kilobyte) or more. A significant portion of the time required to perform such operations associated with the warm boot initialization procedure is due to data transfer via an interface connecting the SPI flash device 320 to the GPU 240. To minimize the amount of data transferred over this interface, GPU 240 can be configured to store code 650 or GPU state 660 in a compressed format.

In these particular embodiments, PMU 610 can be configured to load the compression decompression software included in code 650 from SPI flash device 320 prior to storing the current operational state of GPU 240. In other embodiments, the compression decompression software can be directly wired in GPU 240. Then PMU 610 takes one The compressed format is written to GPU state 660 to SPI flash device 320. When the EC 310 causes the GPU 240 to leave the deep sleep state, the PMU 610 can execute the boot loader and load the compression decompression software from the code 650 or a memory on the wafer. GPU 240 may then restore GPU 240 to an operational state associated with GPU state 660 compressed in SPI flash device 320. For example, PMU 610 can read GPU state 660 from SPI flash device 320, decode GPU state 660, and load data from the uncompressed version of GPU state 660 to scratchpad file 630 or other memory associated with GPU 240. in. In one embodiment, the compression decompression software can compress the GPU state 660 using operational length coding. In other embodiments, the compression decompression software may use any other technically feasible compression algorithm known in the art.

FIG. 7 provides a flow diagram of a method 700 for setting a graphics processing unit 240 in accordance with an embodiment of the present invention. Although the method steps are described in conjunction with the systems of Figures 1, 2A through 2D, and Figures 3 through 6, those skilled in the art will appreciate that the methods are arranged to perform in any order. Any system of steps is within the scope of the invention.

The method begins in step 710, where GPU 240 executes a boot loader stored in one of the memories associated with the GPU. In one embodiment, the boot loader is included in code 640 and is hardwired into the integrated circuitry of GPU 240. The boot loader can set GPU 240 to load and execute additional instructions received from graphics driver 103 or SPI flash device 320. In step 712, GPU 240 determines if a WARMBOOT signal is set by EC 310. As explained above in connection with Figure 3, the WARMBOOT signal indicates whether the GPU 240 must perform a quick reply job, such as a warm boot initialization procedure. If the WARMBOOT signal is not set, then method 700 proceeds to step 714 where GPU 240 performs a complete cold boot initialization procedure. In one embodiment, GPU 240 receives data and instructions from graphics driver 103 via communication path 113. In other embodiments, GPU 240 receives funding from driver 340 via I2C/SMBUS connecting GPU 240 to EC 310. 240 may be arranged to process graphics primitives received from graphics driver 103 to generate pixel data stored in frame buffer 244 for rendering. The GPU 240 then generates the digital video signals based on the rendered pixel data in the frame buffer 244, and the method 800 terminates.

FIG. 9 provides a flow diagram of a method 900 for performing a fast warm-up initialization procedure of a graphics processing unit 240 in accordance with an embodiment of the present invention. Although the method steps are described in conjunction with the systems of Figures 1, 2A through 2D, and Figures 3 through 6, those skilled in the art will appreciate that the methods are arranged to perform in any order. Any system of steps is within the scope of the invention.

The method begins in step 910 with GPU 240 taking one or more instructions from non-volatile memory connected to GPU 240. In one embodiment, the one or more instructions are fetched from code 650 in SPI flash device 320 and are configured to cause GPU 240 to perform one or more of the warm boot initialization procedures, such as determining SPI fast. A location of a GPU state 660 is stored in flash device 320. In other embodiments, the one or more instructions can be hardwired to the on-wafer ROM within GPU 240. In step 912, GPU 240 executes the one or more instructions fetched from non-volatile memory. In step 914, GPU 240 determines whether the physical configuration of computer system 100 has changed since GPU 240 entered a deep sleep state. For example, GPU 240 can be configured to check if a new display is already connected to computer system 100. In one embodiment, when GPU 240 enters the deep sleep state, GPU 240 can read a checksum value stored in SPI flash device 320, which is related to the previous physical configuration of computer system 100. The GPU 240 then calculates a checksum sum for one of the current physical configurations of one of the computer systems 100 when the GPU 240 leaves the deep sleep state. If the stored checksum value matches the calculated checksum value, GPU 240 determines that the physical configuration of computer system 100 has not changed, and method 900 proceeds to step 918. However, if the stored checksum value does not match the calculated checksum value, GPU 240 determines the computer Materials and instructions. GPU 240 sets an operational state of GPU 240 based on the data and instructions received from the software driver. Returning now to step 712, if the WARMBOOT signal is set, then the method 700 proceeds to step 716 where the GPU 240 performs a fast warm-up initialization procedure. In one embodiment, GPU 240 is configured to automate a non-volatile memory load of data and instructions coupled to GPU 240, such as from SPI flash device 320. GPU 240 sets an operational state of GPU 240 based on the data and instructions received from the non-volatile memory.

FIG. 8 provides a flow diagram of a method 800 for performing a cold boot initialization procedure of a graphics processing unit 240 in accordance with an embodiment of the present invention. Although the method steps are described in conjunction with the systems of Figures 1, 2A through 2D, and Figures 3 through 6, those skilled in the art will appreciate that the methods are arranged to perform in any order. Any system of steps is within the scope of the invention.

The method begins in step 810, where GPU 240 receives data and instructions from a software driver to set an operational state of GPU 240. In one embodiment, GPU 240 receives the data and instructions from graphics driver 103 via communication path 113. In such a particular embodiment, GPU 240 must wait until communication path 113 is fully initialized by computer system 100 before GPU 240 can receive the data and instructions from graphics driver 103. In other embodiments, GPU 240 may receive data and instructions via an I2C/SMBUS self-driver 340 that connects GPU 240 to EC 310. In these embodiments, the cold boot initialization routine can be performed in parallel with initialization of other hardware components of computer system 100, such as communication path 113. . In step 812, GPU 240 can direct the instructions to PMU 610 for execution. The executed instructions may be arranged to set an operational state of GPU 240, such as by writing a value defined in the received data to a register in scratchpad file 630. The executed instructions may cause PMU 610 to set up other aspects of GPU 240 and, for example, initialize one or more counters associated with GPU 240. In step 814, GPU 240 begins generating a digital video signal for display on display 110. GPU The physical configuration of system 100 has changed, and method 900 proceeds to step 916 where GPU 240 suspends the warm boot initialization routine and executes a full cold boot initialization routine, such as the initialization procedure described above in conjunction with method 800.

Returning now to step 918, GPU 240 takes a stored operational state from a memory connected to GPU 240. In one embodiment, the instructions fetched in step 910 are set such that PMU 610 loads GPU state 660 from SPI flash device 320. In other embodiments, GPU state 660 can be loaded from other memory, such as frame buffer 244 or system memory 104. In step 920, GPU 240 can set the current operational state of GPU 240 to reflect the stored operational state retrieved from the non-volatile memory. In one embodiment, the PMU 610 is configured to read the stored operational state from the SPI flash device 320 and write one or more values associated with the stored operational state to the scratchpad file 630. One or more registers. In step 922, the GPU begins generating digital video signals for display on display 110. GPU 240 may be arranged to process graphics primitives received from graphics driver 103 to generate pixel material that is colored in frame buffer 244. The GPU 240 can then generate the digital video signals based on the rendered pixel data in the frame buffer 244, and the method 900 terminates.

In summary, the disclosed technology management is coupled to the configuration of a graphics processing unit of one of the displays having self-updating capabilities. This technique utilizes a full cold boot initialization procedure when the computer system is initially powered on. Moreover, the technique is used when the graphics processing unit detects that the physical configuration of the computer system has changed when leaving a deep sleep state, i.e., using the cold boot initialization procedure. Additionally, when the graphics processing unit is leaving a deep sleep state, and when the physical configuration of the computer system has not changed, the technique uses a compressed warm boot initialization procedure to restore a previously stored operational state, thereby minimizing The set time required after leaving the deep sleep state.

One benefit of this disclosure technique is that minimizing the setup time of a graphics processing unit when the display is operating in a panel self-refresh mode can reduce the latency associated with updating an image being displayed. Computer systems including displays with self-updating capabilities can often cause a graphics processing unit to enter and leave a deep sleep state. Typically the graphics processing unit will leave the deep sleep state within a few seconds of entering the deep sleep state. Therefore, the configuration of the computer system is almost impossible to change since the graphics processing unit enters the deep sleep state. The disclosed technique explores this phenomenon by setting the operational state of the graphics processing unit rather than relying on the graphics driver to set the graphics processing unit each time the graphics processing unit is powered on.

Another benefit of the disclosed technique is that the graphics processing unit can be placed in parallel with other hardware and software components of the computer system. The graphics processing unit may not need to rely on a high speed communication bus before the graphics processing unit can be set up by using an auxiliary communication path or a dedicated non-volatile memory to load an instruction for setting the graphics processing unit. Successful initialization of (eg PCIe bus). This allows the graphics processing unit to be individually set to reduce the time required for initialization and to provide better user experience.

The foregoing is a further embodiment of the invention, and other and further embodiments of the invention may be carried out without departing from the basic scope. For example, the aspect of the present invention can be implemented as a hard body or a soft body, or a combination of a hardware and a soft body. An embodiment of the invention can be implemented as a program product for use by a computer system. The program of the program product defines the functions of the specific embodiments (including the methods described herein) and can be included on a variety of computer readable storage media. Exemplary computer readable storage media include, but are not limited to: (i) non-writable storage media (eg, a read-only memory device in a computer, such as a CD-ROM disc that can be read by a CD-ROM, flashing Memory, ROM chip, or any other kind of solid non-volatile semiconductor memory) on which information can be stored permanently; and (ii) writeable to a storage medium (eg, a floppy disk in a disk drive, or a hard disk drive, or any kind of solid state random access semiconductor memory), which can be stored and changed Information. These computer readable storage media are specific embodiments of the present invention when carrying computer readable instructions relating to such functions of the present invention.

Based on the foregoing, the scope of the invention is determined by the scope of the following claims.

100‧‧‧ computer system

102‧‧‧Central Processing Unit

103‧‧‧Graphics driver

104‧‧‧System Memory

105‧‧‧Memory Bridge

106‧‧‧ Bus or other communication path

107‧‧‧Input/Output Bridge

108‧‧‧User input device

110‧‧‧ display

110(0)‧‧‧Internal display panel

110(1)..110(N)‧‧‧ External display panel

112‧‧‧Parallel Processing Subsystem

113‧‧‧ Bus or other communication path

114‧‧‧System Disc

116‧‧‧Switch

118‧‧‧Network Converter

120,121‧‧‧ embedded card

210‧‧‧ Timing Controller

212‧‧‧ line driver

214‧‧‧ column driver

216‧‧‧LCD device

220‧‧‧ self-updating controller

224‧‧‧Local frame buffer

240‧‧‧Graphic Processing Unit

242‧‧‧Graphic memory

244‧‧‧ Frame buffer

250‧‧‧ digital video signals

251, 252, 253, 254 ‧ ‧ route

255‧‧‧Connected symbol clock cycle

260‧‧‧Subdata packets

265‧‧‧Connected symbol clock cycle

280‧‧‧Communication path

310‧‧‧ embedded controller

320‧‧‧SPI flash device

330‧‧‧System Basic Input/Output System

340‧‧‧ drive

400‧‧‧State diagram

410‧‧‧Normal state

420‧‧‧Attachment frame buffer status

430‧‧‧Cache frame status

440‧‧‧ self-update status

450‧‧‧Resynchronization status

460‧‧‧Local frame buffer sleep state

500‧‧‧State diagram

510‧‧‧Normal state

520‧‧‧Deep idle state

530‧‧‧ Panel self-updating status

540‧‧‧Deeply idle

550‧‧‧ GPU power off

560‧‧‧Resynchronization status

610‧‧‧Power Management Microcontroller Unit

620‧‧‧ Processing core

630‧‧‧Scratch file

640‧‧‧ yards

650‧‧‧ yards

660‧‧‧Graphic processing unit status

700‧‧‧ method

710-716‧‧‧Steps

800‧‧‧ method

810-814‧‧‧Steps

900‧‧‧ method

910-922‧‧‧Steps

Therefore, a more detailed description of one of the aspects of the present invention can be made by way of example only. It is to be noted, however, that the appended drawings are merely illustrative of exemplary embodiments of the invention, and are not intended to limit the scope of the invention.

1 is a block diagram of a computer system configured to implement one or more aspects of the present invention; and FIG. 2A illustrates a parallel processing subsystem coupled to a display including a self-updating capability in accordance with an embodiment of the present invention; 2B illustrates a communication path for implementing an embedded DisplayPort interface according to an embodiment of the present invention; FIG. 2C is a conceptual diagram of a digital video signal generated by a GPU transmitted over a communication path according to an embodiment of the present invention; 2D is a conceptual diagram of a primary data packet embedded in a horizontal blank period of the digital video signals of FIG. 2C according to an embodiment of the present invention; FIG. 3 illustrates a computer according to an embodiment of the present invention. The parallel processing subsystem of the system communicates signals with a plurality of components; FIG. 4 is a state diagram of a display having a self-updating capability in accordance with an embodiment of the present invention; and FIG. 5 is a diagram of a specific embodiment of the present invention. a state diagram set to control a display to be converted into a graphics processing unit that is switched away from a panel self-refresh mode; Figure 6 illustrates various components of a graphics processing unit in accordance with an embodiment of the present invention; and Figure 7 provides a flow diagram of a method for setting a graphics processing unit in accordance with an embodiment of the present invention; A flowchart of a method for performing a complete cold boot initialization procedure of a graphics processing unit; and FIG. 9 provides a fast warm restart initialization procedure for executing a graphics processing unit in accordance with an embodiment of the present invention. A flow chart of the method.

Claims (10)

A method for setting an operational state of a graphics processing unit coupled to a self-updating display, the method comprising: performing at least one job to set a first portion of an operational state of the graphics processing unit; determining whether a signal is Has been set to indicate that the graphics processing unit should perform a warm boot operation; and if the signal has been set, perform the warm boot operation to set a second portion of the operational state of the graphics processing unit, or if If the signal has not been set, a cold boot operation is performed to set the second portion of the operational state of the graphics processing unit. The method of claim 1, wherein the performing the cold boot operation comprises: receiving one or more values generated by a software driver associated with the graphics processing unit via a communication bus; Or loading a plurality of values into one or more registers associated with the graphics processing unit; and setting the second portion of the operational state of the graphics processing unit to enable the graphics processing unit to communicate via a primary communication The row receives graphics data and instructions, and generates video signals based on the graphics data and the instructions to display on the display. The method of claim 1, wherein performing the warm boot operation comprises: reading one or more values from a non-volatile memory coupled to the graphics processing unit; and loading the one or more values Entering into one or more registers associated with the graphics processing unit; and setting the second portion of the operational state of the graphics processing unit to enable the graphics processing unit to receive graphics data via a primary communication bus Commanding and generating video signals based on the graphics data and the instructions Display on this display. A subsystem comprising: a graphics processing unit configured to: perform at least one job to set a first portion of an operational state of the graphics processing unit; determine whether a signal has been set to indicate the graphics processing The unit should perform a warm boot operation; and if the signal has been set, perform the warm boot operation to set a second portion of the operational state of the graphics processing unit, or if the signal has not been set, execute one The cold boot operation sets the second portion of the operational state of the graphics processing unit. A subsystem of claim 4, wherein an instruction to execute the at least one job is stored in a mask ROM associated with the graphics processing unit. The subsystem of claim 4, wherein performing the cold boot operation comprises: receiving one or more values generated by a software driver associated with the graphics processing unit via a communication bus; Or loading a plurality of values into one or more registers associated with the graphics processing unit; and setting the second portion of the operational state of the graphics processing unit to enable the graphics processing unit to communicate via a primary communication The row receives graphics data and instructions, and generates video signals based on the graphics data and the instructions to display on the display. The subsystem of claim 6, wherein receiving the one or more values is performed when the primary communication bus is being initialized. The subsystem of claim 4, wherein performing the warm boot operation comprises: reading one or more values from the non-volatile memory; loading the one or more values into an associated graphics processing unit And the second portion of the operating state of the graphics processing unit is configured to enable the graphics processing unit to receive graphics data and instructions via a primary communication bus, and based on the graphics data The instructions generate a video signal for display on the display. For example, in the subsystem of claim 8, the graphics processing unit is further configured to: before entering a deep sleep state, determine whether an operation state stored in one of the graphics processing units in the non-volatile memory conforms to the graphics processing unit. a current operational state; and if the stored operational state conforms to the current operational state, entering the deep sleep state, or if the stored operational state does not conform to the current operational state, updating the stored operational state The current operating state is reflected and enters the deep sleep state. The subsystem of claim 9, wherein the step of determining whether the operational state stored by the one of the graphics processing units in the non-volatile memory conforms to a current operational state of the graphics processing unit comprises comparing operating states regarding the storage One checks the sum and a checksum for the current operating state.