DE19806580A1 - Centralized two-intelligence system and method for a geometry accelerator - Google Patents

Description

The present invention relates generally to Com computer graphics systems and especially on a distributed one Branch logic system and method for enabling one efficient multipath logic branching in ROM-based control generation units of a high-performance geometry accelerator.

Computer graphics systems are commonly used to display graphic representations of objects on a two-dim sional ad used. Current computer graphics system me provide a highly detailed visual representation of Objects, and the same are used in a variety of applications uses.

A typical computer using a computer graphics system is shown in FIG. 1. Referring to FIG. 1, a computer 11 includes a central processing unit (CPU) 12 , a system memory 14 for storing software executed by the CPU 12 , a graphics system 16 for processing graphics data received from the CPU 12 a local interface 18 , which is configured to electrically connect the preceding elements to each other, and a display 21 , which is connected to the graphics system 16 via a connection 22 , and which is configured to the image data generated by the graphics system 16 display.

The graphics system 16 breaks down the objects to be displayed on the display 21 into graphics primitives. "Primitives" are basic components of image data, and they can include points, lines, vectors, and polygons, such as. B. Triangles and Trape zoide (four sides) include. Typically, the hardware and / or software is implemented in graphics system 16 to render or draw the graphics primitives that represent a view of one or more objects that are shown on display 21 .

In general, the primitives of an object to be processed are defined by the CPU 12 with primitive data. For example, if a primitive is a triangle, the CPU 12 may define the primitive with, among other things, coordinates x, y and z and color values (e.g. red, green, blue) of its vertices. Additional primitive data can be used in specific applications. The rendering hardware in a rasterizer of the graphics system finally interpolates the primitive data to calculate the final display screen pixel values that represent each primitive and the R, G, and B color values for each pixel.

The graphics system 16 is shown in more detail in FIG. 2. As shown in Fig. 2, the computer graphics system 16 includes one or more geometry accelerator 23, which are riert confi, gene to vertex data from the CPU 12 to are received, and to define the primitives to be displayed view bil the. Each geometry accelerator 23 has a number of special control units 17 for processing the image data, which, for example, a transforming device TRANSFORM 24 for performing transformations on the vertex data, such as. B. a scaling or moving a vertex in space, a clipping device CLIP 26 for clipping off from objects that extend over a boundary, a light device LIGHT 28 for amplifying the image data by simulating light conditions, and a plane equation device PLANE 32 to define the primitive with mathematical floating point level equations. The control units 17 are typically implemented via cell logic and as separate, different state machines. The output of the geometry accelerator 23 , referred to as rendering data, is used to generate end screen coordinates and color data for each pixel and primitive. The output 33 becomes a floating point to fixed point transformation unit FP-TO- FIXED 34 , which converts the geometry accelerator output 33 into a fixed-point format 35 , and which forwards the value to a raster device 36 . The rasterizer 36 generates pixel data 37 that is communicated to a frame buffer controller 38 and then to a frame buffer 42 . The frame buffer 42 serves to temporarily store the pixel data before communicating with the display. The pixel data is passed from frame buffer 42 through a digital-to-analog converter (DAC) 44 and then to a display 21 .

The operations of the geometry accelerator 23 are highly mathematical and computation-intensive. A frame of a three-dimensional (3D) graphic display can include hundreds of thousands of primitives. To achieve prior art performance, the geometry accelerator 23 may need to perform several hundred million floating point calculations per second. In addition, the volume of data transmission between the CPU 12 and the graphics system 16 is very large. The data for a single trapezoid can be on the order of 64 words, 32 bits each. Additional data transferred from the CPU 12 to the geometry accelerator 23 includes light parameters, clipping parameters, and other parameters needed to generate the graphic image for the display 21 .

It is common for geometry accelerators 23 to have a stack of processing elements 52 as shown in FIG. 3, the same an arithmetic logic unit (ALU) 54 , a multiplier 55 , a divider 56 , a comparison device COMPARE 57 , a clamping device CLAMP 58 , etc. together with a register and a direct access memory (RAM) working memory 61 , 62 includes, but is not limited to. The processor elements are typically shared by the plurality of special control units 17 . Each control unit 17 can control the processing activities of individual processor elements 52 in order to carry out specific calculation tasks.

In order to create a processor element for each control unit 17 , an adequate control line connection option and access control should be set up between the processor elements 52 and each control unit 17 . A solution for creating the control line connection possibility is shown in FIG. 3, and is associated with a multiplexing of the control lines between each control unit and each processor element 52 . A multiplexer (MUX) 66 of FIG. 3 serves this purpose. The MUX 66 is controlled by a MUX controller 68 . The MUX controller 68 provides an enable signal ENABLE 69 to the MUX 66 to control which of the control units 17 is given access to the processor elements 62 at a given time. In operation, the MUX controller 68 activates an enable signal ENABLE 69 to the MUX 66 , which relates to a special control unit 17 , and a start signal GO 72 to the special control unit 17 . The special, selected control unit 17 in turn generates operands and a processor start signal to begin a processing operation, which are ultimately passed on to the stack 51 . The control unit 17 accesses the stack 51 and the specific, desired processing element 52 via a suitable connection 74 , the MUX 66 and the connection 76 . The control unit 17 causes the working processing element 52 to recover data from an input buffer 77 (usually a FIFO buffer) and the result (s) are stored in an output buffer 82 (usually a FIFO buffer). The control unit 17 can initiate any number of operations via one or more of the processing elements 52 . If it was the control unit 17's turn, it activates a done signal DONE 84 to the MUX controller 68 . The MUX controller 68 then activates a further start signal GO 72 to a further control unit 17 , while the latter supplies an enable signal ENABLE 69 , which corresponds to the next control unit 17 .

A problem with the previous design is the large number of gate levels required to implement the MUX 66 . Another problem is that the MUX 66 increases the time necessary for signals that are to be communicated from the control unit 17 to the processing elements 52 . The gate delay alone is part of this increase. Charging also adds to the time delay even when a tri-state MUX 66 is used to replace the multilayer gate arrangement. In addition, the aforementioned problems are increased as the number of control units 17 and the number of processing elements 52 is increased.

The object of the present invention is to provide a system and a method for better interface-connecting control units 17 with processing elements 52 in order to optimize the performance of a geo-transmission accelerator in a computer graphics system.

This task is accomplished through a system and a method for Minimize space requirements and increase ge speed in a geometry accelerator for a Com Computer graphics system according to claim 1, claim 9 and claim 10 solved.

The present invention provides a centralized branch intelligence system and a method of enabling one efficient multipath logic branching in ROM-based control units of a high-performance geometry accelerator a computer graphics system. Generally minimize that  centralized branch intelligence system and the process the Space requirements and increase the speed in the Geometry accelerator.

The system is implemented architecturally as follows. Of the Geometry accelerators include a plurality of processes tion elements (e.g. an arithmetic logic unit, a Multiplier, a divider, a comparison device, a clamping device etc.) and a plurality of control units (e.g. a transformer, a Cutting device, a cutting device, a Bo gene band device, a light device, a classification approximation device, a plane equation device, a Veil device etc.), which the processing elements for Perform data manipulation on image data. According to the invention, the control units are in one Read-only memory (ROM) implemented via microcode instructions.

A branch logic is the ROM to support control assigned to units in multi-path branching. The branch logic is organized in a simple hierarchy in order to rationalize and optimize the logic. Diesel be has two levels of logic: (1) distributed tax unit logic with a plurality of control units safety logic elements, each of each control unit correspond with each element for tracking states the respective control unit, and (2) a branch central intelligence device for tracking High level system states that the conditioning and light modes, the primitive type, etc., but not be so are restricted. It essentially controls the former logic level the command branching within each corresponding one Control unit and the latter logic level controls that Branching under the different control units, d. H. it controls branching from a controller unity to another.

A next address field is each of the microcode instructions in FIG  assigned to the ROM and defines a position in the ROM of a next command to be executed. Each the control unit logic elements is configured to one Next address field for a currently executing command, the corresponding ROM-based control unit is assigned based on state data from the Stack, the corresponding ROM-based control unit and the branch central intelligence device is received, evaluate and define. In particular, every night is The address field is only partially in the ROM from the beginning defined on, and the controller logic elements define the next address field in dynamically the ROM during operation by setting one or multiple bits (preferably LSBs) that correspond to the next address field assigned.

The invention can also be conceived in such a way that the same a method of minimizing space requirements and to increase the speed in a geo gearbox accelerator for a computer graphics system by providing a centralized intelligence. In this together The procedure can be summarized as follows : Implement a variety of controls units in a read-only memory (ROM) via microcode, Im implement a stack of a plurality of processing elements, executing the microcode with the processing elements to modify image data after execution any microcode instruction, allow branching to one of the possible microcode positions based on one next address assigned to each microcode command, Track the operation of the control units with one Branch Central Intelligence Device, Implement One A plurality of branch logic devices, each of the control units, and with each branch logic direction, defining the next address for appropriate Instructions based on state data from the batch that Branch central intelligence device and a corresponding ROM-based control unit can be received.  

The invention has numerous advantages, one of which is few are presented as mere examples below.

An advantage of the invention is that it is egg a geometry accelerator with a higher speed and leads to higher performance.

Another advantage of the invention is that the same a conditional two-way to eight-way branching inside half of the control units of the geometry accelerator possible, whereby a required multiplexing and a Control logic is eliminated.

Another advantage of the invention is that the same reduces the space needed to implement the control tion units of a geometry accelerator required is.

Another advantage of the invention is that the same a communication of very broad command words, 211 bits in the preferred embodiment allows from a control unit to a processing element communicated within a geometry accelerator should be.

Another advantage of the invention is that the same thousands of control unit states using supported the same data path.

Preferred embodiments of the present invention are appended below with reference to the Drawings explained in more detail. Show it:

Fig. 1 is an electronic block diagram showing a computer with a graphics system;

Fig. 2 is an electronic block diagram showing the graphics system of Fig. 1;

Fig. 3 is an electronic block diagram showing a known embodiment of the geometry accelerator of Fig. 2;

Figure 4 is an electronic block diagram showing a geometry accelerator of the invention with control units implemented in read only memory (ROM) and branch logic configured to support instruction branching within the ROM ;

. Fig. 5 is an electronic block diagram, the logic a specifi c hierarchical logic implementation of the branch of Figure 4 with a branch central intelligence shows devices according to the present invention;

Fig. 6 is a schematic diagram showing an example of implementation of fields within a microcode instruction arranged within the ROM of Fig. 4;

Fig. 7 is a state diagram showing an implementation example of the branch central intelligence device of Fig. 5;

Fig. 8 is a flowchart showing an implementation example of each control unit within the ROM of Figs. 4 and 5; and

9 is a schematic diagram showing a simplified implementation example of a possible microcode which is within the ROM of Fig. 4 and 5 can be classified Fig..

Referring generally to FIG. 4, the present invention provides an implementation of control units 17 ei nes geometry accelerator (Fig. 2) of a computer graphics system 16 (Fig. 1, 2) within a read-only memory (ROM) is 100. The implementation of the control units 17 within the ROM 100 interfaces the control units 17 better with the processing elements 52 , minimizes the space requirements and increases the overall speed of the geometry accelerator 23 . The implementation also enables multipath logic branching, which further improves performance. In other words, several decisions can be made at the same time and in parallel.

Referring to Fig. 4, the geometry accelerator 23 of the invention in its architecture includes a number of special control units 17 for processing the image data, which include, but is not limited to, a transformer TRANS 24 for performing transformations on the vertex data, such as B. a scaling or moving a vertex in space, a decomposition device DECOMP 25 for decomposing primitives, such as. B. converting a trapezoid into a triangle, a clipping device CLIP 26 for cutting off pieces from objects that extend over a boundary, a bow band device BOW-TIE 27 for processing a bow band configuration to determine the intersection of the same, and to break the primitive into triangles, a light device LIGHT 28 for shading and enhancing the image data by simulating one or more lighting conditions, a classifying device CLASS 29 for classifying a primitive as facing forward or as facing back for special effects, a plane equation device PLANE 32 for defining primitives using mathematical floating point equations and a fog device FOG 39 for essentially imposing a background color on an object in an image in order to improve the distance perspective.

In particular, geometry accelerator 23 further includes branch logic 102 configured to, when appropriate, manipulate a next address within a command that is currently being executed by ROM 100 such that the current command eventually closes one of up to eight possible command positions (only four in the preferred embodiment) may branch a stack 51 of processing elements 52 , as described above, configured to execute commands from the ROM 100 , an input buffer 77 that configures to receive data from CPU 12 ( FIG. 1) and an output buffer 82 configured to provide output data to raster device 31 ( FIG. 2). Branch logic 102 is configured to receive an address NEXT_ADDR 104 from ROM 100 as well as state data 106 from ROM 100 , stack 51 , CPU 12 ( FIG. 1), and / or elsewhere. The state data may include many types of information regarding the state of the accelerator 23 , for example, but not limited to, information related to whether or not a control unit 17 has stopped operating, information related to the type of the primitive or the Polygons relate, information related to whether the primitive includes light parameters or not, edit mode information, light mode information, etc. Based on state data 106 , branch logic 102 is configured to determine whether the next address NEXT_ADDR 104 that corresponds to the current one Command is assigned, should be modified or left unchanged, and, if it is to be modified, how the next address NEXT_ADDR should be changed.

As shown in FIG. 4, branch logic 102 is . configured to receive the next address NEXT_ADDR or a portion thereof from the ROM 100 and is configured to output a new next address NEXT_ADDR (modified or unmodified) 108 to the ROM 100 . The command currently executing in ROM 100 includes the next address NEXT_ADDR 104 in a corresponding next address field NEXT_ADDR (see, e.g., Fig. 6). The next address NEXT-ADDR 108 will tell the ROM 100 where to move for the next command after the current command has been completed.

An example of the logic functionality that can be used within branch logic 102 is as follows. It is believed that primitive data is sent through the TRANS 24 transform device, and that the state data 106 from the TRANS 24 transform control unit in the ROM 100 indicate that the primitive is off the screen. It is further assumed that the current command has a next address NEXT_ADDR 104 that points to the clipping control unit CLIP 26 . In this case, branch logic 102 can be configured to change the next address NEXT_ADDR 104 such that the next address NEXT_ADDR 108 points to the beginning of the transformation control unit TRANS 24 to wait for the next primitive to be processed.

As another example, consider a scenario in which the lighting is turned off and shows the address of the current command to the lighting device LIGHT 28 . In this case, the branch logic 102 can change the next address such that the current command points to another control unit 17 , for example the plane equation device PLANE 32 .

An example of a possible specific implementation of the geometry accelerator 23 is shown in FIG. 5. Under Be zugnahme to FIG. 5, the specific implementation includes a branch logic 102 with a hierarchical arrangement of a logic functionality. In particular, branch logic 102 includes a branch central intelligence device 112 configured to perform logic decisions at a high level and distributed control unit logic 114 having a plurality of individual control unit logic elements SE-LOGIC-ELEMENT 115 , each corresponding to each control unit 17 . Each control unit logic element 115 is configured to make logic decisions at a lower level, to support each respective control unit 17 , to achieve conditional branching, and to control indirect addressing.

In the preferred configuration for this specific implementation of FIG. 5, the ROM 100 includes the plurality of control units 17 in the form of generally separate software modules; however, nested coding implementations are possible. The module's code is executed individually, and each drives a special processing element 52 with instructions 76 (211 bits in the preferred embodiment).

Each microcode command residing in ROM 100 has at least the fields set forth in FIG. 6. Referring to Fig. 6, each instruction comprises a branch field BRANCH FIELD 121, a next address field NEXT_ADDR 104, a Nächster- vertex field NEXT VERTEX 122, a next light field NEXT LIGHT 123, an initializing field (flag) INIT ( FLAG) 124 , a data path control (command) field DATA PATH CONTROL (INSTRUCTION) 125 , a condition code field CONDITION CODE 126 and an operational control unit identification (ID) field OPERATIONAL CONTROL UNIT IDENTIFICATION (ID) 127 . These fields are described below.

The branch field BRANCH FIELD 121 contains help information relating to the number of possible branch positions. Since branching to one of four possible command positions can occur in the preferred embodiment, the branch field BRANCH FIELD 121 comprises two bits, a bit 2-WAY_4-WAY 128 and a bit COND_NONCOND 129 . The former indicates whether the branch is either two-way or four-way, and the other defines whether the instruction is conditionally CONDITIONAL or unconditionally UNCONDITIONAL. "Unconditional" means that indirect branching will not occur after the current instruction is executed, and accordingly the next address will not be modified by controller logic 114 . "Conditional" means that indirect branching will occur after the current instruction is executed, and therefore one or two bits of the next address NEXT_ADDR will be replaced by control unit logic 114 . One bit is replaced in two-way branching (2-WAY) and two bits are replaced in four-way branching (4-WAY).

The next address field NEXT_ADDR 104 identifies the address corresponding to the next command to be executed in the ROM 100 , which may be in one of a plurality of positions (command slots) according to the invention. Each of the control unit logic elements 115 ( FIG. 5) is configured to evaluate and define a next address field NEXT_ADDR 104 for a currently executing command, which is assigned to a corresponding ROM-based control unit 17 . Each NEXT_ADDR 104 next address field is only partially defined in the ROM 100 from the start, and the controller logic elements 115 fully define the NEXT_ADDR next address field dynamically during operation by setting one or more bits (in the preferred one) Embodiment 2 LSBs (LSB = Least Significant Bit = least significant bit), which are assigned to the next address field NEXT_ADDR 104 .

The next vertex field NEXT VERTEX 122 (preferably 1 bit) notifies the outer vertex / light counter 139 ( Fig. 5) when the vertex count of the same is to be incremented for the primitive concerned.

The next light field NEXT LIGHT 123 (preferably 1 bit) notifies the outer vertex / light counter 139 if the light count for the affected primitive is to be incremented.

The initialization field INIT 124 identifies whether the registers 61 and / or the RAM working memory 62 should be initialized (deleted or preset) or not. Initialization typically occurs when the transform control unit TRANSFORM 24 receives a new primitive.

The data path control field DATA PATH CONTROL 125 is essentially the command to be executed by the processing element 52 . The data path control field DATA PATH CONTROL 125 can perform at least the following functions: defining the position of one (of) operands in the registers 61 and / or the RAM 62 ; Defining an operation (s) to be performed on an operand; Notifying output buffer 82 if it is to load data from processing element 52 ; Identify a position (s) at which an execution result (s) is to be stored in the register 61 , the RAM 62 and / or the output buffer 82 .

The condition code field CONDITION CODE 126 identifies a condition code which is essentially state data identifying the current state of the control unit 17 which is currently in operation within the ROM 100 . The condition codes are specific for each control unit 17 in that specific condition code values can have different meanings in different control units 17 . The condition codes CONDITION CODES 126 can be used in an infinite number of ways to influence logic decisions in the control unit logic elements 115 as well as in the branch central intelligence device 112 . For purposes of illustration, some specific examples of condition codes, their meaning, and their interpretation are described in further detail below during the logic discussion for control unit logic elements 115 and branch central intelligence device 112 .

The operational control unit identification field OPERATION CONTROL UNIT ID 127 identifies the special control unit 17 that is currently being operated in the ROM 100 .

Referring to FIG. 5, as previously mentioned, stack 51 includes a plurality of processing elements 52 identified by reference numerals 54-58 and register and RAM memories 61 , 62 . At any time, one of the processing elements 52 executes an INSTR 76 command from one of the control units 17 in the ROM 100 . During execution, each processing element 52 may receive data from input buffer 77 , and during or after execution, each processing element 52 may output (s) in output buffer 82 under the command of a control unit 17 via a load signal LOAD 143 , preferably ( 1 bit) for communication to the Rastervor direction 31 ( Fig. 2) place. Input buffer 77 may provide vertex information to stack 51 . Processing elements 52 are configured to provide flags 131 (10 bits), if appropriate, to branch logic 102 depending on the particular processing element 52 . For example, the comparison processing element COMPARE 57 can provide a flag (s) 131 which indicates that two operands are the same, two operands are not the same, one operand is larger than another, and one operand is smaller than someone else, etc.

A state management address decoder 132 is provided to receive global state data (54 bits, 32 bits of which are data, 21 bits of address and 1 bit indicating whether the input buffer has valid / invalid data), including mode information, from the CPU 12 ( Fig . 1) to receive, via the input buffer 77, as shown by reference arrow 133rd A UNLOAD 135 (1 bit) discharge signal from the state management address decoding device 132 initiates the previous transmission of the state data. The mode information controls some behavioral aspects of the geometry accelerator 23 . In the preferred embodiment, there are three 32-bit registers that control the respective operating modes: a conditioning mode, a first light mode and a second light mode. In general, the edit mode register defines global information relating to the types of graphic effects or features that are contained in the image data by suitable processing, e.g. B., but not limited to, can be achieved by lighting, a veil, a texture map, etc. In addition, the first and second light mode registers define specific information about how the graphic effects are to be applied to the image data, for example, but not limited to, the number and type of lights to be turned on, the type of texture mapping, etc. .

The branch central intelligence device 112 of the branch logic 102 receives the mode information MODE_INFO 134 (200 bits in the preferred embodiment) from the state management address decoding device 132 . The Zweigzen tralintelligenzvorrichtung 112 further receives the flags 131 of the stack 51, the condition codes CONDITION CODES 126 from the ROM 100 and an operation control unit signal 136 a (in this example, 3 bits) of the ROM 100, indicating which control unit 17 currently within the ROM 100 is operated. Based on the status data, ie the mode information MODE_INFO 134 , the flags 131 , the condition codes CONDITION CODES 126 and the operational control unit signal OPERATIONAL CONTROL UNIT 136 a, the branch central intelligence device 112 generates and outputs a suitable signal next control unit 138 to a single control unit logic element SE-LOGIK -ELEMENT 115 , which corresponds to the operational control unit 17 . The next control unit 138 signal defines which control unit 17 is to branch next according to the logic within the branch central intelligence device 112 .

Each of the individual control unit logic elements 115 , which are located within the control unit logic 114 , supports a corresponding control unit 17 in reaching the branching and the indirect addressing. Each of the individual control unit logic elements 115 is configured to make logical decisions for the respective control unit 17 thereof based on and as a function of the status data which, in the preferred embodiment, has two least significant bits (= Least Significant Bits = LSBs) 104 'of the next address NEXT_ADDR 104 from the current command of ROM 100 , the branch field BRANCH FIELD 121 from the current command of ROM 100 , the condition code CONDITION CODE 126 from the current command of ROM 100 , last-peak and last-light signals LAST 137 from one Vertex / light counters 139 , which indicate whether the current command concerns the last vertex and the last light to be processed in a grouping of vertices / lights associated with a code subroutine, and flags 131 thereof Include stack 51 .

The functionality of each controller logic element 115 may be implemented in cell logic, a lookup table, or any other suitable logic device. As examples of the logic within each control unit logic element 115 , consider the following. These examples should not be taken as limiting, since there are an infinite number of possible logic configurations.

As a first example, assume that a special control unit 17 is operating in the ROM 100 . In this example, the condition code may be correlated with the logic in the ent speaking control unit logic element 115, such that when the corresponding control unit logic element 115 a condition code CONDITION CODE with a value of i (where i is an arbitrary number) of the special control unit is passed 17, the control unit logic element 115, the last vertex bit LAST vERTEX 137 evaluates, and when the bit LAST vERTEX is activated 137, then provides the Steuerungsein integrated logic element 115, the next address NEXT_ADDR 104 such a that the current command to the lighting control LIGHT 28 branches.

As another example, it is assumed that the plane equation device PLANE 32 operates such that math operations are performed on a plane equation vector, that the plane equation parameters dx and dy have already been calculated together with the vector, and that a comparison operation is currently being performed by the comparison processing element COMPARE 57 is performed in the stack 51 . In this example, a condition code of value i (any number) from the plane equation device PLANE 32 may require that the respective control unit logic element 115 examine a flag 131 from the stack 51 relating to the result of the comparison operation and the next address NEXT_ADDR 104 defined accordingly. Furthermore, if dx is greater than dy based on flag 131 (ie, the code is currently working on a major vector x), then controller logic element 115 will force the current instruction to branch to a first position in the code. On the other hand, if dy is greater than dx based on flag 131 (ie, the code is currently operating on a major vector y), then controller logic element 115 will force the current instruction to branch to a second position in the code that is different from the first position.

As yet another example, assume that a special control unit 17 is operating and that a condition code CONDITION CODE with a value of i (any number) indicates the corresponding control unit logic element 115 thereof, the signal next control unit 138 from the branch central intelligence device 112 to investigate. In this case, when the control unit logic element 115 supply code the appropriate Bedin CONDITION CODE detected i with value 104 is the same, the next address NEXT_ADDR such a that a branch to another control unit 17 based on the signal Next control unit 138 of the branch central intelligence device 112 occurs.

The implementation of a plurality of individual control unit logic elements 115 reduces the size of the required microcode instructions INSTR 76 that must be stored in the ROM 100 and further reduces the amount of signaling logic that is necessary to implement the branching functionality. In other words, the logic of the plurality of individual control unit logic elements 115 could be implemented with a single logic element; however, the single element logic would be significantly larger in size and logic complexity, which is therefore undesirable particularly for implementation in an integrated circuit.

A vertex and light counter (vertex / light counter) 139 is implemented using appropriate logic. The vertex / light counter 139 is designed to count and track vertices as well as lights for a primitive. It generates a last vertex signal LAST 137 and a last light signal LAST 137 for the individual control unit logic elements 115 to indicate that the last vertex or light of the primitive is processing based on and as a function of the following signals a flag initialization bit FLAG_INIT 141 from the ROM 100 , next next vertex / next light signals NEXT_VERTEX / LIGHT 142 from the ROM 100 and primitive information PRIMITIVE_INFO 144 (12 bits, 4 bits of which the type of the primitive and 8 bits display the number of lights that are turned on) from the state management address decoder 132 , which is the primitive type (e.g., dot, vector, triangle, trapezoid, etc.) and the number of lights that are on if any lights are present include.

A MUX 146 receives LSBs 148 (2 bits in the preferred embodiment) of the next address NEXT_ADDR 104 from the individual controller logic elements 115 . The operational control unit signal OPERATIONAL CONTROL UNIT 136 b (3 bits in this example) from the ROM 100 forces the MUX 146 to select the appropriate connection 148 that is associated with the appropriate control unit logic element 115 that corresponds to the operational control unit 17 .

A latch 149 , which is preferably a conventional data (D -) type flip-flop memory latch, is configured to receive the LSBs 151 from the MUX 146 . The latch 149 is clocked by a system clock signal CK 152 .

A latch 155 , which is preferably a D-type flip-flop memory latch, receives the upper 9 bits 104 ″ of the next address NEXT_ADDR 104 from the ROM 100 . The latch 155 is clocked by the clock signal CK 152 . Latch 155 outputs 9 bits 156 , which are combined with 2 bits 154 from latch 149 to generate the next address NEXT_ADDR 108 (11 bits) for ROM 100 .

As an example, FIG. 7 illustrates a state diagram for a possible implementation of the branch central intelligence device 112 ( FIG. 5). In FIG. 7, the diamond-shaped blocks represent logical decisions made by the branch central intelligence device 112 and the rectangular blocks represent the logic functionality performed by the control units 17 within the ROM 100 . Therefore, FIG. 7 illustrates how the branch central intelligence device 112 decides which controller 17 is selected and used for the next primitive.

Initially, a DISPATCH 24 'dispatcher, which is essentially a header in the TRANSFORM 24 transformer, awaits the arrival of a primitive. As soon as a primitive arrives, the DISPATCH 24 'dispatcher notifies the branch central intelligence device 112 of this fact.

The branch central intelligence device 112 continues to monitor the mode information MODE_INFO 134 until a primitive arrives. This functionality is shown at block 71 . After a primitive arrives, the branch central intelligence device 112 generates a signal next control unit 138 that corresponds to the TRANSFORM 24 transformation device.

After the transforming device transforms the primitive, a determination is then made as to whether the primitive should be trivially rejected, as shown at block 72 . A primitive is trivially rejected if the entire primitive lies outside the screen, in which case the process will return to the DISPATCH 24 'processing device. If the primitive should not be trivially rejected, then the branch central intelligence device 112 makes a determination as to whether the primitive needs to be classified, as indicated at block 73 .

In the preferred embodiment, the primitives can be classified as facing forward or backward. Generally, the lighting is set based on these parameters. If the primitive is of a type that needs to be classified, then the branch central intelligence device 112 generates a next control signal 138 that corresponds to the CLASSIFY 29 classification device. Further, after the CLASSIFY 29 classifies the primitive, the branch intelligence device 112 determines whether the primitive is read.

In the preferred embodiment, the readout is a feature that has been added to optimize the processing speed. In essence, the user can specify whether the primitives directed forward or backward should be discarded. If the current primitive is a primitive to be discarded, the process will return to dispatcher DISPATCH 24 '. Otherwise, the branch central intelligence device 112 makes a determination as to whether the light device LIGHT 28 should be called in block 75 .

Next, if the branch central intelligence device 112 determines at block 73 that the primitive need not be classified, then the branch central intelligence device 112 makes a determination as to whether the primitive should be illuminated with the lighting device LIGHT 28 , as shown at block 75 .

If it is determined at block 75 that the primitive should be illuminated, then the branch central intelligence device 112 defines an appropriate signal next control unit 138 such that the light device LIGHT 28 is invoked. If a primitive does not have a constant color, then the same is illuminated.

After lighting, the branch central intelligence device 112 makes a determination of whether a veil should be attached to the primitive, as shown at block 76 . If this is the case, then the grinder FOG 39 is called.

After the veil is applied, or if it is determined at block 76 that no veil is being applied, then the branch central intelligence device 112 initializes to its register, as shown in block 77 . In this context, a variable "FIRST" is activated (set to "1") to indicate that this is the first primitive, a variable "QUAD_A" is activated to indicate that this is a trapezoid of type "a" ( ie is a convex tra pezoid) and a variable "BOW-TIE" (= arch band) is deactivated (set to "0") to indicate that this is not an arch band.

After setting the inner registers, the branch central intelligence device 112 determines at block 78 whether the primitive needs to be cut off. If this is the case, then the process flow proceeds through blocks 81 to 86. If not, then the process continues through blocks 91-95 .

In the event that the primitive is to be cut off, the branch central intelligence device 112 then determines whether the primitive is a trapezoid, as shown at block 81 . If this is the case, then the decomposer DECOMP 25 is called. Otherwise the decompression device DECOMP 25 is not called.

After trapezoidal analysis and disassembly, any specified clipping planes are processed in a serial manner if necessary. Each specified clipping plane is looped as shown in blocks 83-85 in FIG. 7. Before entering the loop, inner registers are initialized. A variable "MODEL_CLIP_PASS" is initialized to zero in such a way that the first clipping level is considered and analyzed. With each pass through the loop, a determination is made as to whether there is a bow tape (BOW-TIE) as shown at block 83 , in which case the bow tape device BOW-TIE 27 is called to calculate the intersection. Furthermore, the clipper 26 and then the plane equation device PLANE 32 are used to further process the data as shown. In the loop, the logic at block 84 increments the MODEL_CLIP_PASS variable and the logic at block 85 causes the process flow to return to block 83 until all cut levels have been processed.

At block 86 , a determination is made whether this primitive is the first triangle of the trapezoid. If not, then the process flow returns to block 71 . If so, then at block 87 the branch central intelligence device 112 sets the inner registers to process the second triangle of the trapezoid. In this regard, the "MODEL_CLIP_PASS" variable is set to zero and the "FIRST" variable is set to zero.

If it is determined at block 78 that the primitive should not be cut off, the plane equation device PLANE 32 is invoked, and then the branch central intelligence device 112 verifies whether the primitive is a "a" (convex) type trapezoid, as shown in FIG a block 91 is shown. This is accomplished by observing the flags from the stack 51 and the condition codes CONDITION_CODES 126 . In particular, the branch central intelligence device 112 is supplied with a suitable condition code CONDI TION_CODE 126 in order to analyze the flags 131 from the stack 51 . The flags 131 indicate the type of the trapezoid. If not, then the process will return to block 71 to wait for another primitive. Otherwise, in the case where the primitive is not a trapezoid of type "a" (convex), the primitive is dismantled via the decompression device DECOMP 25 .

Next, the branch central intelligence device 112 makes a determination of whether the primitive is an arc band, as shown at block 93 . If this is not the case, then the plane equation device PLANE 32 is called. Otherwise, the Bogenbandvorrich device BOW-TIE 27 and then the plane equation device PLANE 32 is called. The logic of blocks 94 through 95 ensures that both triangles of the arc band are processed.

business

The operation of the geometry accelerator 23 with the control units 17 implemented in the ROM 100 will now be described with reference to FIGS. 8 and 9. FIG. 8 shows a flow diagram 161 that shows the operation of an example of a control unit 17 within the ROM 100 in connection with the branch logic 102 . In this example, a control unit 17 generally processes all vertices and all lights, if any, of a grouping of vertices and lights that correspond to a primitive in question. Reference is now made to both FIG. 5 and FIG. 8 in the following discussion.

First, primitive data and status data are supplied to the input buffer 77 by the CPU 12 ( Fig. 1). The status management address decoding 132 reads the status data 133 by activating a discharge signal UNLOAD 135 to the input buffer 77 . The state management address encoding 132 in turn decodes the state data and provides mode information MODE_INFO 134 to the branch intelligence device 112 . In addition, the branch central intelligence device 112 provides signals to the next control unit 138 to respective control unit logic elements SE-LOGIK-ELEMENT 115 .

A microcode command is read by the ROM 100 , and a microcoded control unit 17 therein is allowed to operate within the ROM 100 . The microcoded control unit 17 executes an initialization routine at the beginning of a clustering of highlights / lights, as shown in flowchart block 162 . Here the control unit 17 of the ROM 100 essentially initializes flags such as e.g. B. FLAG_INIT 141 , and the register and RAM memories 61 , 62 in the stack 51 .

Next, a vertex loop routine is started that processes data associated with a vertex of the primitive during each loop operation. As shown at block 163, the ge suitable control unit logic element 115 determines via the Letz ter-vertex bit LAST VERTEX 137, whether the peak point that was recently beitet bear in the past through the stack 51, is the last vertex of the primitive that is currently affected.

If so, then control unit 17 is forced to transfer control of stack 51 to another control unit 17 , as shown at block 164 , by control unit logic element 115 . In this case, control unit logic element 115 achieves this by modifying one or both LSBs 104 'of the next address NEXT_ADDR. The high level logic associated with branch central intelligence device 112 ultimately determines which control unit 17 will be used next. The control unit logic element 115 determines the appropriate branch position, that is, as the LSBs 104 'of the next address based on the signal NEXT_ADDR Next control unit 138 central intelligence device from the branch 112 to be modified.

If the previously processed vertex was not the last vertex, and consequently more vertexes are to be processed, then the microcode of the control unit 17 performs some or more operations on the present vertex using one or more of the processing elements 52 as shown in block 165 is shown. The corresponding control unit logic element 115 dictates the branching during these operations based on the branch field BRANCH-FIELD 121 , the condition codes CONDITION CODES 126 and the FLAGS 131 .

For each vertex, a light loop routine, if applicable, is started that processes data associated with a light (s) of the primitive during each loop operation. As shown at block 166 , the appropriate controller logic element 115 determines via the last light bit LAST LIGHT 137 whether the light previously processed by the stack 51 is the last vertex light that is currently affected.

If not, then the light operations are performed, as shown at block 167 . The corresponding control unit logic element 115 dictates the branching during these light operations based on the branch field BRANCH_FIELD 121 , the condition codes CONDITION CODES 126 and the flags 131 . After the light operations, a light counter is advanced as indicated at block 168 and the process flow returns to block 166 to identify another light if there are any lights left to be processed.

If there are no lights left to be processed at block 166 , then vertex counter 139 ( FIG. 5) is advanced via signal NEXT_VERTEX 142 , as shown at block 166 in FIG. 8, and becomes one another vertex for processing, if any vertices remain, recovered, as shown at block 163 in FIG. 8.

The aforementioned process continues cyclically until all vertices and lights, if any, have been processed in a group, in which case one or more other microcoded control units 17 are authorized to start operating until processing of the primitive is complete.

Microcode example

To further clarify the operation, a specific simplified example of the microcode in the ROM 100 will now be discussed with reference to FIG. 9. In this example, it is assumed that the ROM 100 contains at least eleven instructions with the contents set forth in FIG. 9.

The ROM 100 will start the instruction in slot 0 . At the beginning of the code relating to a control unit 17 , an initialization routine INITIALIZE is carried out. Since the initialization flag in the command is activated at this point regarding the start of a new control unit 17 , the ROM 100 would activate the FLAG_INTIALIZE 141 signal ( FIG. 5) to the vertex counter 139 ( FIG. 5), causing the Vertex point 139 initializes its vertex count. The vertex counter 139 is informed of the type of the primitive and the number of vertices by the state management address decoding 132 via a primitive information signal PRIMITIVE_INFO 144 . Furthermore, the unconditional flag NONCOND of this command is activated in the branch field BRANCH_FIELD 121 , and therefore the control unit logic elements 115 do not have to look at the flag TWO-WAY_FOUR-WAY and they do not have to modify the LSBs 104 'of the next address NEXT_ADDR. Because there is no indirect addressing, the controller logic elements 115 do not modify the next address field NEXT_ADDR 104 . Finally, the command evaluates the NEXT_ADDR field, which indicates that the next command to be executed is the same as that in command slot 1 . Accordingly, the next instruction that is executed is the same one that is in slot 1 .

The command located in slot 1 does not require initialization because the initialization flag INITIALIZE (FLAG) is deactivated. Therefore, the FLAG_INIT 141 signal to the vertex counter 139 is deactivated. The conditional flag COND of the branch field BRANCH_FIELD 121 is activated, and therefore the appropriate control unit logic element 115 interprets the two-way four-way flag TWO-WAY_FOUR-WAY, which is set to zero, which indicates that the branching is two-way. The next address field of the instruction may be defined by logic element 115 to branch the instruction into slot 2 or slot 3 , depending on the condition code CONDITION_CODE 126 and each flag 131 from stack 51 . If the last light or vertex was not processed in a grouping of vertices / lights based on the condition code CONDITION_CODE 126 , the flags 131 and the signal LAST 137 , then the controller logic element 115 can be configured to cause that the ROM 100 selects the command located in slot 2 . To do this, control unit logic element 115 defines the appropriate next address LSBs 148 . In this case, the control unit logic element 115 allows the LSB1 of the next address NEXT_ADDR 104 to be forwarded unchanged to the next address NEXT_ADDR 108 , and forces the LSB0 of the next address NEXT_ADDR 104 to be deactivated ("0").

The instruction in slot 2 does not require initialization, as shown by the deactivated initialization flag INITIA LIZE (FLAG). The vertex counter 139 ( FIG. 5) is not moved forward by a deactivated signal FLAG_INIT 141 . Furthermore, the data path control field DATA PATH CONTROL 125 causes the stack 51 to be forwarded by the ROM 100 on connection 76 , which the ALU 54 ( FIG. 5) executes by adding operands A and B. Operands A and B are retrieved from registers 61 and / or RAM 62 , the position of which is defined in the data path control field DATA PATH CONTROL 125 of the INSTR instruction. The result is stored in the register 61 , the RAM 62 and / or the output buffer 82 by the ALU 54 . The unconditional flag NONCOND is activated, and therefore the two-way, four-way flag TWO-WAY_FOUR-WAY need not be considered, and controller logic 115 need not modify the next-address LSBs NEXT_ADDR. Furthermore, the next address NEXT_ADDR is the same that is in slot 4 as prescribed by the command.

The command in slot 4 is started by ROM 100 after the command in slot 2 is completed . Initialization does not occur and the vertex counter 139 is not advanced. The command causes the ALU to add 54 operands C and D (ADD). The operands C and D are retrieved from the registers 61 and / or the RAM 62 based on the data path control DATA PATH CONTROL 125 . The result is stored in the register 61 , the RAM 62 and / or the output buffer 82 by the ALU 54 . Furthermore, the command is not conditional and goes directly to the command in slot 5 . Again, controller logic element 115 does not modify the LSBs of the next address NEXT_ADDR in this case.

The command in slot 5 does not initialize and does not move the vertex counter 139 forward. The same causes multiplier 55 ( Fig. 5) to multiply operands E and F (MPY). Operands E and F are retrieved from registers 61 and / or RAM 62 . The result is stored in the register 61 , the RAM 62 and / or the output buffer 82 by the multiplier 55 . The command is not conditional, and therefore the command can only branch to another command located in slot 6 according to the NEXT_ADDRESS field. Again, controller logic element 115 does not modify the next address LSBs in this case.

The command in slot 6 does not perform an initialization process according to the initialization flag INITIALIZE (FLAG). Its data path control field DATA PATH CONTROL causes comparator COMPARE 57 ( Fig. 5) to compare amounts (A + B), (C + D). The command is not conditional (NONCONDITIONAL). The same causes the ROM 100 to look at the instruction in slot 1 after it has incremented the vertex counter 139 according to the NEXT_VERTEX field.

For each primitive, the aforementioned operations will occur once for each vertex, ie, the ROM 100 will cycle through slots 1 , 2 , 4 , 5 and 6 . As a result, in the case of a triangle with three vertices, three cycles would occur through the aforementioned commands. After the last vertex / light, the branch central intelligence device 112 will recognize a condition code CONDITION_CODE, for example "7" as shown in FIG. 9, which indicates that the branch logic 115 for this control unit 17 should watch the LAST signal 137 , and should determine if it is the last vertex / light LAST VERTEX / LAST LIGHT. This is the case here. In this case, the branch central intelligence device 112 notifies an appropriate control unit logic element 115 of the next control unit 17 to be used. The NEXT_ADDR 104 next address field may be set by the appropriate controller logic element 115 to indicate that the ROM 100 should advance to slot 3 for the next command.

In slot 3 , the command is conditional (CONDITIONAL), as indicated by the activated condition flag COND_NONCOND. The 4-WAY flag is also enabled, indicating that the next command may be in one of four different positions in the ROM 100 . These positions are slots 8-11 . The control unit logic element 115 makes the decision by defining the next address LSBs based on and as a function of the next control unit 138 signal from the branch central intelligence device 112 , the condition code CONDITION CODE 126 from the ROM 100, and any flags 131 from the stack 51 by. In this example, slots 8-11 correspond to instructions that start clipping, shading, plane equation, and decomposition routines. As shown in Fig. 9, this command indicates a CONDITION_CODE condition code of "5". The condition code CONDITION_CODE "5" could indicate to the controller logic element 115 that it should examine the next controller 138 signal from the branch intelligence device 112 to jump to another controller 17 . The next control unit 17 could e.g. For example, the light device may be LIGHT when the branch central intelligence device 112 determines that shading should occur next, in which case the controller logic element 115 would define the LSBs of the next address such that the next address would be defined as slot 9 .

Claims (10)

1. A system for minimizing space requirements and increasing the speed in a geometry accelerator ( 23 ) for a computer graphics system ( 16 ) by providing a centralized branching intelligence ( 112 ), having the following features:
a stack of a plurality of processing elements ( 52 );
a plurality of control units ( 17 ) implemented in a read only memory (ROM) ( 100 ) via microcode instructions ( 117 ), each of the control units ( 17 ) configured to process a processing element ( 52 ) use to modify image data;
a next address field (104) (117) is associated with each of the microcode instructions and a position in the ROM (100) defining a next instruction (117) to be executed; and
a central branch intelligence device ( 112 ) configured to control the branching between the control units ( 17 ) by defining the next address field ( 104 ) while executing instructions. 2. The system of claim 1, wherein the control units ( 17 ) are selected from a group consisting of a transforming device ( 24 ), a disassembling device ( 25 ), a cutting device ( 26 ), an arc band device ( 27 ), a light device ( 28 ), a classification device ( 29 ), a plane equation device ( 32 ) and a Schleiervor direction ( 39 ). 3. System according to claim 1 or 2, wherein the processing elements ( 52 ) are selected from a group consisting of an arithmetic logic unit ( 54 ), a multiplier ( 55 ), a divider ( 56 ), a comparison device ( 57 ) and a clamping device ( 58 ). 4. The system of any one of claims 1 to 3, further comprising a plurality of control unit logic elements ( 115 ) each corresponding to the control units ( 17 ), each of the control unit logic elements ( 115 ) configured to the next address Field ( 104 ) for a currently executing command ( 117 ) which is assigned to a corresponding control unit ( 17 ), based on status data ( 106 ) from the stack, the corresponding control unit ( 17 ) and the central branch intelligence device ( 112 ) are received, evaluated and defined. The system of one of claims 1 to 3, further comprising a plurality of control unit logic elements ( 115 ), each corresponding to the control units ( 17 ), each of the control unit logic elements ( 115 ) configured to branch the internal command within to control each of the control units ( 17 ). The system of one of claims 1 to 5, wherein a condition code field ( 126 ) is associated with each of the commands, the condition code field ( 126 ) defining a state of the corresponding control unit ( 17 ), the central branch intelligence device ( 112 ) being configured, to receive the condition code field (126), and to the next address field (104) to define, based on the condition code field (126). 7. System according to one of claims 1 to 6, wherein the central branch intelligence device is configured (112) to receive light parameter (134), and to the next address field (104) parameters based on the light (134) to define. The system of one of claims 1 to 7, wherein the central branch intelligence device ( 112 ) is configured to receive rendering parameters ( 134 ) and to define the next address field ( 104 ) based on the rendering parameters ( 134 ) . 9. A method of minimizing space requirements and increasing the speed in a Geometriebeschleu niger (23) for a computer graphics system (16) by providing a centralized branch intelligence (112), wherein the geometry accelerator (23) a plurality of processing elements (52) and a Has a plurality of control units ( 17 ), with the following steps:
Implementing the plurality of control units ( 17 ) in a read only memory (ROM) ( 100 ) via microcode instructions ( 117 ), each of the control units ( 17 ) being configured to use a processing element ( 52 ) to obtain image data modify;
A next address field (104) in each of the microcode instructions (117) of a next instruction (117) defines a location in the ROM (100) to be executed provision; and
Controlling the branching between the control units ( 17 ) by defining the next address field ( 104 ) while executing the commands ( 117 ). 10. A method for minimizing space requirements and increasing speed in a geometry accelerator ( 23 ) for a computer graphics system ( 16 ) by providing a centralized branching intelligence ( 112 ), comprising the following steps:
Implementing a plurality of control units ( 17 ) in a read only memory (ROM) ( 100 ) via micro code instructions ( 117 );
Implementing a stack of a plurality of processing elements ( 52 );
Executing the microcode instructions ( 117 ) with the processing elements ( 52 ) to modify image data;
after executing each microcode command, enabling branching to one of the plurality of possible microcode positions based on a next address ( 104 ) associated with each of the microcode commands;
Tracking the operation of the control units ( 17 ) with a central two-intelligence device ( 112 );
Implementing a plurality of branch logic devices ( 115 ), each corresponding to the control units ( 17 ); and
with each of the branch logic devices ( 115 ), defining the next address ( 104 ) for corresponding instructions ( 117 ) based on status data ( 106 ) obtained from the stack, the central branch intelligence device ( 112 ) and a corresponding ROM-based control unit ( 17 ) be received.