Abstract:
One embodiment of the present invention sets forth a method and system for reordering a plurality of pixel data returned by a frame buffer in a display system. The method includes the steps of recording the order of a plurality of requests for pixel data arriving at the frame buffer as a first sequence, wherein the plurality of requests is further associated with a first request stream, associating each pixel data returned by a frame buffer partition in the frame buffer in response to the plurality of requests with an independently operating data thread, wherein each of the data threads is further associated with the first request stream and the frame buffer partition, and retrieving the pixel data for display in a same sequence as the first sequence from the data threads.

Description:
BACKGROUND OF THE INVENTION 
     1. Field of the Invention 
     Embodiments of the present invention relates generally to display technologies and more specifically to a method and system for reordering isochronous hub streams. 
     2. Description of the Related Art 
     Unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section. 
     Multi-head display systems, which support multiple display devices such as monitors, televisions, and projectors, are becoming increasingly popular. Each display device in such a display system is an output isochronous function and imposes strict timing constraints for receiving display data from the memory subsystem of the display system. To satisfy such timing constraints, one approach is to include an isochronous hub to manage the multiple streams of traffic traveling in between the multi-heads and the memory subsystem. This isochronous hub is disclosed in the U.S. patent application titled, “Isochronous Hub Contracts,” filed on Apr. 2, 2007 and having U.S. patent application Ser. No. 11/695,557 (the “Related Application”). 
       FIG. 1A  is a simplified diagram of a multi-head display system  100  utilizing such an isochronous hub. In particular, the multi-head display system  100  includes a display device  110  supporting two display heads and a memory subsystem  102 . The memory subsystem  102  further includes a frame buffer  104  with multiple partitions (e.g., PA 0 -PA N ) and an isochronous hub  106 . The isochronous hub  106  ensures the establishment of a contract for an entire frame of data between the display device  110  and the memory subsystem  102  before the memory subsystem  102  delivers any of the requested data. The “contract” here refers to a collection of parameters associated with the request for the frame of data. With the established contract, the isochronous hub  106  proceeds to facilitate the transmission of N streams of requests to the frame buffer  104  to retrieve data from different partitions for each of the two display heads. 
     In addition, the isochronous hub  106  supports multiple channels carrying different types of data to the two heads of the display device  110 . Specifically, a channel  108  of the isochronous hub  106  carries contract-related communication data for establishing, amending, and managing the contracts between the memory subsystem  102  and the display device  110 . A first set of channels, channels  120 ,  122 , and  124 , and a second set of channels, channels  126 ,  128 , and  130 , transmit information associated with different types of display data received from the frame buffer  104  to head  0  and head  1 , respectively.  FIG. 1B  is a conceptual diagram of a display screen including three different types of display data, namely, base data  150 , overlay data  152 , and cursor data  154 . The base address (e.g., ADDR), the screen coordinates (e.g., the Xs and Ys), and the base address offsets (e.g., the X_BASE_OFFs and Y_BASE_OFFs) associated with the three display data types also correspond to physical locations of various buffers in the frame buffer  104  as shown in  FIG. 1C , namely a base buffer  160 , a overlay buffer  162 , and a cursor buffer  164 . It is worth noting that each of these buffers corresponds to one or more frame buffer partitions. For example, the base buffer  160  may correspond to PA 0 -PA 3 , and the cursor buffer  164  may correspond to PA N . Because each of these partitions operates independently from one another, the isochronous hub  106  lacks any mechanism to ensure the sequence of data received from the partitions matches the sequence of the requests it sends to the frame buffer  104 . 
     To illustrate, suppose the isochronous hub  106  receives a stream of requests for base data from the base buffer  160 , a request stream 0 . In response, the isochronous hub  106  first transmits a request associated with the request stream 0  to PA A , denoted as request (PA A ), and then transmits a request associated with the request stream 0  to PA B , denoted as request (PA B ), to the frame buffer  104 . Without any corrective mechanism, the isochronous hub  106  is likely to improperly receive the requested data corresponding to the request (PA B ) before the requested data corresponding to the request (PA A ). 
     As the foregoing illustrates, what is needed in the art is a method and system for ensuring the sequence of data from the frame buffer partitions match the sequence of requests issued to the frame buffer partitions. 
     SUMMARY OF THE INVENTION 
     One embodiment of the present invention sets forth a method and system for reordering a plurality of pixel data returned by a frame buffer in a display system. The method includes the steps of recording the order of a plurality of requests for pixel data arriving at the frame buffer as a first sequence, wherein the plurality of requests is further associated with a first request stream, associating each pixel data returned by a frame buffer partition in the frame buffer in response to the plurality of requests with an independently operating data thread, wherein each of the data threads is further associated with the first request stream and the frame buffer partition, and retrieving the pixel data for display in a same sequence as the first sequence from the data threads. 
     One advantage of the disclosed method and system is that multiple streams of requests for a frame buffer can be processed by multiple independently operating frame buffer partitions, because the sequence of pixel data returned by the frame buffer partitions is ensured to correctly match the sequence of the requests received by the frame buffer. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       So that the manner in which the above recited features of the present invention can be understood in detail, a more particular description of the invention, briefly summarized above, may be had by reference to embodiments, some of which are illustrated in the appended drawings. It is to be noted, however, that the appended drawings illustrate only typical embodiments of this invention and are therefore not to be considered limiting of its scope, for the invention may admit to other equally effective embodiments. 
         FIG. 1A  is a simplified diagram of a multi-head display system utilizing an isochronous hub; 
         FIG. 1B  is a conceptual diagram of a frame buffer containing various buffers for different types of pixel data; 
         FIG. 1C  illustrates a number of display rectangles in the screen space corresponding to the frame buffer shown in  FIG. 1B ; 
         FIG. 2  is a simplified block diagram of an isochronous hub capable of reordering data from frame buffer partitions, according to one embodiment of the present invention; 
         FIG. 3A  is a conceptual diagram of a multithreaded command buffer, according to one embodiment of the present invention; 
         FIG. 3B  is a conceptual diagram of a multithreaded data buffer, according to one embodiment of the present invention; 
         FIG. 3C  is a conceptual diagram of a read-out interface, according to one embodiment of the present invention; 
         FIG. 3D  is a state transition diagram for one of multiple state machines in the read-out interface, according to one embodiment of the present invention; and 
         FIG. 4  is a block diagram of a system configured to implement one or more aspects of the present invention. 
     
    
    
     DETAILED DESCRIPTION 
       FIG. 2  is a simplified block diagram of an isochronous hub  200  capable of reordering data from frame buffer partitions, according to one embodiment of the present invention. Specifically, the isochronous hub  200  includes a parser  202 , an arbitrator  204 , an address generator  206 , a multithreaded command buffer  208 , a multithreaded data buffer  210 , and a read-out interface  212 . In one implementation, the isochronous hub  200  facilitates a contract-based communication session between a frame buffer  214  and one or more display heads. As discussed above, the Related Application discloses how such a session is conducted. Here, the parser  202  mainly extracts information, such as one or more request streams, from an established contract. Each request stream includes individual requests for a particular type of display data from a specific buffer within the frame buffer  214 , and each of these requests is further associated with attributes of the buffer and the relative locations of the requested display data within the buffer. For instance, a request stream 0  may include requests for base data from the base buffer  160  as shown in  FIG. 1C , and each of these requests is further associated with the attributes of the base buffer  160  and the relative locations of the requested base data within the base buffer  160 , which are represented in terms of the ADDR base  and the (X base , Y base ) screen coordinates as shown in  FIG. 1B . Then, the arbitrator  204  arbitrates among the M request streams and passes on a selected request stream, such as the request stream 0 , to the address generator  206 . The address generator  206  then translates the relative locations associated with each request into physical addresses corresponding to certain frame buffer partitions in the frame buffer  214  and directs the request with the translated physical address to both the multithreaded readout buffer  208  and the frame buffer  214 . 
       FIG. 3A  is a conceptual diagram of the multithreaded command buffer  208 , according to one embodiment of the present invention. The multithreaded command buffer  208  mainly tracks the sequence of the requests from the various request streams arriving at the multithreaded command buffer  208 . Since the address generator  206  also forwards these same requests to the frame buffer  214 , the arrival sequence recorded by the multithreaded command buffer  208  is the same as the arrival sequence at the frame buffer  214 . In one implementation, the multithreaded command buffer  208  is divided into multiple independently operating logical buffers, each of which stores the requests associated with a particular request stream in a first-in-first-out sequence. To illustrate, suppose a logical buffer  300  is designated to store the requests associated with the request stream 0 , and a logical buffer  302  is designated to store the requests associated with a request stream M . Suppose further that the address generator  206  forwards three requests to the multithreaded command buffer  208  and the frame buffer  214  in the following sequence: (1) a request for PA B  of the frame buffer  214 , and the request is associated with the request stream 0  and is denoted as a request (stream 0 , PA B ), (2) a request for PA C  of the frame buffer  214 , and the request is associated with the request stream M  and is denoted as a request (stream M , PA C ), and (3) a request for PA A  of the frame buffer  214 , and the request is associated with the request stream 0  and is denoted as a request (stream 0 , FA A ). To record this arrival sequence, as shown in  FIG. 3A , the logical buffer  300  stores the request (stream 0 , PA B ) before the request (stream 0 , FA A ), and the logical buffer  302  stores the request (stream M , PA C ). 
     As the multithreaded command buffer  208  records the arrival sequence of the incoming requests, the various frame buffer partitions in the frame buffer  214  also respond to these same requests. As mentioned above, since each of the requested frame buffer partition operates independently, the data returned by the requested frame buffer partitions do not arrive at a return crossbar (“RXB”)  216  in the same sequence as the frame buffer  214  receives the incoming requests. To reorder these out-of-order returned data, instead of directly forwarding the returned data to display head interfaces for display, the RXB  216  directs the returned data to the multithreaded data buffer  210 , which is further illustrated in  FIG. 3B . 
     In one implementation, the multithreaded data buffer  210  includes multiple independently operating data threads, each of which stores returned data associated with a specific request stream and a specific frame buffer partition. The number of these data threads thus equals to the number of request streams (e.g., M) multiplying by the number of frame buffer partitions (e.g., N). So, as shown in  FIG. 3B , the multithreaded data buffer  210  designates a data thread  350  to store the returned data corresponding to the request (stream 0 , FA A ) and a data thread  352  to store the returned data corresponding to the request (stream 0 , PA B ). 
     With the arrival sequence of the requests stored in the multithreaded command buffer  208  and the returned data from the frame buffer  214  stored in the multithreaded data buffer  210 , the read-out interface  212  reorders, whenever necessary, the returned data based on the recorded arrival sequence.  FIG. 3C  is a conceptual diagram of the read-out interface  212 , according to one embodiment of the present invention. Specifically, the read-out interface  212  includes M read-out finite state machines (“FSMs”). Each read-out FSM is responsible for a request stream and independently performs tasks based on a state transition diagram shown in  FIG. 3D . 
     Referring back to the contents of the multithreaded command buffer  208  of  FIG. 3A  and the multithreaded data buffer  210  of  FIG. 3B  as an example, since a read-out FSM 0  corresponds to the request stream 0 , the read-out FSM 0  retrieves the first-in request (stream 0 , PA B ) from the logical buffer  300  of  FIG. 3A  in a state  380 . In a state  382 , the read-out FSM 0  determines the data thread within the multithreaded data buffer  210  that stores the desired pixel data by using the information in the request (stream 0 , PA B ), such as the request stream number and the frame buffer partition, and also its own identification number. In this example, because the FSM identification number and the request stream number both equal to zero and the frame buffer partition is PA B , the read-out FSM 0  in a state  384  retrieves the returned data associated with the data thread  352  of  FIG. 3B . If PA B  fails to return data to the data thread  352  at the time the read-out FSM 0  attempts to retrieve data from it, then the read-out FSM 0  waits. The read-out FSM 0  does not attempt to retrieve data from other data threads that are associated with the request stream 0  in the multithreaded data buffer  210 , such as the data thread  350 , even if such a data thread contains pixel data. In other words, if the frame buffer  214  receives the aforementioned request (stream 0 , PA B ) ahead of the request (stream 0 , PA A ) but the frame buffer partition PA A  responds out-of-order and responds before PA B , the read-out FSM still waits for the data thread  352  to receive the returned pixel data from PA B . After the read-out FSM 0  successfully retrieves the returned data, it sends such pixel data to a display engine in a state  386 . As has been demonstrated, by using the multithreaded command buffer  208  and the multithreaded data buffer  210 , the read-out FSMs are able to reorder the out-of-order responses from the various frame buffer partitions before the display of the returned pixel data. 
       FIG. 4  is a block diagram of a system configured to implement one or more aspects of the present invention. Without limitation, system  400  may be a desktop computer, server, laptop computer, palm-sized computer, tablet computer, game console, cellular telephone, hand-held device, mobile device, computer based simulator, or the like. System  400  includes a host processor  408 , BIOS  410 , system memory  402 , and a chipset  412  that is directly coupled to a graphics subsystem  414 . BIOS  410  is a program stored in read only memory (“ROM”) or flash memory that is executed at bootup. The graphics subsystem  414  includes a graphics processing unit (“GPU”)  416 . In alternate embodiments, the host processor  408 , the GPU  416 , the chipset  412 , or any combination thereof, may be integrated into a single processing unit. Further, the functionality of the GPU  416  may be included in a chipset or in some other type of special purpose processing unit or co-processor. 
     A graphics driver  404 , stored within the system memory  402 , configures the GPU  416  to share the graphics processing workload performed by the system  400  and communicate with applications that are executed by the host processor  408 . In one embodiment, the graphics driver  404  generates and places a stream of commands in a “push buffer.” When the commands are executed, certain tasks, which are defined by the commands, are carried out by the GPU  416 . 
     In some embodiments of the system  400 , the chipset  412  provides interfaces to the host processor  408 , memory devices, storage devices, graphics devices, input/output (“I/O”) devices, media playback devices, network devices, and the like. It should be apparent to a person skilled in the art to implement the chipset  412  in two or more discrete devices, each of which supporting a distinct set of interfaces. 
     The GPU  416  is responsible for outputting image data to a display  426 . The Display  426  may include one or more display devices, such as, without limitation, a cathode ray tube (“CRT”), liquid crystal display (“LCD”), or the like. The GPU  416  is also coupled to a memory subsystem  418 . The memory subsystem  418  further includes an isochronous hub  420 , which is detailed above and illustrated in  FIG. 2 , and frame buffer  422 . 
     The above description illustrates various embodiments of the present invention along with examples of how aspects of the present invention may be implemented. The above examples, embodiments, and drawings should not be deemed to be the only embodiments, and are presented to illustrate the flexibility and advantages of the present invention as defined by the following claims.