|Publication number||US7620798 B1|
|Application number||US 11/554,511|
|Publication date||Nov 17, 2009|
|Filing date||Oct 30, 2006|
|Priority date||Oct 30, 2006|
|Also published as||US7917736|
|Publication number||11554511, 554511, US 7620798 B1, US 7620798B1, US-B1-7620798, US7620798 B1, US7620798B1|
|Inventors||Mark J. French, Steven E. Molnar|
|Original Assignee||Nvidia Corporation|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (3), Classifications (6), Legal Events (3)|
|External Links: USPTO, USPTO Assignment, Espacenet|
1. Field of the Invention
One or more aspects of the present invention relate generally to synchronizing events across multiple execution pipelines, and more particularly to synchronizing the events using signals that may incur varying amounts of latency.
2. Description of the Related Art
Multiple execution pipelines are conventionally used to increase processing throughput. Sometimes it is necessary to synchronize the multiple pipelines in order to process data from a common starting point. Some conventional synchronization mechanisms require that each of the multiple pipelines signal their execution status to each other or a central synchronization unit in a single clock cycle. As chip die sizes increase, the distance that the signals must travel across a die may increase beyond what can be accomplished in a single clock cycle and in order to meet the chip-level timing constraints, the signals are pipelined. Pipelining the signals may result in varying latencies for each signal complicating synchronization when multiple synchronization events occur in sequence.
When the signals are pipelined, a conventional handshake synchronization mechanism is used so that each sender of a signal is acknowledged by the central synchronization unit or every other execution pipeline. Unfortunately, the round trip latency incurred for the handshaking synchronization of each synchronization event reduces the processing throughput of the multiple execution pipelines.
As the foregoing illustrates, what is needed in the art is the ability to synchronize multiple execution pipelines when multiple synchronization events may occur in sequence and the synchronization signals are pipelined to meet chip-level timing constraints.
Systems and methods of the present invention are used to synchronize events across multiple execution pipelines that process transaction streams. The current invention provides the ability to synchronize multiple execution pipelines when multiple synchronization events may occur in sequence and when the synchronization signals are pipelined to meet chip-level timing constraints.
Each transaction stream that is executed by one of the multiple execution pipelines includes a common set of state configuration to control processing of data that is distributed between the different transaction streams. Portions of the state configuration correspond to portions of the data. Execution of the state configuration portions of the transaction streams is synchronized to ensure that each portion of the data is processed using the state configuration that corresponds to that portion of the data. In some cases, such as when a transaction sequence does not include a portion of data corresponding to a particular portion of state configuration, different portions of the state configuration may occur back-to-back, resulting in back-to-back synchronization events. The synchronization mechanism tolerates latency for the transmission of synchronization signals between the multiple execution pipelines to allow for pipelining of the signals and back-to-back synchronization events.
Various embodiments of a method of the invention for synchronizing execution of multiple transaction streams including a first transaction stream and remaining transaction streams includes receiving a synchronization transaction included in the first transaction stream, outputting a synchronization strobe to each processing pipeline executing one of the remaining transaction streams indicating that a synchronization point of the multiple transaction streams has been reached, maintaining independent synchronization state within each processing pipeline for each one of the multiple transaction streams, determining whether each one of the remaining transaction streams have reached the synchronization point using the synchronization state for each one of the multiple transaction streams, and disabling output of the first transaction stream when one or more of the multiple transaction streams have not reached the synchronization point.
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.
In the following description, numerous specific details are set forth to provide a more thorough understanding of the present invention. However, it will be apparent to one of skill in the art that the present invention may be practiced without one or more of these specific details. In other instances, well-known features have not been described in order to avoid obscuring the present invention.
State configuration A 111, state configuration A 121, and state configuration A 131 may be identical or may be tailored specifically for each transaction stream 100, 120, and 130 based on the particular execution pipeline that will process transaction stream 100, 120, and 130, respectively. Furthermore, state configuration A (represented by state configuration A 111, state configuration A 121, and state configuration A 131) and state configuration B (represented by state configuration B 113, state configuration B 123, and state configuration B 133) may include one or more configuration instructions that set up each of the multiple execution pipelines to operate in a specified mode with state information provided by the configuration instructions.
In some embodiments of the present invention, each one of the configuration instructions is considered a synchronization event. In other embodiments of the present invention, a first or last configuration instruction within a sequence of configuration instructions, e.g., state configuration A or state configuration B, is considered a synchronization event. In one embodiment, illustrated in
Transaction streams 100, 120, and 130 each include a portion of data for processing by an execution pipeline that is configured as specified by the state configuration corresponding to each portion of the data. As shown in transaction stream 120, state configuration A 121 is back-to-back with state configuration B 123 since transaction stream 120 does not include any data for processing using the execution pipeline configuration specified by state configuration A 121. In contrast, transaction stream 100 includes data A 112 for processing as specified by state configuration A 111 and data B 114 for processing as specified by state configuration B 113. Transaction stream 130 includes data A 132 for processing as specified by state configuration A 131 and data B 134 for processing as specified by state configuration B 133.
Transaction stream 130 includes data Z 140 that is processed as specified by an earlier state configuration (not shown). When the execution pipelines receiving transaction streams 100 and 120 receive state configuration A 111 and state configuration A 121, respectively, they will wait for the execution pipeline processing data Z 140 to output data Z 140 and indicate that state configuration A 131 is at the output before outputting data A 112 and state configuration B 123, respectively. Similarly, the execution pipeline processing and outputting state configuration B 123 of transaction stream 120 will wait for the execution pipelines processing data A 112 and data A 132 to each output data A 112 and data A 132 and execute state configuration B 113 and 133 before outputting data B 124. Once all of the execution pipelines are synchronized for synchronization point 151, i.e., have output state configurations B 113, 123, and 133, they may then output data B 114, 124, and 134, respectively. In some embodiments of the present invention, all of the execution pipelines are synchronized for each synchronization point before either data or state configuration is output from any of the execution pipelines. In these embodiments, a synchronization latency is incurred for each synchronization point and when each configuration instruction is a synchronization event, synchronization latencies are incurred serially, thereby limiting transaction throughput when the latency is greater than one clock cycle.
In other embodiments of the present invention an amount of elasticity is allowed for the synchronization so that the execution pipelines are allowed to “get ahead” by outputting a limited number of state configuration transactions without waiting for the other execution pipelines to output data or even a previous state configuration. For example, the execution pipeline processing and outputting state configuration B 123 of transaction stream 120 can proceed to output a limited number of state configuration transactions of state configuration B 123 and get ahead of the other execution pipelines that may not have completed output of data A or state configuration A. Unlike the state configuration transactions, a data transaction cannot get ahead until all of the execution pipelines have output the state configuration corresponding to the data. For example, the execution pipeline processing and outputting data A 132 of transaction stream 130 must wait for the execution pipelines processing transaction streams 100 and 120 to output state configuration A 111 and 121, respectively.
Each processing pipeline 210, 220, and 230 asserts a synchronization strobe for a single clock cycle when a synchronization point is reached in a transaction stream. For example, a strobe connection 231 transmits the synchronization strobe signal output by processing pipeline 230 to processing pipeline 210 and processing pipeline 220. Strobe connection 231 also transmits the synchronization strobe signal back to processing pipeline 230. In some embodiments of the present invention, strobe connection 231 is not input to processing pipeline 230. The generation and monitoring of the synchronization strobes is described in conjunction with
The synchronization mechanism of the present invention is tolerant of latency. In particular when a sequence of back-to-back synchronization events occurs, the synchronization latency, including any latency introduced by retiming registers 260 is only incurred once for processing the entire sequence rather than for each event in the sequence. In other words, once the synchronization latency is incurred state configuration instructions are output at a rate of one per clock. Data that follows the state configuration may then be output at a rate of one per clock until another synchronization event is encountered.
When each state configuration transaction is also a synchronization transaction, the different processing pipelines 210, 220, and 230 are allowed to output the state configuration without synchronizing each state configuration transaction. However, the number of state configuration transactions that any processing pipeline 210, 220, or 230 is permitted to advance “ahead” of the other processing pipelines is limited by a counter. This elasticity is advantageous since the latency introduced by retiming registers 260 is not incurred for each state configuration transaction when each state configuration transaction is also a synchronization transaction. Although one or more of processing pipelines 210, 220, and 230 may advance ahead, processing pipelines 210, 220, and 230 must wait for all of processing pipelines 210, 220, and 230 before beginning to output data transactions or another state configuration.
Processing pipeline 230 includes a synchronization control unit 280 for generating and receiving synchronization strobe signals. Processing pipeline 230 also includes multiple synchronization strobe counters 270 that maintain synchronization state for each transaction stream being processed by processing pipeline 210, 220, and 230. Each one of the synchronization strobe counters 270 corresponds to a particular processing pipeline 230, 210, 220, or the like. The synchronization state maintained by synchronization strobe counters 270 is used to enable and disable the output of data, state configuration, and synchronization transactions from processing pipeline 230.
Synchronization strobe counters 270 are used to determine when the processing pipelines in a system are synchronized and should be configured to count at least as high as the latency for a synchronization strobe to propagate from one processing pipeline to another processing pipeline. When a synchronization transaction reaches the output of pipeline engines 290, pipeline engines 290 signals synchronization control unit 280 via synch transaction 292. A synchronization transaction may be all state configuration instructions or a discrete synchronization instruction. Synchronization control unit 280 outputs a synchronization strobe on strobe output 285. The synchronization strobe may then propagate through one or more retiming registers before reaching another processing pipeline. When synchronization transactions occur on consecutive clock cycles, processing pipelines 210, 220, and 230 will output transactions in lockstep if the maximum count is equal to the worst-case synchronization strobe propagation latency from one processing pipeline 210, 220, and 230 to any other processing pipeline 210, 220, and 230. Therefore, it is advantageous to increase the maximum count, thereby increasing the elasticity of state configuration transaction outputs between processing pipelines 210, 220, and 230, and reducing the frequency of processing pipelines 210, 220, and 230 stalling to wait for one or more of the processing pipelines to “catch up.”
One synchronization control unit 280 receives the synchronization strobe output on strobe output 285 via one of strobe inputs 275. The other synchronization control units 280 receive synchronization strobes from processing pipelines 210 and 220 via the other two strobe inputs 275. Synchronization strobe counters 270 each decrement when a strobe is received. Synchronization strobe counters 270 are simultaneously incremented using an increment 282 signal output by synchronization control unit 280 when synchronization control unit 280 outputs a synchronization strobe on strobe output 285. In other embodiments of the present invention, the incrementing and decrementing is reversed. Therefore, each synchronization strobe counter 270 indicates how far ahead (positive values) or behind (negative values) each local pipeline engine, e.g., pipeline engines 290 within processing pipeline 230, is relative to the pipeline engines in each one of processing pipelines 210, 220, and 230. When the values of synchronization strobe counters 270 are zero, processing pipelines 210, 220, and 230 are synchronized at the same synchronization event.
Synchronization control unit 280 provides an output enable/disable 294 signal to pipeline engines 290 to control whether or not transactions are output by pipeline engines 290 for transaction stream 295. Separate output enable/disable 294 signals are used to control the output of state configuration transactions and data transactions from pipeline engines 290. When the value of each synchronization strobe counter 270 does not exceed the maximum count, the state configuration transactions are output at a rate of one per clock until a non-synchronization transaction, e.g., a data transaction, is ready for output by pipeline engines 290. Therefore, the synchronization latency is only incurred once for each sequence of synchronization transactions. Data transactions are output at a rate of one per clock following synchronization, as long as the unit receiving the data transactions can accept them. When a data transaction reaches the output of pipeline engines 290, pipeline engines 290 signals synchronization control unit 280 via data transaction 293.
In step 315 the particular synchronization strobe counter 270 that corresponds to the synchronization strobe signal received in step 310 is decremented to indicate that a synchronization transaction was received from the processing pipeline that is coupled to the particular synchronization strobe counter 270. Each synchronization strobe counter 270 may be incremented and/or decremented during each clock cycle. When a synchronization strobe counter 270 is incremented and decremented in the same clock cycle, the counter value of the synchronization strobe counter 270 is unchanged. Synchronization strobe counters 270 are incremented once for each clock cycle that increment 282 is asserted. Increment 282 is provided to all synchronization strobe counters 270 in parallel by synchronization control unit 280, as described in conjunction with
If, in step 325 synchronization control unit 280 determines that all of the counters are less than the maximum count, then in step 335 synchronization control unit 280 enables pipeline engines 290, via output enable/disable 294, to output synchronization transactions. In step 340 synchronization control unit 280 outputs a synchronization strobe via strobe output 285 to indicate that a synchronization transaction has been received. In step 345 synchronization control unit 280 simultaneously increments each one of synchronization strobe counters 270 via increment 282. Incrementing all of the synchronization strobe counters 270 within processing pipeline 230 indicates the number of synchronization transactions that processing pipeline 230 has processed relative to each processing pipeline, e.g., processing pipeline 210, 220, and 230.
If, in step 305 synchronization control unit 280 determines that the transaction is not a synchronization transaction, then the transaction is a data transaction and in step 350 synchronization control unit 280 determines if all of the counters provided to synchronization control unit 280 by each synchronization strobe counter 270 are less than or equal to zero. If any counter is greater than zero, then in step 355 synchronization control unit 280 disables pipeline engines 290, via output enable/disable 294, from outputting data transactions. When the counters are not all less than or equal to zero a synchronization transaction is pending and data transactions should not be output from any of processing pipeline 210, 220, or 230 until processing pipelines 210, 220, and 230 have all reached a common synch point. Pipeline engines 290 will resubmit the data transaction via data transaction 293 when output of the data transactions is disabled, waiting until data transactions are enabled.
If the counters are all less than or equal to zero in step 350, then in step 360 synchronization control unit 280 enables pipeline engines 290, via output enable/disable 294, to output all data transactions. The present invention allows each processing pipeline 210, 220, and 230 to independently determine that a synch point has been reached, so that a sequence of synchronization transactions can be processed at a rate of one per clock. Notably, all of the processing pipelines 210, 220, and 230 are equal, i.e., there is no master-slave relationship for the processing pipelines or transaction streams 100, 120, and 130. The synchronization latency is only incurred once for each sequence of synchronization transactions and the synchronization mechanism is tolerant of synchronization strobe latency. Therefore, chip-level timing constraints can be met without requiring a redesign of the synchronization mechanism.
Host processor 414 includes a processing unit 200 or 250 that may be configured to process multiple transaction streams in parallel using the distributed synchronization mechanism described in conjunction with
A graphics device driver 420 is stored in host memory 412 and is configured to interface between applications and a graphics subsystem 470. Graphics device driver 420 translates instructions for execution by graphics processor 450 based on the specific capabilities of graphics processor 450.
Host computer 410 communicates with graphics subsystem 470 via system interface 415. Data received by graphics processor 450 can be processed by a graphics pipeline, such as processing unit 200 or 250, within graphics processor 450 or written to a local memory 440. Graphics processor 450 uses graphics memory to store graphics data and program instructions, where graphics data is any data that is input to or output from units within graphics processor 450. Graphics memory can include portions of host memory 412, local memory 440, register files coupled to the components within graphics processor 450, and the like. Graphics processor 450 includes one or more processing units that may each read and/or write graphics memory. In alternate embodiments, host processor 414, graphics processor 450, system interface 415, or any combination thereof, may be integrated into a single processing unit. Further, the functionality of graphics processor 450 may be included in a chip set or in some other type of special purpose processing unit or co-processor.
In a typical implementation graphics processor 450 performs geometry computations, rasterization, pixel texture mapping and shading computations and raster operations. In some embodiments of the present invention, graphics processor 450 is optionally configured to deliver data to a display device, network, electronic control system, other computing system 400, other graphics subsystem 470, or the like. Alternatively, data is output to a film recording device or written to a peripheral device, e.g., disk drive, tape, compact disk, or the like.
Execution of transaction streams executed by processing units 200 and 250 may be synchronized to ensure that each portion of the data is processed using the state configuration that corresponds to that portion of the data. The synchronization mechanism may be used for multiple synchronizations in a sequence and when the synchronization strobes are pipelined to meet chip-level timing requirements. The synchronization is distributed within each processing pipeline 210, 220, and 230, rather than using a centralized synchronization mechanism. Although present invention has been described in the context of synchronizing state transactions, in other embodiments, the present invention may be employed to synchronize execution of multiple transaction streams containing other synchronization events known to those skilled in the art, e.g., semaphores, mutual-exclusion tokens, and the like. Persons skilled in the art will appreciate that any system configured to perform the method steps of
The invention has been described above with reference to specific embodiments. Persons skilled in the art, however, will understand that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention as set forth in the appended claims. The foregoing description and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US5428756 *||Jul 12, 1993||Jun 27, 1995||Matsushita Electric Industrial Co., Ltd.||Pipelined computer with control of instruction advance|
|US6272621 *||Aug 18, 2000||Aug 7, 2001||Cisco Technology, Inc.||Synchronization and control system for an arrayed processing engine|
|US20030063092 *||Sep 28, 2001||Apr 3, 2003||Gavril Margittai||Texture engine memory access synchronizer|
|U.S. Classification||712/216, 712/228, 712/200|
|Oct 30, 2006||AS||Assignment|
Owner name: NVIDIA CORPORATION, CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:FRENCH, MARK J.;MOLNAR, STEVEN E.;REEL/FRAME:018455/0679
Effective date: 20061030
|Mar 7, 2013||FPAY||Fee payment|
Year of fee payment: 4
|Apr 21, 2017||FPAY||Fee payment|
Year of fee payment: 8