A method of performing a blit operation in a parallel processing system includes dividing a blit operation into batches of pixels, performing reads of pixels associated with a first batch in any order, confirming that all reads of pixels associated with the first batch are completed, and performing writes of pixels associated with the first batch in any order. The pixels of the first batch and pixels of additional batches are applied to parallel processors, where the parallel processors include a corral defined by entry points and exit points distributed across the parallel processors.
|
1. A method of processing graphics information in a parallel processing system, comprising:
for a blit operation including copying of a source pixel area to a destination pixel area, dividing pixels associated with the blit operation into a first batch and a second batch with each batch being a subset of the blit input data;
determining whether the source pixel area overlaps with the destination pixel area;
based on determining that the source pixel area overlaps with the destination pixel area, activating a corral for the blit operation;
delivering pixels of the first batch and the second batch to parallel processors, wherein the parallel processors include the corral defined by entry points and exit points distributed across the parallel processors, such that each of the parallel processors includes a respective entry point and a respective exit point demarking a boundary of the corral, the exit points of the corral preventing the release of pixels for a particular batch for writing prior to confirming that all reads for the particular batch have been completed to guarantee that all read operations for the batch occur before write operations;
identifying when all of the pixels of the first batch have been delivered to the corral; and
removing the pixels of the first batch from the corral in response to said identifying.
2. The method of
3. The method of
4. The method of
5. The method of
specifying a batch size; and
configuring a size of the corral in accordance with the batch size so as to contain at least the pixels of the first batch.
|
This invention relates generally to graphics processing. More particularly, this invention relates to a technique for performing blit operations across parallel processors of a graphics processing unit (GPU).
In conventional graphics processing systems, an object to be displayed is typically represented as a set of one or more graphics primitives. Examples of graphics primitives include one-dimensional graphics primitives, such as lines, and two-dimensional graphics primitives, such as polygons. Portions of an object to be displayed are frequently moved from one display location to another. This copying of a source pixel area to a destination pixel area is referred to as a blit operation. A GPU may respond to an instruction to perform a blit operation by performing a read operation to read data in memory locations corresponding to the source pixel area, followed by a write operation to write the data to memory locations corresponding to the destination pixel area. The instruction for a blit operation may specify coordinates to identify the source pixel area, as well as coordinates to identify the location of the destination pixel area.
Within a single blit, if the destination pixel area overlaps the source pixel area, the reads and writes need to be performed with attention to ordering so that reads for pixels that are both in the source and destination pixel area are performed before the destination writes. This is the traditional blit correctness problem. There are known techniques for solving this problem in serial processing systems. It would be desirable to solve this problem in a parallel processing system.
Performance demands are resulting in increased parallel processing in GPUs. Parallel processing raises particular challenges for blit operations. Efficient parallel processing requires out of order execution of operations whenever possible. However, out of order execution of blit operations may result in the reading of stale data and the overwriting of valid data.
It would be desirable to extend the performance benefits of parallel processing to blit operations. However, any such parallel processing of blit operations must preserve data integrity. That is, any such parallel processing of blit operations must be accomplished without incurring errors in the sequencing of read and write operations.
The invention includes a method of performing a blit operation in a parallel processing system. The method includes dividing a blit operation into batches of pixels, performing reads of pixels associated with a first batch in any order, confirming that all reads of pixels associated with the first batch are completed, and performing writes of pixels associated with the first batch in any order. The pixels of the first batch and pixels of additional batches are applied to parallel processors, where the parallel processors include a corral defined by entry points and exit points distributed across the parallel processors.
The invention also includes a method of processing graphics information. The method includes dividing pixels associated with a blit operation into a first batch and a second batch, delivering pixels of the first batch and the second batch to processing units of a set of processing units, where the processing units include a corral defined by entry points and exit points distributed across the processing units. The method identifies when all of the pixels of the first batch have been delivered to the corral and the pixels of the first batch are then removed.
The invention also includes a graphics processing unit with a set of processing units. A circuit divides pixels associated with a blit operation into batches of pixels. A circuit delivers pixels of each batch to processing units of the set of processing units, where the set of processing units include a corral defined by entry points and exit points distributed across the processing units. The corral contains at least one batch of pixels. All batches within a blit pass through the corral.
The invention is more fully appreciated in connection with the following detailed description taken in conjunction with the accompanying drawings, in which:
Like reference numerals refer to corresponding parts throughout the several views of the drawings.
The parallel processors P1 through PN carry out blit operations in parallel. Each processor P operates to read data from a memory location in the frame buffer 130. In particular, as shown with processor P1, read requests are applied to the frame buffer 130 and read data is returned. The memory location specified in the read request corresponds to a specified source pixel area. The output from the individual processors P1 through PN is transferred via network 206 to raster operations 208, including raster operations units R1 through RM. The network may be a sophisticated routing network, if there is a general mapping of pixel data from processors P1 through PN to raster operations units, or it may be as simple as a direct connection between processors P1 through PN and dedicated raster operations units. The raster operations units 208 write the appropriate data to the memory locations in the frame buffer 130 corresponding to the specified destination pixel area to complete the blit operation. The raster operations units 208 communicate with the two-dimensional rasterizer 200 in a closed-loop to indicate that the blit operation is completed.
In accordance with the invention, the graphics pipeline 118 is configured to process groups or batches of input data (e.g., pixels). The ordering of the batches is significant. The ordering constraints are the same as in a serial system. For example, if a blit copies a rectangle one pixel to the left, batches would start at the left edge of the rectangle and move to the right. Pixels that are both read and written are read in an earlier (or the same) batch than the batch that writes them. The graphics pipeline 118 reads pixels within a batch before any writes associated with the batch are performed. More particularly, the writes for any batch N must not be performed until the reads for all batches 1 through N are completed. As long as this condition is observed, the reads and writes associated with a blit operation within a batch may be performed in any order. This specified ordering of reads and writes insures data integrity, while allowing for asynchronous reads and writes within a batch, which facilitates exploitation of the parallel processor architecture.
As in prior art systems, the invention processes a blit in batches. However, the pixels in a batch may be read at different times by different parallel processors and processed by different parallel processors and written at different times on different parallel processors. The pixel data in a batch need not be collected together on any single processor. The invention provides a “blit corral” that may be distributed over the processors to preserve the integrity of the blit without requiring the data of a batch to be gathered into a single processor. The corral is a stationary logical structure that allows one to observe what pixels have entered the corral and provides a gate to prevent them from leaving prematurely. The corral is defined by entry points and exits points distributed across the processing units. The size of the corral is configurable, but is always configured to be large enough to contain at least one batch of pixels.
The blit input data is divided into batches of pixels that may be viewed as subsets of the blit input data. For example, in the case of a rectangular blit, a number of batches may be formed as sub-rectangles of the rectangular blit. One rule for dividing a blit into batches is: if it would be correct to process the batches in order serially, then it will also be correct to process those same batches in that same order using the blit corral algorithm. Advantageously, the read operations may be performed in parallel to improve processing speed. The write operations associated with a batch may also occur in any order. As discussed below, the batches of the invention may be implemented with hardware control that guarantees that all read operations occur before write operations.
The foregoing operations of the invention are more fully appreciated with reference to
The second operation is to read pixel data in the processor's portion of the batch 302. Within a batch, pixels may be read in any order. Once read, the pixel data has now entered the blit corral. The processor then determines whether the other parallel processors 204 have completed their reads of the batch 304. This may be done via control signals between the parallel processors 204 or by a central controller, which gathers and distributes status signals from each of the parallel processors 204. If any other processor is still reading data for the batch, the processor must wait. Once the batch is complete on all parallel processors 204, the processor may release pixels for the batch for writing 306. This operation effectively unloads one batch from the corral.
The network 206 may receive the pixels from the corral and deliver them to the raster operations units 208. The raster operations units 208 may then write the pixels to memory locations within the frame buffer 130 in any desired sequence. A new batch is then invoked 308 and the processing beginning at block 300 is repeated. It should be appreciated that blocks 300 and 302 are running continuously. There may be several batches in the pipeline or corral at any one time. The completion of a batch does not stop blocks 300 and 302; similarly, blocks 300 and 302 do not need to wait for block 308. Rather, continuous processing in a parallel processing system is being performed, which is not otherwise immediately apparent from the flow chart of
These operations are more fully appreciated with reference to a specific example.
Any number of techniques may be used to demark each batch. For example, one or more flag bits associated with a pipeline transaction may be used to specify a batch boundary. Alternately, a special token may be inserted into the command or data stream to mark the start or end of a batch. Regardless of the technique used, the term batch token is used to indicate batch demarcation. Counters may be used anywhere in the graphics pipeline 118 to track the number of batches within each processor. The counter is incremented each time a batch token is received.
As shown in
In the example of
After the data associated with the first batch 402 is removed, the processor state of
Since two batch tokens exist in each processor of
The corral driver 114 may be configured to allow a user to specify a desired batch size. The corral driver 114 may also be used to disable the corral processing operations, for example by disabling any batch tokens when the source and destination rectangles are known not to overlap.
Those skilled in the art will appreciate that the invention provides a technique for performing blit operations in a parallel processor environment. This is achieved through blit data grouping in the form of batches. The invention provides a minimally invasive coherent protocol that avoids data corruption hazards. Thus, the invention allows one to perform same surface blits without write-before-read corruption.
An embodiment of the present invention relates to a computer storage product with a computer-readable medium having computer code thereon for performing various computer-implemented operations. The media and computer code may be those specially designed and constructed for the purposes of the present invention, or they may be of the kind well known and available to those having skill in the computer software arts. Examples of computer-readable media include, but are not limited to: magnetic media such as hard disks, floppy disks, and magnetic tape; optical media such as CD-ROMs, DVDs and holographic devices; magneto-optical media; and hardware devices that are specially configured to store and execute program code, such as application-specific integrated circuits (“ASICs”), programmable logic devices (“PLDs”) and ROM and RAM devices. Examples of computer code include machine code, such as produced by a compiler, and files containing higher-level code that are executed by a computer using an interpreter. For example, an embodiment of the invention may be implemented using Java, C++, or other object-oriented programming language and development tools. Another embodiment of the invention may be implemented in hardwired circuitry in place of, or in combination with, machine-executable software instructions.
The foregoing description, for purposes of explanation, used specific nomenclature to provide a thorough understanding of the invention. However, it will be apparent to one skilled in the art that specific details are not required in order to practice the invention. Thus, the foregoing descriptions of specific embodiments of the invention are presented for purposes of illustration and description. They are not intended to be exhaustive or to limit the invention to the precise forms disclosed; obviously, many modifications and variations are possible in view of the above teachings. The embodiments were chosen and described in order to best explain the principles of the invention and its practical applications, they thereby enable others skilled in the art to best utilize the invention and various embodiments with various modifications as are suited to the particular use contemplated. It is intended that the following claims and their equivalents define the scope of the invention.
Molnar, Steven E., French, Mark J., Legakis, Justin S., Muliadi, Lukito
Patent | Priority | Assignee | Title |
8587581, | Oct 15 2009 | Nvidia Corporation | Order-preserving distributed rasterizer |
8941653, | Oct 15 2009 | Nvidia Corporation | Order-preserving distributed rasterizer |
9213735, | Jan 25 2012 | GOOGLE LLC | Flow control in very large query result sets using a release message to confirm that a client computer is ready to receive the data associated with a data collection operation |
9501847, | Oct 15 2009 | Nvidia Corporation | Parallel line stipple computation |
Patent | Priority | Assignee | Title |
4930066, | Oct 15 1985 | Agency of Industrial Science and Technology | Multiport memory system |
5408629, | Aug 13 1992 | Unisys Corporation | Apparatus and method for controlling exclusive access to portions of addressable memory in a multiprocessor system |
5434967, | Oct 27 1992 | Nvidia Corporation | Decision variable hardware logic and processing methods for graphics display system |
5861894, | Jun 24 1993 | CHARTOLEAUX KG LIMITED LIABILITY COMPANY | Buffer manager |
5978830, | Feb 24 1997 | Hitachi, Ltd. | Multiple parallel-job scheduling method and apparatus |
6289434, | Feb 27 1998 | ALTAIR LOGIX LLC | Apparatus and method of implementing systems on silicon using dynamic-adaptive run-time reconfigurable circuits for processing multiple, independent data and control streams of varying rates |
7508397, | Nov 10 2004 | Nvidia Corporation | Rendering of disjoint and overlapping blits |
20030197707, |
Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
Apr 13 2006 | LEGAKIS, JUSTIN S | Nvidia Corporation | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 017788 | /0578 | |
Apr 13 2006 | FRENCH, MARK J | Nvidia Corporation | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 017788 | /0578 | |
Apr 13 2006 | MOLNAR, STEVEN E | Nvidia Corporation | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 017788 | /0578 | |
Apr 14 2006 | MULIADI, LUKITO | Nvidia Corporation | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 017788 | /0578 | |
Apr 19 2006 | Nvidia Corporation | (assignment on the face of the patent) | / |
Date | Maintenance Fee Events |
Apr 29 2015 | M1551: Payment of Maintenance Fee, 4th Year, Large Entity. |
Apr 23 2019 | M1552: Payment of Maintenance Fee, 8th Year, Large Entity. |
Apr 21 2023 | M1553: Payment of Maintenance Fee, 12th Year, Large Entity. |
Date | Maintenance Schedule |
Nov 15 2014 | 4 years fee payment window open |
May 15 2015 | 6 months grace period start (w surcharge) |
Nov 15 2015 | patent expiry (for year 4) |
Nov 15 2017 | 2 years to revive unintentionally abandoned end. (for year 4) |
Nov 15 2018 | 8 years fee payment window open |
May 15 2019 | 6 months grace period start (w surcharge) |
Nov 15 2019 | patent expiry (for year 8) |
Nov 15 2021 | 2 years to revive unintentionally abandoned end. (for year 8) |
Nov 15 2022 | 12 years fee payment window open |
May 15 2023 | 6 months grace period start (w surcharge) |
Nov 15 2023 | patent expiry (for year 12) |
Nov 15 2025 | 2 years to revive unintentionally abandoned end. (for year 12) |