|Publication number||US7737983 B2|
|Application number||US 11/552,693|
|Publication date||Jun 15, 2010|
|Filing date||Oct 25, 2006|
|Priority date||Oct 26, 2005|
|Also published as||CN1983326A, CN1991905A, CN1991905B, CN100538737C, CN100590655C, CN101034469A, CN101034469B, CN101034470A, US7755632, US8004533, US8817029, US20070091100, US20070091101, US20070091102, US20070115292|
|Publication number||11552693, 552693, US 7737983 B2, US 7737983B2, US-B2-7737983, US7737983 B2, US7737983B2|
|Inventors||John Brothers, Timour Paltashev, Hsilin Huang, Boris Prokopenko, Qunfeng (Fred) Liao|
|Original Assignee||Via Technologies, Inc.|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (30), Non-Patent Citations (2), Referenced by (26), Classifications (14), Legal Events (2)|
|External Links: USPTO, USPTO Assignment, Espacenet|
This application claims priority to U.S. Provisional Application entitled “GPU Synchronization and Scheduling System, Method, and Apparatus,” having Ser. No. 60/730,444, as filed on Oct. 26, 2005, which is entirely incorporated herein by reference. This application is also related to copending U.S. patent applications Ser. No. 11/468,135 filed Aug. 30, 2006 and Ser. No. 11/552,649 filed Oct. 25, 2006.
The present disclosure relates to graphic processing, and more particularly, to a method and apparatus for synchronizing and controlling a graphics pipeline.
Current computer applications are generally more graphically intense and involve a higher degree of graphics processing power than predecessors. Applications, such as games, typically involve complex and highly detailed graphics renderings that involve a substantial amount of ongoing computations. To match the demands made by consumers for increased graphics capabilities in computing applications, like games, computer configurations have also changed.
As computers, particularly personal computers, have been programmed to handle programmers' ever increasingly demanding entertainment and multimedia applications, such as high definition video and the latest 3D games, higher demands have likewise been placed on system bandwidth. Thus, methods have arisen to deliver the bandwidth for such bandwidth hungry applications, as well as providing additional bandwidth headroom for future generations of applications.
For these reasons, current computer systems oftentimes include multiple processors. For example, a graphics processing unit (GPU) is an example of a coprocessor in addition to a primary processor, such as a central processing unit (CPU), that performs specialized processing tasks for which it is designed. In performing these tasks, the GPU may free the CPU to perform other tasks. In some cases, coprocessors, such as a GPU, may actually reside on the computer system's motherboard along with the CPU, which may be a microprocessor. However, in other applications, as one of ordinary skill in the art would know, a GPU and/or other coprocessing devices may reside on a separate but electrically coupled card, such as a graphics card in the case of the GPU.
A coprocessor such as a GPU may often access supplemental memory, such as video memory, for performing its processing tasks. Coprocessors may be generally configured and optimized for performing specialized tasks. In the case of the GPU, such devices may be optimized for execution of three dimensional graphics calculations to support applications with intensive graphics. While conventional computer systems and coprocessors may adequately perform when running a single graphically intensive application, such computer systems and coprocessors may nevertheless encounter problems when attempting to execute multiple graphically intensive applications at once.
It is not uncommon for a typical coprocessor to schedule its processing workload in an inefficient manner. In some operating systems, a GPU may be multitasked using an approach that submits operations to the GPU in a serialized form such that the GPU executes the operations in the order in which they were received.
One problem with this approach is that it does not scale well when many applications with differing priorities access the same resources. In this nonlimiting example, a first application that may be currently controlling the resources of a GPU coprocessor needs to relinquish control to other applications for the other applications to accomplish their coprocessing objectives. If the first application does not relinquish control to the other waiting application, the GPU may be effectively tied up such that the waiting application is bottlenecked while the GPU finishes processing the calculations related to the first application. As indicated above, this may not be a significant bottleneck in instances where a single graphically intensive application is active; however, the problem of tying up a GPU or other coprocessor's resources may become more accentuated when multiple applications attempt to use the GPU or coprocessor at the same time.
The concept of apportioning processing between operations has been addressed with the concept of interruptible CPUs that context switch from one task to another. More specifically, the concept of context save/restore has been utilized by modern CPUs that operate to save the content of relevant registers and program counter data to be able to resume an interrupted processing task. While the problem of apportioning processing between the operations has been addressed in CPUs, where the sophisticated scheduling of multiple operations is utilized, scheduling for coprocessors has not been sufficiently addressed.
At least one reason for this failure is related to the fact that coprocessors, such as GPUs, are generally viewed as a resource to divert calculation-heavy and time consuming operations away from the CPU so that the CPU may be able to process other functions. It is well known that graphics operations can include calculation-heavy operations and therefore utilize significant processing power. As the sophistication of graphics applications has increased, GPUs have become more sophisticated to handle the robust calculation and rendering activities.
Yet, the complex architecture of superscalar and EPIC-type CPUs with parallel functional units and out-of-order execution has created problems for precise interruption in CPUs where architecture registers are to be renamed, and where several dozens of instructions are executed simultaneously in different stages of a processing pipeline. To provide for the possibility of precise interrupts, superscalar CPUs have been equipped with a reorder buffer and an extra stage of “instruction commit (retirement)” in the processing pipeline.
Current GPU are becoming more and more complex by including programmable and fixed function units connected by multiple FIFO-type buffers. Execution of each GPU command may take from hundreds to several thousand cycles. GPU pipelines used in today's graphics processing applications have become extremely deep in comparison to CPUs. Accordingly, most GPUs are configured to handle a large amount of data at any given instance, which complicates the task of attempting to apportion the processing of a GPU, as the GPU does not have a sufficient mechanism for handling this large amount of data in a save or restore operation.
Modern GPU configurations that have evolved so as to handle large amounts of data have taken upon complex shapes that involve new mechanisms for synchronization for the pipeline units in data stream processing. Using programmable parallel processing units in addition to main fixed function graphics pipeline units involves maintaining the order of graphics primitive data that may be received and updated in the different stages of the GPU pipeline. Plus, maintaining multiple contexts simultaneously with interruptability in the graphics pipeline of the GPU involves the resynchronization of such interrupted context with minimal performance loss and smooth switching between an interrupted and resumed graphics context. Current GPU configurations, however, do not handle synchronization of contexts well, instead resulting in a complete flush of the pipeline, thereby resulting in less efficient operation and reduced graphics capabilities.
Further, multi pass rendering when a GPU renders a surface that becomes a source surface for a next pass also involves synchronization to avoid RAW data hazards when a second pass starts to access the shared surface. Plus, synchronization with CPU task execution when a GPU is supposed to start and/or resume a certain context execution depending upon events in CPU threads and current GPU context is also an issue in current GPU processing implementations. Yet, current CPUs are simply unable to communicate and respond to such changes in a timely manner so as to maintain pace with the increasing demands of graphics applications.
Thus, there is a heretofore-unaddressed need to overcome these deficiencies and shortcomings described above.
A method for high level synchronization between an application and a graphics pipeline comprises receiving an application instruction in an input stream at a predetermined component, such as a command stream processor (CSP), as sent by a central processing unit. The CSP may have a first portion coupled to a next component in the graphics pipeline and a second portion coupled to a plurality of components of the graphics pipeline. A command associated with the application instruction may be forwarded from the first portion to the next component in the graphics pipeline or some other component coupled thereto. The command may be received and thereafter executed. A response may be communicated on a feedback path to the second portion of the CSP. Nonlimiting exemplary application instructions that may be received and executed by the CSP include check surface fault, trap, wait, signal, internal stall, flip, and trigger.
If the application instruction is a check surface fault instruction, a command may be communicated from the CSP to a recipient component to check a virtual memory and determine the availability of all surfaces for a particular context to be executed in the graphics pipeline. The CSP may interrupt the particular context if the virtual memory lacks all surfaces for the particular context. In this instance, the CSP may switch to a new context and begin executing that context. Otherwise, execution of the particular context may continue if the virtual memory contains all surfaces for the particular context upon communicating the command from the CSP to the recipient component.
An interrupt may also be generated to retrieve all surfaces not contained in the virtual memory from the location where the surfaces are stored. When all of the surfaces are retrieved and available in the virtual memory, the CSP may subsequently resume execution of the previously interrupted context.
If the application instruction is a trap instruction, the CSP may forward a trap token from the first portion (which may be known as a front-end portion) of the CSP to the next component in the graphics pipeline. Thereafter, the trap token may be communicated through the graphics pipeline to a graphics pipeline last stage component, which, as a nonlimiting example, may be a write back unit.
The graphics pipeline last stage component may then communicate the trap token back to the CSP, but to the second portion of the CSP (which may be known as a back-end portion) that is configured for receiving such communications. Thereafter, the CSP may generate an interrupt message to the central processing unit associated with receipt of the trap token by the second portion of the CSP. The central processing, unit upon receipt of the interrupt message, may recognize receipt of the interrupt message in association with an end of processing in the graphics pipeline of a designated command or data, such as a given context. Also, the CSP may store identification information about the trap token in a memory.
If the application instruction is a wait instruction, the CSP, after recognizing the wait instruction in the input stream from the central processing unit to the CSP, may check a counter to determine if a value of the counter is greater than or equal to a threshold value. The threshold may be set at zero or some other predetermined or predefined value. If the value of the counter is greater than the threshold value, the CSP may decrement the counter and continue to execute instructions associated with a current graphics context. However, if the value of the counter is equal to the threshold value, then the CSP (or a portion of the CSP) may cause a switch from the current graphics context to another graphics context, which may be a set of instructions in a list of contexts wherein each context pertains to a different set of instructions for related objects. In switching to another graphics context, an instruction pointer may also be reset by the CSP for the new graphics context to be executed.
This counter may, as a nonlimiting example, be an internal flip counter on the graphics processing unit or may be external in a coupled video memory. Plus, in at least one nonlimiting example, the counter (either internal or external in memory) may be configured as a 64-bit counter, but one of ordinary skill in the art would know that counters of other logical sizes could also be used.
If the application instruction is a signal instruction, the CSP, upon recognizing such in the input stream from the central processing unit to the CSP, may increment a counter by one unit. The counter may be logically located in correspondence with an address contained in the signal command. Thereafter, the CSP may interrupt the central processing unit if a predetermined bit is set to a predetermined logical state and a value of the counter changes from a first particular value to a second particular value. As nonlimiting examples, the first particular value may be zero (0), and the second particular value may be (1).
If the application instruction is a flip instruction, the CSP may send a flip token from a first portion of the CSP to the next component in the graphics pipeline, which could be a triangle setup unit, as one of ordinary skill in the art would know. The flip token may migrate through the graphics pipeline to a last stage component in the graphics pipeline, which, as one of ordinary skill in the art would know, could be a write back unit. The last stage component in the graphics pipeline may thereafter forward the flip token to a second (or back-end portion) of the CSP that is configured to receive such communications.
Upon receipt of the flip token, the CSP may engage in a wait configuration for a signal to be received from a display interface unit, which may be one of many units or components in the graphics processing unit that are coupled to the CSP. The CSP may also, however, program a predetermined register of the display interface unit with data associated with the flip token.
So as to avoid stalling the last stage component in the graphics pipeline, the CSP may be coupled to a buffer configured to receive flip tokens from the last stage component. The buffer may be a FIFO, which forwards the flip tokens to the CSP in the order received from the last stage component in the graphics pipeline.
Yet another application instruction executable by the CSP is a mask instruction. The mask instruction provides that the CSP may check a designated counter to determine if a value of the counter is equal to a predefined value, such as zero (0). If so, the CSP may check for the receipt of a predefined signal from a predefined unit, such as the display interface unit. The CSP may be stalled from further operations until the signal is received from the predefined unit. However, if the value of the counter, when checked by the CSP is greater than the predefined value, which, again, could be zero (0), the CSP may decrement the counter by one.
The CSP may also be configured to receive a trigger instruction in the input stream, which may lead to a predefined response. As a nonlimiting example, the CSP may output an operation code, or opcode to a target component, which, as a nonlimiting example, could be any unit in the graphics processing unit. The opcode may instruct the target component to take a predefined action, which when received by the target component, results therein. As nonlimiting examples, the predefined actions could include: a preload action, a flush action, and a drain action.
Based on the type of trigger instruction, the CSP may or may not be stalled until completion of the operation contained in the trigger, which may be performed by one or more components other than the CSP in the graphics pipeline. So the CSP may be instructed to wait and may continuously check the status of the wait mask (counter) to determine if it has been lifted. When lifted, the CSP may resume processing operations in the input stream.
The application instruction may comprise an operation code portion and at least one double word portion containing at least one of identification information, address information, and data. As a nonlimiting example, each operation code and at least one double word portion may be 32 bits.
The application instruction may also be an internal stall instruction, which comprises receiving the internal stall instruction in the input stream at the CSP. Thereafter a flip counter may be checked to determine if a value of the counter is equal to a predefined value. The CSP may further check for receipt of a predefined signal from a predefined unit if the value of the counter is equal to the predefined value. Thereafter, the CSP may stall from additional operations until the predefined signal is received.
A wait mask counter may be checked in accordance with the internal stall instruction. The CSP may be stalled from additional operations if the wait mask counter is not a predefined value, such as 0.
Yet another type of receivable instruction is a wait mask instruction, which comprises receiving a wait instruction in the input stream at the CSP with a wait mask set portion. The CSP may also receive a target operation command that is forwarded to a block in the graphics pipeline. The block in the graphics pipeline may perform a predetermined operation in correspondence with data in the target operation.
The CSP may receive a wait clear trigger instruction that is forwarded to the block in the graphics pipeline and subsequently back to the CSP. An internal wait command with a wait mask status check may be received at the CSP, and a determination may be made whether the wait clear trigger instruction has been received back at the CSP such that the wait mask set portion may be cleared.
These features described herein in this section of the disclosure are merely nonlimiting examples, as additional information related to these nonlimiting examples are described in the sections that follow and the figures of this disclosure.
Computer 12 may include a variety of computer readable media. Computer readable media can be any available media that can be accessed by computer 12 and includes both volatile and nonvolatile memory, which may be removable, or nonremovable memory.
The system memory 18 may include computer storage media in the form of volatile and/or nonvolatile memory, such as read only memory (ROM) 24 and random access memory (RAM) 26. A basic input/output system 27 (BIOS) may be stored in ROM 24. As a nonlimiting example, operating system 29, application programs 31, other program modules 33, and program data 35 may be contained in RAM 26.
Computer 12 may also include other removable/nonremovable volatile/nonvolatile computer storage media. As a nonlimiting example, a hard drive 41 may read from or write to nonremovable, nonvolatile magnetic media. A magnetic disk drive 51 may read from or write to a removable, nonvolatile magnetic disk 52. An optical disk drive 55 may read from or write to optical disk 56.
A user may enter commands and information into computer 12 through input devices such as keyboard 62 and pointing device 61, which may be coupled to processing unit 16 through a user input interface 60 that is coupled to system bus 21. However, one of ordinary skill in the art would know that other interface and bus structures such as a parallel port, game port, or a universal serial bus (USB) may also be utilized for coupling these devices to the computer 12.
One or more graphics processing units (GPUs) 84 may communicate with the graphics interface 82 that is coupled to system bus 21. As a nonlimiting example, GPU 84 may include on-chip memory storage, such as register storage and cache memory. GPU 84 may also communicate with a video memory 86, as desired.
A monitor 91 or other type of display device may be also coupled to system bus 21 via a video interface 90, which may also communicate with video memory 86. In addition to monitor 91, computer system 10 may also include other peripheral output devices, such as printer 96 and speakers 97, which may be coupled via output peripheral interface 95.
Computer 12 may operate in networked or distributed environments using logical connections to one or more remote computers, such as remote computer 80. Remote computer 80 may be a personal computer, a server, a router, a network PC, a pier device, or other common network node. Remote computer 80 may also include many or all of the elements described above in regard to computer 12, even though only memory storage device 81 and remote application programs 85 are depicted in
In this nonlimiting example of
As stated above, the GPU 84 may be configured to switch processes, or contexts, during the processing of another context, or operation. In this instance, the GPU 84 is configured to save an interrupted context and to initiate processing of another context, which itself may have been previously interrupted and saved.
GPU 84 may be configured to support sequential execution of multiple GPU programs (commands) belonging to the same context. Yet, as stated above, in order to synchronize execution of the GPU 84 in tandem with processing unit 16, multiple levels or synchronization may be utilized.
A global level memory data access system synchronization may be a first high level method of synchronizing the processing unit 16 application or driver and a GPU context being implemented by GPU 84. As a second level or an intermediary level of synchronization, memory data access synchronization may occur between two GPU contexts that are being implemented with GPU 84. Thus, as described above, synchronization between two contexts may occur in the instance where one context in interrupted so that a second context may resume or initiate from prior execution. Or another case may be that a second context uses data from a memory surface generated by a first context in the same GPU, which cannot be started before the first context has finished all writes to the particular memory surface. As a third level of synchronization, the pipeline in GPU 84 itself may be configured such that the individual unit or components of the pipeline may be synchronized, which may constitute a lower internal level of synchronization. Thus, three levels of synchronization may be utilized so that the processing unit 16 may be synchronized in tandem with GPU 84 to handle complex and convoluted processing operations.
Specifically, upon receiving Fence Command A (reference 103) in the GPU command and data stream buffer in memory, which may be written by the CPU application 101, a fence command and data may be written by GPU 84 (as implementing GPU context 102) to registry 104 in system or video memory 86 of
CPU application 101 may attempt to read the data value of registry 104 so that a comparison between fence and wait values is made. The comparison may indicate to the CPU application 101 whether the GPU context 102 has accomplished a predetermined action, such as completion of a designated task, which might, as a nonlimiting example, enable CPU application 101 to utilize certain data for additional processing operations.
GPU context 102 may subsequently receive Wait A command 106 from the GPU command and data stream shown in
As a nonlimiting example, medium level synchronization may be accomplished between multiple GPU contexts, such as contexts 1 and 2 of
By causing data associated with each of the fence and wait commands 107 a, 107 b to be written to the MXU 109 (in this nonlimiting example), a GPU graphics pipeline component may wait for data associated with context 1 to be processed to a designated point so that further and related processing can occur at a higher logical point in the GPU graphics pipeline 108 on data associated with context 2. In this way, GPU graphics pipeline 108 is able to implement a medium level-type of data synchronization between two disparate GPU contexts. For more information about internal fence and wait synchronization commands, please refer to U.S. patent application Ser. No. 11/552,649 regarding same, which is hereby incorporated by reference.
Command stream processor 114 (CSP) may be a predetermined component that is logically positioned on the top of GPU graphics pipeline 110 and provides control over the entire GPU graphics pipeline 110. CSP 114 executes the above-described high and medium level synchronization schemes and also generates a number of internal tokens for low level synchronization inside the GPU graphics pipeline, as also discussed above. CSP 114 may be configured with instructions that are relevant for each of the above-described levels of synchronization.
As a nonlimiting example, some of the instructions that may be configured in the CSP 114 for implementing each of the above-described synchronization levels are as follows:
May be placed in context
position as placemarker
when current context to
be executed and not
Draw primitive command
Draw indexed command
2D Polyline support
2D data/Master Image
Header command for 2D
data block from host
Synchronization of input
stream processing with
synchronization - Stall
display scan and wait
of input parsing until
selected display sync
signal or wait mask
High level sync virtual
High level synchronization -
memory mechanism support
Switch to another context
if surface not paged in
Stream buffer pointer
Set GPU registers in
May require sync with
command or restore all
Save GPU state registers
in the memory
Update active GPU context
list (Not a stream
Enable GPU exceptions/
1-BPP engine command
synchronization - Stall
particular block in
access to the memory
to prevent RAW hazard
Interrupt CPU and provide
Counter control command
Counter dump command
synchronization - Input
Stream parse control
based on query registers
Medium and low level
Display sync command
switch at the end of
High level sync command
synchronization - Wait
on the external counter
in the memory
High level sync command
Increment external sync
counter in the memory
Internal GPU command
for tracing DMA buffer
Low-level GPU pipeline
sync command (token)
generated token for low
For a number of these commands implemented by the CSP 114, which are discussed in more detail below, the following constitutes the CSP 114 synchronization command format:
1F - Sync
As recited above, the CheckSurfaceFault (or CheckFault) command provides high level synchronization in terms of checking availability of all surfaces in virtual memory (VM) for a particular GPU context. This command may generally be configured in the beginning of a context that is executed by the GPU graphics pipeline 110. If some surfaces associated with the context are not available, the CheckSurfaceFault command may cause a VM mechanism to page the surfaces. In that case, the current context may be interrupted and switched so that another context is executed while the VM mechanism pages the surfaces. The CSP 114 cooperates with MXU (Memory Access Unit) 109, which supports the VM mechanism and generates interrupts for the processing unit 16 (or other CPU) to engage the VM mechanism.
As shown in
As discussed above, if some surfaces associated with the context are not available, the CheckSurfaceFault command may cause the MXU 109 to page the surfaces in videomemory or main memory. In this instance, the MXU 109 may interrupt the CPU (processing unit 16 of
Also referenced above is a trap instruction. A trap is an instruction that may generate a CPU interrupt when processed by the GPU 84 through a component of the GPU graphics pipeline 110, such as a write back unit component 119, as shown at the bottom of the GPU graphics pipeline 110 in
As data and commands are pushed from the CSP front-end portion 114 a into the GPU graphics pipeline 110, as shown in
The CSP back-end portion 114 b may notify the CPU (processing unit 16 of
A wait instruction is an instruction that may be inserted in a DMA stream to inform the CSP 114 that it should inspect the value of a specified counter, which in this nonlimiting example may be a 64-bit counter.
If the aforementioned counter has a non-zero value, as a nonlimiting example, the CSP 114 should decrement the counter and continue executing the current GPU context. However, if the value of the counter is zero (0), as a nonlimiting example, the CSP 114 may reset an instruction pointer of a current GPU context to position before the wait instruction and switch to the next context in a run list, which may be a set of contexts to be executed by the GPU 84. When a GPU context needs to stop on a wait instruction and is later rescheduled, the CSP 114 may re-execute the wait instruction, since it is possible that the wait condition is not satisfied.
Instead of checking an internal flip counter, the wait instruction may cause the CSP front-end portion 114 a to check a counter in memory 86. Specifically, a counter in memory 86 may be checked and decremented if not equal to zero (in this nonlimiting example) in similar fashion than as described above. At least one difference, however, when an external wait command is implemented is that an external memory access operation results, whereas the internal flip counter may be one that is retained locally to the GPU 84, thereby potentially resulting in a faster operation.
The command for a wait instruction may take the following form:
0 = the command operates external 64-bit counter by the
1 = the command operates the internal counter
DWF (num of DWORD following). DWF = 00 or 01.
TD - disable virtual to physical address translation
0 = the address is to be translated by the MXU
1 = the MXU should not translate the address
In addition to a wait operation, the CSP 114 may be configured to engage in a signal operation.
A signal instruction may be inserted in a data stream to inform the GPU 84 that it should update the value of a designated 64-bit counter located by a specified address. The CSP front-end portion 114 a may implement receive the signal instruction in the GPU command stream, as shown in
In this nonlimiting example, the CSP front-end portion 114 a may ignore the potential overflow during the addition. If an interrupt bit (or another predetermined bit) is set in the instruction, the CSP 114 front-end portion 114 a may also send a CPU interrupt to the processing unit 16 (which is shown in
The command for a signal instruction may take the following form:
INT Interrupt on 0→1 transition; this way the signal
instruction will be implemented, sending an interrupt request
when the counter value changes from 0 to 1
DWF (num of DWORD following). DWF = 1.
TD - disable translate
0 = the address is to be translated by the MXU 109
1 = the MXU 109 should not translate the address
Address 64-bit aligned
Another instruction implemented in the CSP 114 of
The flip instruction may take the following form:
SHOW-The frame is shown for back-end Flip operations
SS2 VERTICAL SYNC
SS1 VERTICAL SYNC
HS1 HORIZONTAL SYNC
PS2 VERTICAL SYNC
PS1 VERTICAL SYNC
HS2 HORIZONTAL SYNC
Flip ID - for front end flip operations. The Flip ID may be
used by the driver when parsing the event history buffer
FE—Front End. Distinguishes Front end and back end flip
INT - for front end flip operations. The CSP sends an
interrupt request to the CPU on the flip's execution
ADDR - The starting address of the first DIU register to
DWF - the number of registers to program (up to 3, 1 for a
To prevent stalling the last GPU pipeline last stage unit 121, as shown in
A waiting for sync flip command (or instruction) may be stored in the retaining buffer 137. If a fence or other predetermined command immediately follows the flip instruction, the fence command may be stacked together with the flip instruction in the retaining buffer 137. All subsequent flip+fence pairs may also be stacked in the retaining buffer 137.
The CSP 114 may invalidate earlier flip instructions with the same ADDR value, as shown in the nonlimiting exemplary addressing format above, that is, if there are any stored in the retaining buffer 137. To prevent the CSP 114 from invalidating earlier flip instructions, the SHOW bit, as shown above, may be set in a command. A flip instruction with SHOW bit set (bit 0) would not be dropped by the CSP 114.
When a flip command or instruction is executed, a flip counter may be incremented. The flip counter may be decremented by a complimentary wait command or instruction, as described above.
Another command that may be implemented by the CSP 114 is an internal wait (or stall) instruction. An internal stall instruction may be configured to stall the CSP 114 while waiting for occurrence of a display retrace signals coming from DIU with a preliminary check of the flip counter, or clearing wait mask preliminary set by a trigger instruction, as shown in
Nevertheless, if the flip counter is not equal to zero (0), as shown in
However, if the flip counter is zero (0), then the CSP front-end portion 114 a will wait for occurrence of a display retrace signal (or other signal) from the display interface unit (or other predefined unit). More specifically, and as shown in
The form of an internal stall instruction, as may be received by the CSP front-end portion 114 a may be configured as follows:
HS2 horizontal sync
SS2 vertical sync
SS1 vertical sync
HS1 horizontal sync
PS2 vertical sync
PS1 vertical sync
2D - 2D FE idle
SPP - SPP idle
AES - AES idle
PG - Paging idle
Flip counter status stall:
FC—Flip Counter (see Optimized Flip Support for
0 = Not sensitive to status of Optimized Flip Counter
1 = Stall CSP FE if Flip Counter = 0 and wait until status
change; otherwise it will decrement the counter and
Wait flag (mask) stall or complete pipeline flush command.
0 = do not wait for the wait mask to become 0
1 = wait for the wait mask to become 0 (see CSP wait
DWF = 00
The CSP wait mask, which in this nonlimiting example is represented at bit 18, enables the software driver to synchronize for the CSP 114 to receive information from the GPU graphics pipeline 110. Setting and clearing the wait mask can be, as a nonlimiting example, accomplished through a trigger command communicated down the GPU graphics pipeline 110 and back to the CSP 114.
Thereafter, a CSP internal wait (or stall) command may issued to wait for the CSP wait mask (or counter) to be cleared. This command sequence may cause the CSP 114 to suspend parsing the input command stream until all MXU 109 registers are received and the CSP trigger token is passed through the MXU 109. However, one of ordinary skill in the art would know that this example with MXU 109 is nonlimiting, as one or more other blocks or components of the GPU graphics pipeline 110 could be used as well.
As shown in
A subsequent trigger command 157 may be received by the CSP front-end portion 114 a and forwarded to the MXU 109 and on to the CSP back end portion 114 b. This command 157 may contain a clear wait mask (or decrement) option, as shown in
Thus, MXU 109 may ultimately forward the wait clear command 157 on to a wait mask register at CSP back-end portion 114 b, which subsequently correlates to a corresponding register in CSP front-end portion 114 a. In so doing, CSP 114 will effectively suspend parsing the input command stream until all MXU 109 registers are received and the CSP Trigger token (in this instance, wait clear command 157) is passed through the MXU 109.
As indicated with respect to the wait (or stall) instruction, the CSP may implement a trigger function or instruction. The trigger instruction may cause the CSP 114 to initiate a preload, invalidate, flush, drain, clear, autoclear operation, or other predetermined actions on various blocks or units in the GPU graphics pipeline 110 of
Bits 7-0 Trigger bits; specify an operation to be implemented or executed.
Bits 14:10 Block ID; identify the particular block in GPU graphics pipeline 110 for receipt of the trigger command for the predetermined action.
Bits 20:16 Auxiliary Block ID. These bits identify an alternate block in the graphics pipeline 100. This information may relate to a block ID to send the command to in the event that bit 21, BE, is set to 1 If BE (bit 21)=0, then the Auxiliary Block ID field of bits may be ignored.
Bit 21-BE (back-end). This bit corresponds to a CSP “Back end” trigger, which may be sent through the GPU graphics pipeline 110 along with the Auxiliary Block ID (bits 20:16) back to the CSP for synchronization purposes.
Bit 22-POS (position). This bit relates to whether the CSP 114 should send a position command down the GPU graphics pipeline 110 for the corresponding trigger command.
Bits 25-24—DWF (double words). The field specifies how many “range” information use depends on the recipient block for the trigger command, as some blocks may call for more or fewer DWs.
This trigger command may be configured as a multifunctional internal buffer management and synchronization command that may, as a nonlimiting example, be directed a number of the units (or blocks) of the GPU graphics pipeline 110. The action of the trigger command in each unit of the graphics pipeline 110 can be defined by trigger bit mask [7:0], as discussed above. Plus, action in each of the potential recipient blocks might be different depending on functionality of that particular pipeline block in GPU graphics pipeline 110, such as CSP 114, MXU 109, SG (Shade Generator) 117, ASU (Attribute Setup Unit) 118, WBU (Write Back Unit) 119, as well as a host of other component blocks shown in
In at least one nonlimiting example, as discussed above, trigger commands may be directed to the CSP 114. In this instance, as discussed above for CSP-directed trigger commands, control bits POS  and backend BE  may be used, as discussed above, in combination with an auxiliary block ID [20:16].
As a nonlimiting example, the following table may describe a nonexclusive number of CSP 114 directed trigger command options:
Description and relation to other commands
Sending the CSP trigger “clear dirty” may
force the CSP 114 to mark all its shadow register
buffer's contents as “clean”. That may lead
to the CSP 114 not flushing the “dirty” contents
on a next command. This command may be used at the
debug/verification stage to help minimizing the
size of the dumps after the initial Restore All
Clear Wait mask
Set Wait mask
The CSP Trigger “flush Q$” command is
intended to flush all non-saved contents of the
CSP query cache and save the contents of the query
flags' memory to the specified location. The
command is executed at the CSP FE only. There
should always be the address of the location to
save the predicated ID data in the command.
The CSP Trigger “load Qid” command is
intended to have the previously stored contents of
the query predicates' buffer loaded back to the
CSP buffer. This command also requires DW to
be the address of the 512-bit aligned buffer where
predicated were saved.
However, CSP 114 may also redirect the trigger command to the CSP back-end 114 b via a particular pipeline block defined in the auxiliary block ID field, which in this nonlimiting example may be bits 20:16.
As shown in
The recipient pipeline block J (reference numeral 169), after receiving trigger command 167 and implementing the instructed action, which could include: marking cache contents invalid, flushing caches to memory, dumping predetermined registers, invalidating page tables, termination of certain requests, etc.—all as nonlimiting examples. Upon completion of the action specified by trigger command 167, the pipeline block J (reference number 169), as shown in
The method also comprises forwarding a GPU command associated with the application instruction from the first portion to at least one of the next component and another component coupled to the predetermined component, as shown in step 184. The method may further comprise receiving the GPU command associated with the application instruction at the at least one of the next component and the another component, the at least one of the next component and the another component executing a predetermined number of actions associated with the GPU command, as shown in step 186.
It should be emphasized that the above-described embodiments and nonlimiting examples are merely possible examples of implementations, merely set forth for a clear understanding of the principles disclosed herein. Many variations and modifications may be made to the above-described embodiment(s) and nonlimiting examples without departing substantially from the spirit and principles disclosed herein. All such modifications and variations are intended to be included herein within the scope of this disclosure and protected by the following claims.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US4855936 *||Sep 25, 1987||Aug 8, 1989||International Business Machines Corp.||Full-screen input/output application program interface|
|US4862155 *||Oct 26, 1987||Aug 29, 1989||Tektronix, Inc.||Graphic display system with secondary pixel image storage|
|US4916301 *||Jan 17, 1989||Apr 10, 1990||International Business Machines Corporation||Graphics function controller for a high performance video display system|
|US5097411 *||Oct 17, 1988||Mar 17, 1992||Digital Equipment Corporation||Graphics workstation for creating graphics data structure which are stored retrieved and displayed by a graphics subsystem for competing programs|
|US5230039 *||Feb 19, 1991||Jul 20, 1993||Silicon Graphics, Inc.||Texture range controls for improved texture mapping|
|US5293587 *||Jun 1, 1990||Mar 8, 1994||Chips And Technologies, Inc.||Terminal control circuitry with display list processor that fetches instructions from a program memory, character codes from a display memory, and character segment bitmaps from a font memory|
|US5299309 *||Jan 2, 1992||Mar 29, 1994||Industrial Technology Research Institute||Fast graphics control system capable of simultaneously storing and executing graphics commands|
|US5315696 *||Aug 21, 1991||May 24, 1994||Digital Equipment Corporation||Graphics command processing method in a computer graphics system|
|US5706478||Nov 14, 1994||Jan 6, 1998||Cirrus Logic, Inc.||Display list processor for operating in processor and coprocessor modes|
|US6208361||Jun 15, 1998||Mar 27, 2001||Silicon Graphics, Inc.||Method and system for efficient context switching in a computer graphics system|
|US6252610||May 29, 1998||Jun 26, 2001||Silicon Graphics, Inc.||Method and apparatus for efficiently switching state in a graphics pipeline|
|US6329996||Jan 8, 1999||Dec 11, 2001||Silicon Graphics, Inc.||Method and apparatus for synchronizing graphics pipelines|
|US6476808||Oct 14, 1999||Nov 5, 2002||S3 Graphics Co., Ltd.||Token-based buffer system and method for a geometry pipeline in three-dimensional graphics|
|US6483505||Mar 17, 2000||Nov 19, 2002||Ati International Srl||Method and apparatus for multipass pixel processing|
|US6708269||Dec 30, 1999||Mar 16, 2004||Intel Corporation||Method and apparatus for multi-mode fencing in a microprocessor system|
|US6782432||Jun 30, 2000||Aug 24, 2004||Intel Corporation||Automatic state savings in a graphics pipeline|
|US6806880||Oct 17, 2000||Oct 19, 2004||Microsoft Corporation||System and method for efficiently controlling a graphics rendering pipeline|
|US6833831||Feb 26, 2002||Dec 21, 2004||Sun Microsystems, Inc.||Synchronizing data streams in a graphics processor|
|US6867781 *||Nov 28, 2000||Mar 15, 2005||Nintendo Co., Ltd.||Graphics pipeline token synchronization|
|US6954204 *||Nov 22, 2002||Oct 11, 2005||Nvidia Corporation||Programmable graphics system and method using flexible, high-precision data formats|
|US7353369||Jul 13, 2005||Apr 1, 2008||Nvidia Corporation||System and method for managing divergent threads in a SIMD architecture|
|US20030001840||Jun 1, 2001||Jan 2, 2003||Spitzer John Fredric||Method and system for synchronizing updates of vertex data with a graphics processor that is fetching vertex data|
|US20030023971||Feb 9, 2001||Jan 30, 2003||James Martinolich||Incorporating graphics and interactive triggers in a video stream|
|US20030169259||Mar 8, 2002||Sep 11, 2003||Lavelle Michael G.||Graphics data synchronization with multiple data paths in a graphics accelerator|
|US20040008200 *||Jul 12, 2002||Jan 15, 2004||Naegle Nathaniel David||Method for context switching a graphics accelerator comprising multiple rendering pipelines|
|US20040135787||Nov 20, 2003||Jul 15, 2004||Nintendo Co., Ltd.||Graphics system interface|
|US20040160446||Jan 22, 2004||Aug 19, 2004||Gosalia Anuj B.||Multithreaded kernel for graphics processing unit|
|US20040189650||Mar 31, 2003||Sep 30, 2004||Deering Michael F.||Accelerator control unit configured to manage multiple hardware contexts|
|US20050030311||Jul 15, 2004||Feb 10, 2005||Renesas Technology Corp.||Data processor and graphic data processing device|
|US20050046633 *||Aug 25, 2003||Mar 3, 2005||Ati Technologies, Inc.||Method and apparatus for graphics rendering on a mobile device|
|1||Brothers, et al., Non-Final Office Action, mailed Apr. 22, 2009, filed Aug. 30, 2006, U.S. Appl. No. 11/468,435.|
|2||Brothers, et al., Non-Final Office Action, mailed Jun. 8, 2009, filed Oct. 25, 2006, U.S. Appl. No. 11/552,649.|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US7821931||Oct 25, 2007||Oct 26, 2010||Extreme Networks, Inc.||System and method for assembling a data packet|
|US7822032 *||Mar 30, 2004||Oct 26, 2010||Extreme Networks, Inc.||Data structures for supporting packet data modification operations|
|US8139583||Sep 30, 2008||Mar 20, 2012||Extreme Networks, Inc.||Command selection in a packet forwarding device|
|US8698808||Apr 29, 2011||Apr 15, 2014||Nvidia Corporation||Conversion of dashed strokes into quadratic Bčzier segment sequences|
|US8698837||May 18, 2011||Apr 15, 2014||Nvidia Corporation||Path rendering with path clipping|
|US8704830||May 19, 2011||Apr 22, 2014||Nvidia Corporation||System and method for path rendering with multiple stencil samples per color sample|
|US8730253||Apr 29, 2011||May 20, 2014||Nvidia Corporation||Decomposing cubic Bezier segments for tessellation-free stencil filling|
|US8773439||Apr 29, 2011||Jul 8, 2014||Nvidia Corporation||Approximation of stroked higher-order curved segments by quadratic bčzier curve segments|
|US8786606||Apr 29, 2011||Jul 22, 2014||Nvidia Corporation||Point containment for quadratic Bčzier strokes|
|US8856446 *||Sep 28, 2011||Oct 7, 2014||Texas Instruments Incorporated||Hazard prevention for data conflicts between level one data cache line allocates and snoop writes|
|US8976185 *||Nov 11, 2011||Mar 10, 2015||Nvidia Corporation||Method for handling state transitions in a network of virtual processing nodes|
|US9063974 *||Feb 26, 2013||Jun 23, 2015||Oracle International Corporation||Hardware for table scan acceleration|
|US9147224 *||Nov 11, 2011||Sep 29, 2015||Nvidia Corporation||Method for handling state transitions in a network of virtual processing nodes|
|US9202303 *||May 20, 2011||Dec 1, 2015||Nvidia Corporation||System and method for compositing path color in path rendering|
|US9251272||Mar 7, 2013||Feb 2, 2016||Oracle International Corporation||Reconfigurable hardware structures for functional pipelining of on-chip special purpose functions|
|US9292569||Feb 26, 2013||Mar 22, 2016||Oracle International Corporation||Semi-join acceleration|
|US9311738||May 4, 2011||Apr 12, 2016||Nvidia Corporation||Path rendering by covering the path based on a generated stencil buffer|
|US9317960||May 13, 2011||Apr 19, 2016||Nvidia Corporation||Top-to bottom path rendering with opacity testing|
|US20110285735 *||Nov 24, 2011||Bolz Jeffrey A||System and method for compositing path color in path rendering|
|US20120198162 *||Aug 2, 2012||Texas Instruments Incorporated||Hazard Prevention for Data Conflicts Between Level One Data Cache Line Allocates and Snoop Writes|
|US20130120412 *||May 16, 2013||Sean J. Treichler||Method for handling state transitions in a network of virtual processing nodes|
|US20130120413 *||May 16, 2013||Sean J. Treichler||Method for handling state transitions in a network of virtual processing nodes|
|US20140095468 *||Feb 26, 2013||Apr 3, 2014||Oracle International Corporation||Hardware for table scan acceleration|
|US20140135067 *||Jan 29, 2013||May 15, 2014||Nvidia Corporation||Wireless base station device and communication system including the wireless base station device|
|US20140176577 *||Dec 20, 2012||Jun 26, 2014||Nvidia Corporation||Method and mechanism for preempting control of a graphics pipeline|
|US20150261871 *||May 11, 2015||Sep 17, 2015||Oracle International Corporation||Hardware for performing a database operation|
|U.S. Classification||345/522, 345/506|
|International Classification||G06F1/20, G06T1/00|
|Cooperative Classification||G06F9/485, G06F9/526, G06F9/3879, G06F9/542, G06T1/20|
|European Classification||G06F9/38S1, G06F9/52E, G06F9/54B, G06F9/48C4P, G06T1/20|
|Jan 10, 2007||AS||Assignment|
Owner name: VIA TECHNOLOGIES, INC., TAIWAN
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:BROTHERS, JOHN;PALTASHEV, TIMOUR;HUANG, HSILIN;AND OTHERS;REEL/FRAME:018735/0626;SIGNING DATES FROM 20061115 TO 20061212
Owner name: VIA TECHNOLOGIES, INC.,TAIWAN
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:BROTHERS, JOHN;PALTASHEV, TIMOUR;HUANG, HSILIN;AND OTHERS;SIGNING DATES FROM 20061115 TO 20061212;REEL/FRAME:018735/0626
|Nov 13, 2013||FPAY||Fee payment|
Year of fee payment: 4