US20070273700A1 - Method, system and computer program product for efficiently utilizing limited resources in a graphics device - Google Patents
Method, system and computer program product for efficiently utilizing limited resources in a graphics device Download PDFInfo
- Publication number
- US20070273700A1 US20070273700A1 US11/512,055 US51205506A US2007273700A1 US 20070273700 A1 US20070273700 A1 US 20070273700A1 US 51205506 A US51205506 A US 51205506A US 2007273700 A1 US2007273700 A1 US 2007273700A1
- Authority
- US
- United States
- Prior art keywords
- microcode
- phase
- processor
- memory
- sequence
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/38—Concurrent instruction execution, e.g. pipeline, look ahead
- G06F9/3877—Concurrent instruction execution, e.g. pipeline, look ahead using a slave processor, e.g. coprocessor
- G06F9/3879—Concurrent instruction execution, e.g. pipeline, look ahead using a slave processor, e.g. coprocessor for non-native instruction execution, e.g. executing a command; for Java instruction set
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/22—Microcontrol or microprogram arrangements
- G06F9/223—Execution means for microinstructions irrespective of the microinstruction function, e.g. decoding of microinstructions and nanoinstructions; timing of microinstructions; programmable logic arrays; delays and fan-out problems
Definitions
- the present invention relates generally to memory management, and more particularly to improving the performance of microcoded functionality.
- microcode instructions i.e., microinstructions
- the microcode instructions include loop routines that are used to execute the rendering instructions.
- the loop routines are unrolled to reschedule or tune the microinstructions.
- a direct correlation can be observed between the complexity of graphics programs and the number of required routines.
- graphics programs become more advanced and sophisticated, a substantial number of lines of microinstructions are needed to render various graphic modes.
- microcode engines tend to have limited random access memory (RAM) capacity. Once RAM is consumed, more processing time or a faster processor is required to support highly advanced graphics, including animation, gaming and other simulations.
- RAM random access memory
- Tuning techniques are often used to improve performance and expand the capabilities of microcode engines. This improves the performance of microcoded transformations, lighting, and other graphics effects.
- most graphics applications have the ability to use several modes to render display frames. Each mode has the potential to contain various combinations of graphics effects, and each mode would require specifically tuned microinstructions to draw the effects.
- microcode branch instructions can be used to allow a single monolithic rendering code to work in several modes, but at the expense of extreme complexity in applying tuning techniques to maintain reasonable processing requirements for real time environments.
- Microinstructions are also dependent upon the platform being used to run the graphics program.
- the microcode capabilities of each graphics system including its system and language related run-time libraries, vary and effect the efficiency and performance of the applications loaded onto the graphics system.
- Software developers for new graphics applications must consider the version, performance, and capabilities of these platforms when they build their applications. Otherwise, new video games, for example, either would not be able to use the microcode developed for the existing platform, or would not take full advantage of the microcode capabilities.
- a microcode management system improves the performance and expands the capabilities of graphics software to use more tuning techniques and conserve limited memory on any type of computer platform.
- Rendering code for a microcode processor is assembled in one or more phases. Well-tuned versions of each phase are stored as distinct modules into a phase code depository for quick and easy access.
- a microcode manager contains various components designed to select a correct sequence of phases that are needed to implement a desired graphics mode.
- the components include a mode detector, sequence identifier, code loader, drawing data processor, and phase executor.
- the mode detector evaluates a user request for the desired graphics mode.
- the sequence identifier selects the correct phase sequence.
- the code loader transfers the phase sequence from the phase code depository to a microcode processor where it is temporarily stored in a microcode instruction memory.
- the memory address for each module within the phase sequence is written to a microcode data memory.
- the drawing data processor supplies vertices and vertex data to the microcode processor, and the phase executor instructs the microcode processor to execute the phase sequence to process the vertices and vertex data to render the desired graphics mode.
- the resulting data is forwarded to another processor for additional microcode processing, vector processing, rasterization, or the like.
- FIG. 1 illustrates a block diagram of a microcode management system according to an embodiment of the present invention.
- FIG. 2 illustrates a block diagram of a microcode manager according to an embodiment of the present invention.
- FIG. 3 shows exemplary phase modules according to an embodiment of the present invention.
- FIG. 4 a shows an exemplary phase module sequence according to an embodiment of the present invention.
- FIG. 4 b shows an exemplary phase module sequence according to a second embodiment of the present invention.
- FIG. 5 a shows exemplary phase modules according to a third embodiment of the present invention.
- FIG. 5 b shows exemplary phase modules according to a fourth embodiment of the present invention.
- FIG. 6 shows exemplary generic groups and merger groups according to an embodiment of the present invention
- FIG. 7 illustrates an operational flow diagram for the steps involved in managing the utilization of microcode according to an embodiment of the present invention.
- FIG. 8 illustrates a block diagram of an example computer system useful for implementing the present invention.
- central processor 110 is the Emotion engine, available from Sony Computer Entertainment America Inc., that provides motion simulation capability for animation or gaming applications, including the Playstation® 2 entertainment system available from Sony Computer Entertainment America Inc.
- microcode processor 130 is a vector processor capable of handling over eight floating-point operations at a given time.
- Application software 112 can be any currently available or future developed application, including, but not limited to, a game, word processing, presentation, spreadsheet, graphics, or the like.
- the formats supported by the application software 112 includes, but are not limited to, Virtual Reality Modeling Language (VRML) for three dimensional graphics, GIF for graphics, JPEG for photographs, the QuickTime® software available from Apple Computer, Inc. for dynamic media (i.e., audio and video), the Macromedia® FlashTM software available from Macromedia, Inc. for simple animation, the Macromedia® Shockwave® software available from Macromedia, Inc. for more advanced animation, the Adobe® Acrobat® software available from Adobe Systems Incorporated for documents, the Intrinsic AlchemyTM software available from Intrinsic Graphics, Inc. for gaming, or the like.
- VRML Virtual Reality Modeling Language
- GIF for graphics
- JPEG for photographs
- the QuickTime® software available from Apple Computer, Inc. for dynamic media (i.e., audio and video)
- system software 114 is the Intrinsic AlchemyTM software available from Intrinsic Graphics, Inc., which can be used to develop video games for personal computers, consoles, television set-top boxes, the Internet, wireless handheld devices, or real-time three dimensional graphic applications, such as a flight simulator for pilot training.
- system software 114 is the OpenGL® application program interface, available from Silicon Graphics, Inc.
- system software 114 is the DirectX® suite of multimedia application program interfaces available from Microsoft Corporation.
- Microcode manager 116 serves as an interface between microcode processor 130 and various components within central processor 110 .
- microcode manager 116 is a software application loaded or operating as a separate module in central processor 110 .
- microcode manager 116 is loaded into or operating as a part of system software 114 .
- Microcode manager 116 primarily receives signals from system software 114 and interacts with microcode processor 130 .
- Microcode processor 130 executes commands from microcode manager 116 as a sequence of microcode instructions (i.e., microinstructions).
- the microinstructions are written specifically for the Vector Unit (VU0 or VU1) in a Playstation® 2 system.
- Central processor 110 (including its components application software 112 , system software 114 , and microcode manager 116 ) has access to primary memory 120 .
- Primary memory 120 contains data, instructions, state variables or the like that are required by central processor 110 or its components to carry out various functions.
- primary memory 120 includes a phase code depository 122 that stores microinstructions that are delivered to microcode processor 130 for execution.
- microcode processor 130 has access to microcode instruction memory 132 and microcode data memory 134 which store data, instructions, state variables, or the like that are necessary for microcode processor 130 to function as designed.
- Microcode instruction memory 132 stores a sequence of microinstructions.
- Microcode data memory 134 stores a sequence list which is a compilation of addresses to the sequences listed in microcode instruction memory 132 in addition to other information required by microcode processor 130 and/or the microinstructions. Thus, microcode data memory 134 is queried to ascertain the location of a specific group of microinstructions stored in microcode instruction memory 132 .
- Primary memory 120 , microcode instruction memory 132 , and microcode data memory 134 can be a component of a main memory, a secondary memory, or a memory cache.
- FIG. 1 shows microcode processor 130 interacting directly with microcode instruction memory 132 and microcode data memory 134
- central processor 110 interacts directly with microcode instruction memory 132 and/or microcode data memory 134 to supply information to microcode processor 130 , or for operations independent of microcode processor 130 .
- microcode data memory 134 and microcode instruction memory 132 are located externally to microcode processor 130 .
- microcode data memory 134 and microcode instruction memory 132 are internal components of microcode processor 130 .
- microcode processor 130 , microcode data memory 134 , and microcode instruction memory 132 are integrated into a single device.
- Auxiliary processor 140 provides additional microcode processing, pixel processing, rasterization, vector processing, or the like.
- Microcode processor 130 directly communicates with auxiliary processor 140 .
- such communications are filtered or controlled through central processor 110 .
- microcode instruction memory 132 and/or microcode data memory 134 interacts directly with auxiliary processor 140 .
- auxiliary processor 140 can be another microcode processor 130 , and hence, the present invention is adaptable to support multiple microcode processors 130 simultaneously.
- auxiliary processor 140 is another microcode processor 130 that is coupled to its own microcode instruction memory 132 and microcode data memory 134 .
- microcode manager 116 provides centralized control of multiple microcode processors 130 .
- FIG. 2 illustrates a block diagram of microcode manager 116 according to an embodiment of the present invention.
- Microcode manager 116 includes a mode detector 212 , drawing data processor 214 , phase executor 216 , sequence identifier 218 , and code loader 220 .
- Mode detector 212 receives a signal from system software 114 . After processing the signal, mode detector 212 exchanges communications with drawing data processor 214 , phase executor 216 , sequence identifier 218 and/or code loader 220 , as required.
- drawing data processor 214 Based on a signal received from mode detector 212 , drawing data processor 214 sends drawing data to microcode processor 130 .
- the drawing data includes vertices and vertex data used to draw primitives (e.g., points, line segments, and polygon) on a display.
- Vertex data includes coordinates, colors, normals, texture coordinates, edge flags, or the like.
- Phase executor 216 , sequence identifier 218 and code loader 220 also exchange communications with mode detector 212 and microcode processor 130 . Based on a signal received from mode detector 212 , sequence identifier 218 determines or selects the appropriate microinstructions to be executed by microcode processor 130 . Sequence identifier 218 also signals code loader 220 to load the microinstructions into microcode processor 130 . Phase executor 216 primarily functions to command microcode processor 130 to process the microinstructions according to a predetermined sequence.
- microinstructions for performing certain tasks are grouped in respective phase modules or functions.
- Sequence identifier 218 selects an appropriate set and sequence of phase modules.
- An example of phase modules selection and sequencing of phase modules in a graphics environment according to the present invention is described below in further detail with respect to FIGS. 3-7 .
- microinstructions are stored in phase code depository 122 . Therefore, code loader 220 queries phase code depository 122 to select the appropriate microinstructions and send them to microcode instruction memory 132 . Alternatively, code loader 220 can command phase code depository 122 to send the microinstructions directly to microcode instruction memory 132 . In an embodiment, code loader 220 does not directly communicate with microcode instruction memory 132 . As such, the microinstructions are delivered to microcode processor 130 to route the microinstructions to microcode instruction memory 132 .
- microcode data memory 134 records the memory addresses of the phase modules located in microcode instruction memory 132 . Accordingly, code loader 220 also ensures that the memory addresses for the phase modules are written to microcode data memory 134 .
- Code loader 220 also manages the memory pool within microcode instruction memory 132 and/or microcode data memory 134 . As such, code loader 220 audits and removes or overwrites microinstructions and/or other data from microcode instruction memory 132 and/or microcode data memory 134 when the contents of the memories exceed certain capacity restrictions. Upon reaching the capacity restrictions, code loader 220 discards or overwrites the unused microinstructions on a first-in-first-out basis. In other words, code loader 220 would go to the beginning of the memory and start to overwrite the unused microinstructions. In an embodiment, code loader 220 analyzes or optimizes the memories by discarding all unused microinstructions prior to writing new microinstructions. In all embodiments, code loader 220 ensures that the addresses stored in microcode data memory 134 are updated, and the microinstructions are removed from microcode instruction memory 132 .
- code loader 220 polls microcode instruction memory 132 and/or microcode data memory 134 at a periodically scheduled rate to determine if the memories have exceeded their respective memory capacities or a predetermined threshold. In an alternative embodiment, microcode instruction memory 132 and/or microcode data memory 134 notifies code loader 220 upon reaching a predetermined threshold. In another embodiment, code loader 220 tracks the capacities of microcode instruction memory 132 and/or microcode data memory 134 as code loader 220 loads data into each respective memory. Hence, the present invention supports dynamic code loading to ensure the microinstructions and related data are available for microcode processor 130 when they are needed, but can be removed to make room for other information when the microinstructions and related data are not needed.
- code loader 220 builds a buffer to transfer microinstructions to microcode instruction memory 132 , code loader 220 is aware of the microinstructions that are currently residing in microcode instruction memory 132 . Therefore, code loader 220 only selects the microinstructions that need to be transferred.
- code loader 220 constructs or revises one or more path tables that are used to manage the memory pool within microcode instruction memory 132 and microcode data memory 134 .
- a path table (as described in further detail below in reference to FIG. 5 ) includes various information about the microinstructions to enable code loader 220 to quickly determine the current location of a set of microinstructions.
- the path table includes other attributes about the microinstructions, such as size, loading state, logical relations, and/or the like, as discussed in further detail below.
- FIG. 1 and FIG. 2 are conceptual illustrations of microcode management system 100 and microcode manager 116 , respectively, that allow an easy explanation of the present invention. That is, one or more of the blocks can be performed by the same piece of hardware or module of software. It should also be understood that embodiments of the present invention can be implemented in hardware, firmware, software, or any combination thereof. In such an embodiment, the various components and steps would be implemented in hardware, firmware and/or software to perform the functions of the present invention.
- primitives are used to render a model representing the object that is being drawn.
- the primitives can be drawn in a variety of modes that are set by a user.
- a user can be a human operator (not shown), application software 112 , system software 114 , or the like.
- Each mode set by the user can be broken-down into one or more phases used to control all fundamental graphical operations in two or three dimensional environments.
- FIG. 3 illustrates an exemplary compilation of phases (also referred to as “groups”) used in a graphics environment.
- the phases include transformation, lighting, post lighting transformation, clipping, fog, and final.
- Each phase includes one or more sub-phases.
- the sub-phases also referred to as “phase modules” or “functions”) specify the microinstructions for implementing the respective phase or certain attributes of the phase.
- the fog phase includes phase modules to perform calculations to implement a linear fog or exponential fog effect.
- Another phase is clipping which is used to fit corresponding primitives into a specified region.
- the clipping phase includes phase modules to instruct microcode processor 130 for clipping triangles, clipping strips of triangles, or clipping lines.
- FIG. 3 also includes two types of phase modules for the post lighting transformation phase.
- One phase module contains microinstructions for implementing no post lighting transformation.
- the second phase module contains microinstructions for implementing a post lighting projection transformation.
- the lighting phase includes a phase module for a single, simple light and a phase module for a single, complex light.
- the lighting phase also contains a phase module for multiple (i.e., “n”) simple lights, as well as a phase module for multiple complex lights. Phase modules for local or infinite lighting are also provided.
- the transformation phase modules contain microinstructions to implement a model view, normal, texture, projection, or a combination thereof. Although five combinations are shown, any combination or singularly selected view can be used.
- the final output phase module is used to instruct microcode processor 130 to suspend or cease processing, or send the results of the microcode processing to auxiliary processor 140 .
- Each module contains, or is associated with, instructions or a pointer to direct microcode processor 130 to read or process the microinstructions in the next module, except the output phase module.
- phase and sub-phases presented in FIG. 3 are illustrative and are not intended to limit the present invention. Other phases, sub-phases or a combination thereof can be used as would be apparent to one skilled in the relevant art(s).
- phase modules containing microinstructions for a phase or sub-phase, are stored in phase code depository 122 .
- the phase modules are prefabricated, tuned and stored in phase code depository 122 to be subsequently selected by sequence identifier 218 .
- the phase modules are generated by sequence identifier 218 in real time or near term, and transferred to phase code depository 122 .
- sequence identifier 218 selects a correct phase module or a sequence of phase modules (collectively referred to as a “phase module sequence”) to implement a desired mode.
- phase modules (excluding the output phase module) are interchangeable and capable of being synthesized in any order to implement a desired mode.
- some phase modules are order dependent and must be executed in a predetermined sequence.
- a group of order-dependent phase modules would be interchangeable and capable of being synthesized in any order with respect to other phase modules or groups of order-dependent phase modules.
- microcode manager 116 would generate, identify or retrieve a sequence of phase modules based on a mode command.
- the phase modules contain the microinstructions for implementing a specific phase or sub-phase. Since a mode consists of one or more designated phases or sub-phases, a phase module sequence can be produced to identify the requisite microinstructions to implement the phases or sub-phases for the desired mode.
- FIG. 4 a shows an example of a phase module sequence according to the present invention.
- This phase module sequence can be the by-product of a mode command to turn off texture transformation, turn on lighting, use infinite lighting, and turn off fog effects.
- sequence identifier 218 would determine that a normal transform phase module is needed because the lighting is turned on. It would also combine the normal transform phase module with the phase modules for model-view and projection transform since the lighting has been specified to be infinite. The infinite lighting phase module is also included to produce infinite lighting effects. Since fog has been turned off, no fog phase modules are needed.
- an output module is added to complete the phase module sequence.
- the phase module sequence would be assembled as “model-view, normal, projection transformation,” “infinite lighting,” and “output,” as shown in FIG. 4 a.
- a phase module sequence produced from a second mode command is shown in FIG. 4 b .
- This mode command requests a processor to turn on texture transformation and lighting, use local lighting, and turn on linear fog effects.
- This mode command would be analyzed to select model-view and projection transformation phase modules because model-space vertices would be needed to support local lighting.
- the local lighting phase module would be included.
- a normal transformation phase module is also needed since lighting is turned on.
- a texture transformation phase module would be included since texture transformation is turned on.
- a phase module for post lighting projection transformation is required because local lighting has been requested.
- a linear fog phase module and output phase module are added.
- phase module sequence would be “model-view, normal, texture transformation,” “local lighting,” “post lighting projection transformation,” “linear fog,” and “output,” as shown in FIG. 4 b .
- microcode memory savings can be realized and efficiency improved.
- Microcode instruction memory 132 and microcode data memory 134 need only store and process the selected phase module sequence. Other phase modules which are not selected need not be loaded into microcode instruction memory 132 .
- FIG. 5 a and FIG. 5 b illustrate phase modules according to another embodiment of the present invention. More specifically, FIG. 5 a shows a graphics pipeline 500 A containing a plurality of phases or groups 502 (shown as 502 a - 502 m ), and a plurality of functions or phase modules 504 (shown as 504 a - 504 m 2 ).
- each phase module 504 contains the microinstructions executed by microcode processor 130 to implement a sub-phase of a phase 502 .
- Fog phase 502 h contains three phase modules 504 h 1 - 504 h 2 .
- Phase module 504 h 1 includes the microinstructions for computing the fog calculations to implement a linear fog effect.
- Phase module 504 h 2 includes the microinstructions for implementing an exponential fog effect
- phase module 504 h 2 includes the microinstructions for exponential square effects.
- FIG. 5 b shows a pre-path graphics pipeline 500 B that contains a group module 502 (shown as 506 ) and a plurality of phase modules 504 (shown as 508 - 516 ).
- the phase modules 504 include a model-view, perspective (or projection) and screen (MVPS) module 508 , a model-view and perspective (MVP) module 510 , a perspective and screen (PS) module 512 , a texgen module 514 , and a normal module 516 .
- the matrix construction group module 506 provides the key for calling the microinstructions of phase modules 508 - 516 .
- pre-path graphics pipeline 500 B is used to prepare data for the primary graphics pipeline 500 A.
- FIG. 5 a and FIG. 5 b are provided for illustrative purposes and are not intended to limit the present invention. Other phases, sub-phases or a combination thereof can be used as would be apparent to one skilled in the relevant art(s).
- microcode manager 116 permits a user to added a new phase module 504 to increase the functionality of a specific group 502 or add an entirely new group 502 .
- a user can instruct microcode manager 116 to delete a phase module 504 or an entire group 502 .
- microcode manager 116 permits a user to modify the microinstructions and/or related data associated with the microinstructions, as required.
- Each phase module 504 contains or is associated with metadata that establishes the attributes for the phase modules 504 .
- the metadata resides in a header coupled to each phase module.
- the metadata resides in separate file, table or directory, that is associated with one or more phase modules 504 .
- the present invention allows the metadata to be used to define various types of attributes.
- the attributes include a phase module identifier that uniquely identifies each phase module 504 , and a group identifier that identifies the assigned group 502 .
- Another attribute is a loading state that indicates whether the respective phase module 504 is currently loaded into microcode processor 130 or auxiliary processor 140 .
- the attributes also include an address for the respective phase module 504 .
- a source address is used to designate the host address for the phase module 504 .
- the metadata also describes the logical relationship of a phase module 504 with another phase module 504 .
- the metadata stipulates which phase modules 504 can or cannot be concatenated or executed with another phase module 504 .
- the metadata also stipulates which phase modules 504 must be concatenated or executed with a specific phase module 504 .
- the metadata also includes a descriptor that provides a brief description of the functionality of a respective phase module 504 .
- the description also summarizes the purpose and properties.
- the data contained in the descriptor facilitates the ability for a user to analyze or edit a phase module 504 .
- phase module type is also stipulated in the metadata. If designated as a static phase module, the phase module 504 always resides in microcode instruction memory 132 . A static phase module is never overwritten or discarded by code loader 220 during a dynamic code loading operation. Additionally, a static phase module resides at a known address inside microcode instruction memory 132 .
- a shared phase module has several functions that use the same code base or share part of the same code.
- a shared phase module is treated as one module function whenever a load operation needs to get placed. When building a phase code sequence, the needed function will be retrieved from the shared phase module.
- MVPS module 508 is a shared phase module having functions interlaced with two branch functions, namely MVP module 510 and PS module 512 . Branch functions share part of the microinstructions residing in the shared phase module.
- MVP module 510 and PS module 512 share the microinstructions within MVPS 508 that are pertinent to preparing or processing the transformation data.
- a shared phase module can be overwritten or discarded by code loader 220 during dynamic code loading.
- the metadata associated with a shared phase module is used to track the address of the shared phase module inside microcode instruction memory 132 .
- a third phase module type is a volatile phase module.
- a volatile phase module can be overwritten or discarded by code loader 220 during dynamic code loading. However, a volatile phase module cannot be shared. Code loader 220 would read the loading state field to determine the location of a volatile phase module. The metadata associated with a volatile phase module is used to track the address of the volatile phase module inside microcode instruction memory 132 .
- the present invention supports two groups 502 of phase modules 506 .
- the groups are a generic group and a merger group.
- FIG. 6 illustrates exemplary generic groups 502 a - 502 l and merger groups 606 a - 610 according to an embodiment of the present invention.
- Generic groups 502 a - 502 l represent individual phases or groups 502 as described in reference to FIG. 5 .
- Merger groups 606 a - 610 are a combination of two or more generic groups 502 a - 502 l .
- Merger groups 606 a - 610 can also be created by concatenating one or more generic groups 502 a - 502 l with one or more other merger groups 606 a - 610 .
- merger groups 606 a - 610 can be a combination of multiple merger groups 606 a - 610 .
- merger groups 606 a - 610 illustrate an embodiment of generic groups 502 a - 502 l that have been concatenated logically.
- sequence identifier 218 is configured to validate or optimize the concatenation of a merger group. This is implemented by examining the logical relationships and like restrictions stipulated in the metadata for each group 502 .
- Merger groups 606 a - 606 b are a combination of two generic groups. Specifically, sequence identifier 218 would concatenate generic group 502 d and generic group 502 g to produce merger group 606 a . Sequence identifier 218 would concatenate generic group 502 g and generic group 502 l to produce generic group 606 b.
- Merger groups 608 a - 608 b include a combination of three generic groups.
- Merger group 608 a is a combination of merger group 606 a and generic group 502 l .
- Merger group 608 b is a combination of merger group 606 a and generic group 502 l.
- Merger group 610 includes a combination of four generic groups. Specifically, merger group 610 is a combination of generic group 502 l and merger group 608 a.
- flowchart 700 represents the general operational flow of an embodiment of the present invention. More specifically, flowchart 700 shows an example of a control flow for managing the utilization of microcode in system 100 . For convenience, the operation of the control flow in FIG. 7 is described with respect to the examples of FIG. 4 a and FIG. 4 b . However, this control flow is not necessarily limited to the examples of FIG. 4 a and FIG. 4 b.
- mode detector 212 detects a mode command from the user (e.g., application software 112 , system software 114 , or a human operator).
- the mode command is a request to either initiate or create a designated graphics mode, or change a current mode.
- mode detector 212 sends a signal to sequence identifier 218 to instruct it to generate, identify or determine a phase module sequence corresponding to the mode command.
- sequence identifier 218 analyzes the mode command to determine the microcode requirements for implementation.
- code loader 220 would query phase code depository 122 to select one or more phase modules matching the microcode requirements. An example of the results of such a query are shown in the phase code sequences of FIG. 4 a and FIG. 4 b.
- sequence identifier 218 constructs a path table for the phase module sequence.
- the path table contains various metadata associated with each phase module, including its purpose, properties and location.
- Sequence identifier 218 uses the path table to validate and/or optimize the phase module sequence.
- the present invention supports several types of validation techniques or methodologies.
- One type of validation is state validation.
- state validation sequence identifier 218 determines the loading state of each phase module within the phase module sequence. State validation occurs whenever a new mode requires the addition of a new phase module. State validation is not required to be implemented each time a parameter for a phase module changes.
- prepath validation A second type of validation is prepath validation.
- prepath pipeline 500 B is used to implement the microinstructions for prepath validation in an embodiment.
- Prepath validation is used to preprocess data for the phase module sequence.
- Prepath validation can be used to calculate values that will be used more than once.
- a third type is path validation which is used to build the actual phase module sequence that will be communicated to code loader 220 and executed by microcode processor 130 .
- Sequence identifier 218 analyzes each phase and its associated metadata to choose the optimal phase module. During this phase, sequence identifier 218 identifies which phase modules (or functions) are needed per phase (or group). Additionally, sequence identifier 218 determines if a faster version (or merger group) of the generic phase module sequence exists and is valid based on the requested mode command. Sequence identifier 218 uses a merger group(s) when possible to optimize microcode processing.
- code loader 220 receives a path table after it has been validated by sequence identifier 218 .
- Code loader 220 updates or reconciles the path table to verify the current state and addresses of the specified phase modules. Dynamic code loading can be implemented to ensure that unused phase modules are discarded. Code loader 220 can also ensure that duplicate phase modules are not loaded into microcode instruction memory 132 .
- code loader 220 In addition to loading the phase code sequence into microcode instruction memory 132 , code loader 220 also loads a corresponding sequence list into microcode data manager 134 .
- the sequence list contains the memory addresses to the phase modules stored in microcode instruction memory 132 . Therefore, when the phase module sequence is executed by microcode processor 130 , the sequence list would instruct microcode processor 130 where to find the requisite microinstructions.
- the sequence list can be a copy of the path table or a subset of data from the path table.
- mode detector 212 is notified that the phase module sequence has been identified and properly loaded into microcode instruction memory 132 . Mode detector 212 would then instruct drawing data processor 214 to send the related drawing data to microcode processor 130 .
- the drawing data includes a set of vertices and vertex data (e.g., coordinates, colors, normals, texture coordinates, edge flags or the like) used to draw primitives for an image.
- code loader 220 notifies drawing data processor 214 after the phase module sequence has been loaded, without having to interact with mode detector 212 .
- phase executor 216 sends a signal to microcode processor 130 to command it to execute the phase module sequence designated in microcode instruction memory 132 .
- microcode processor 130 would start by executing the microinstructions in the “model-view, normal, projection transformation” phase module.
- Microcode processor 130 uses the microinstructions to process all the vertices in the drawing data. The last line of code in this phase module instructs microcode processor 130 to read the next module.
- microcode processor 130 would read the last line, and at step 720 , would execute the microinstructions in the next phase module in FIG. 4 a , entitled “infinite lighting.” This process is repeated, once again, when microcode processor 130 reads the last line of the “infinite lighting” phase module, and initiates execution of the “output” phase module. The last line in the “output” phase module instructs microcode processor 130 that there are no more phase modules in this phase module sequence.
- the “output” phase module of FIG. 4 a instructs microcode processor 130 to send the results of the microcode processing to auxiliary processor 140 .
- Auxiliary processor 140 would use the results for further microcode processing, pixel processing, or the like.
- drawing data processor 214 is notified that all phase modules for the drawing data has been executed. If additional drawing data is available for the current mode, the control flow passes back to step 716 and drawing data processor 214 would forward the drawing data to microcode processor 130 . As a result, the phase module sequence is executed to implement the designated mode for the drawing data.
- step 736 mode detector 212 determines or verifies whether all mode commands have been executed or whether any new mode commands have been received for execution. State variables used to track mode changes, drawing data or the like can be stored in primary memory 120 or microcode data memory 134 . If additional mode commands are present, the control flow passes back to step 704 . Otherwise, the control flow ends as indicated by step 795 .
- the present invention can be implemented using hardware, firmware, software or a combination thereof and can be implemented in one or more computer systems or other processing systems. In fact, in an embodiment, the present invention is directed toward one or more computer systems capable of carrying out the functionality described herein.
- Computer system 800 is used to show an example environment in which the present invention can operate.
- Computer system 800 can include any type of computer graphics computer, virtual machine, processor (single bus, multiple bus, or bus-less processor(s)), workstation, and network architecture.
- processor single bus, multiple bus, or bus-less processor(s)
- workstation and network architecture.
- OpenGL® machine can be used including, but not limited to, graphics workstations manufactured by Silicon Graphics, Inc.
- Computer system 800 includes one or more processors, such as processor 804 and graphics engine 816 .
- Graphics engine 816 can be implemented as one or more processor chips. Graphics engine 816 can be included as a separate processor as shown in FIG. 8 , or as part of processor 804 .
- processor 804 can carry out the operations of one or more of central processor 110 , microcode processor 130 and auxiliary processor 140 (shown in FIG. 1 ).
- graphics engine 816 can carry out the operations of one or more of microcode processor 130 and auxiliary processor 140 .
- Processor 804 and graphics engine 816 are connected to a communication infrastructure 806 (e.g., a communications bus, cross-over bar, or network).
- a communication infrastructure 806 e.g., a communications bus, cross-over bar, or network.
- Computer system 800 can include a display interface 802 that forwards graphics, text, and other data from the communication infrastructure 806 (or from a frame buffer not shown) for display on the display unit 830 .
- Computer system 800 also includes a main memory 808 , preferably random access memory (RAM), and can also include a secondary memory 810 .
- main memory 808 preferably random access memory (RAM)
- secondary memory 810 preferably random access memory (RAM)
- primary memory 120 , microcode instruction memory 132 , microcode data memory 134 can be a component of either main memory 808 or secondary memory 810 .
- Secondary memory 810 can include, for example, a hard disk drive 812 and/or a removable storage drive 814 , representing a floppy disk drive, a magnetic tape drive, an optical disk drive, etc.
- the removable storage drive 814 reads from and/or writes to a removable storage unit 818 in a well-known manner.
- Removable storage unit 818 represents a floppy disk, magnetic tape, optical disk, etc. which is read by and written to removable storage drive 814 .
- the removable storage unit 818 includes a computer usable storage medium having stored therein computer software and/or data.
- secondary memory 810 can include other similar means for allowing computer programs or other instructions to be loaded into computer system 800 .
- Such means can include, for example, a removable storage unit 822 and an interface 820 .
- Examples of such can include a program cartridge and cartridge interface (such as that found in video game devices), a removable memory chip (such as an EPROM, or PROM) and associated socket, and other removable storage units 822 and interfaces 820 which allow software and data to be transferred from the removable storage unit 822 to computer system 800 .
- Computer system 800 can also include a communications interface 824 .
- Communications interface 824 allows software and data to be transferred between computer system 800 and external devices. Examples of communications interface 824 can include a modem, a network interface (such as an Ethernet card), a communications port, a PCMCIA slot and card, etc.
- Software and data transferred via communications interface 824 are in the form of signals 828 which can be electronic, electromagnetic, optical or other signals capable of being received by communications interface 824 . These signals 828 are provided to communications interface 824 via a communications path (i.e., channel) 826 .
- This channel 826 carries signals 828 and can be implemented using wire or cable, fiber optics, a phone line, a cellular phone link, an RF link and other communications channels.
- computer program medium and “computer usable medium” are used to generally refer to media such as removable storage drive 814 , a hard disk installed in hard disk drive 812 , and signals 828 .
- These computer program products are means for providing software to computer system 800 .
- the invention is directed to such computer program products.
- Computer programs are stored in main memory 808 and/or secondary memory 810 . Computer programs can also be received via communications interface 824 . Such computer programs, when executed, enable the computer system 800 to perform the features of the present invention as discussed herein. In particular, the computer programs, when executed, enable the processor 804 to perform the features of the present invention. Accordingly, such computer programs represent controllers of the computer system 800 .
- the software can be stored in a computer program product and loaded into computer system 800 using removable storage drive 814 , hard drive 812 or communications interface 824 .
- the control logic when executed by the processor 804 , causes the processor 804 to perform the functions of the invention as described herein.
- the invention is implemented primarily in hardware using, for example, hardware components such as application specific integrated circuits (ASICs).
- ASICs application specific integrated circuits
- the invention is implemented using a combination of both hardware and software.
Abstract
A memory management system provides microcode instructions that are divided into multiple tuned phases and stored as separate modules inside a phase code depository. A microcode manager, containing a mode detector, sequence identifier, code loader, drawing data processor and phase executor, interacts with a microcode processor and the phase code depository. The mode detector evaluates a user request for a desired mode. In response to a command from the mode detector, the sequence identifier selects a correct phase sequence that is needed to implement the desired mode. The code loader transfers the phase sequence from the phase code depository to the microcode processor where it is stored in a microcode instruction memory. The memory address for each module within the phase sequence is written to a microcode data memory. The drawing data for the graphics mode is sent from the drawing data processor to the microcode processor, and the phase executor instructs the microcode processor to execute the phase sequence to render the desired mode by processing the drawing data. The resulting data is forwarded to another processor for additional microcode processing, vector processing, rasterization, or the like. The ability to select interchangeable phase modules to implement a desired mode reduces microcode memory requirements and allows easy integration and reuse of previously developed features among different games and other graphics software developers without having to rely on the type of platform.
Description
- 1. Field of the Invention
- The present invention relates generally to memory management, and more particularly to improving the performance of microcoded functionality.
- 2. Related Art
- Conventional applications for computer graphics use a microcode engine to prepare the instructions to render various graphics modes. To increase the processing speed, the microcode instructions (i.e., microinstructions) include loop routines that are used to execute the rendering instructions. The loop routines are unrolled to reschedule or tune the microinstructions. A direct correlation can be observed between the complexity of graphics programs and the number of required routines. In short as graphics programs become more advanced and sophisticated, a substantial number of lines of microinstructions are needed to render various graphic modes. However, microcode engines tend to have limited random access memory (RAM) capacity. Once RAM is consumed, more processing time or a faster processor is required to support highly advanced graphics, including animation, gaming and other simulations.
- Tuning techniques are often used to improve performance and expand the capabilities of microcode engines. This improves the performance of microcoded transformations, lighting, and other graphics effects. However, most graphics applications have the ability to use several modes to render display frames. Each mode has the potential to contain various combinations of graphics effects, and each mode would require specifically tuned microinstructions to draw the effects. In general, there is not enough microcode memory space to have monolithic tuned rendering microcode for each mode that an application may want to use. Microcode branch instructions can be used to allow a single monolithic rendering code to work in several modes, but at the expense of extreme complexity in applying tuning techniques to maintain reasonable processing requirements for real time environments.
- Microinstructions are also dependent upon the platform being used to run the graphics program. The microcode capabilities of each graphics system, including its system and language related run-time libraries, vary and effect the efficiency and performance of the applications loaded onto the graphics system. Software developers for new graphics applications must consider the version, performance, and capabilities of these platforms when they build their applications. Otherwise, new video games, for example, either would not be able to use the microcode developed for the existing platform, or would not take full advantage of the microcode capabilities.
- What is needed is a method and system that overcome the above problems to efficiently manage microcode independent of the hardware and operating system.
- A microcode management system improves the performance and expands the capabilities of graphics software to use more tuning techniques and conserve limited memory on any type of computer platform. Rendering code for a microcode processor is assembled in one or more phases. Well-tuned versions of each phase are stored as distinct modules into a phase code depository for quick and easy access.
- A microcode manager contains various components designed to select a correct sequence of phases that are needed to implement a desired graphics mode. The components include a mode detector, sequence identifier, code loader, drawing data processor, and phase executor.
- The mode detector evaluates a user request for the desired graphics mode. In response to a command from the mode detector, the sequence identifier selects the correct phase sequence. The code loader transfers the phase sequence from the phase code depository to a microcode processor where it is temporarily stored in a microcode instruction memory. The memory address for each module within the phase sequence is written to a microcode data memory.
- The drawing data processor supplies vertices and vertex data to the microcode processor, and the phase executor instructs the microcode processor to execute the phase sequence to process the vertices and vertex data to render the desired graphics mode. The resulting data is forwarded to another processor for additional microcode processing, vector processing, rasterization, or the like.
- The accompanying drawings, which are incorporated herein and form part of the specification, illustrate the present invention and, together with the description, further serve to explain the principles of the invention and to enable a person skilled in the pertinent art to make and use the invention. In the drawings, like reference numbers indicate identical or functionally similar elements. Additionally, the leftmost digit(s) of a reference number identifies the drawing in which the reference number first appears.
-
FIG. 1 illustrates a block diagram of a microcode management system according to an embodiment of the present invention. -
FIG. 2 illustrates a block diagram of a microcode manager according to an embodiment of the present invention. -
FIG. 3 shows exemplary phase modules according to an embodiment of the present invention. -
FIG. 4 a shows an exemplary phase module sequence according to an embodiment of the present invention. -
FIG. 4 b shows an exemplary phase module sequence according to a second embodiment of the present invention. -
FIG. 5 a shows exemplary phase modules according to a third embodiment of the present invention. -
FIG. 5 b shows exemplary phase modules according to a fourth embodiment of the present invention. -
FIG. 6 shows exemplary generic groups and merger groups according to an embodiment of the present invention -
FIG. 7 illustrates an operational flow diagram for the steps involved in managing the utilization of microcode according to an embodiment of the present invention. -
FIG. 8 illustrates a block diagram of an example computer system useful for implementing the present invention. - I. Overview of Microcode Management System
- II. Microcode Management
- III. Phase Module Sequencing
- IV. Phase Module Attributes
- V. System Operation
- VI. Software and Hardware Embodiments
- VII. Conclusion
- I. Overview of Microcode Management System
-
FIG. 1 illustrates, according to an embodiment of the present invention, a block diagram of amicrocode management system 100. As shown,microcode management system 100 includes acentral processor 110,primary memory 120,microcode processor 130,microcode instruction memory 132,microcode data memory 134, andauxiliary processor 140.Central processor 110,microcode processor 130, andauxiliary processor 140 represent any commonly known or future-developed computer processor.Central processor 110 can be any processor developed by Intel Corporation, Advanced Micro Devices, Inc. (AMD), API NetWorks (Alpha), ARM Ltd., MIPS Technologies, Inc, or the like. In an embodiment,central processor 110 is the Emotion engine, available from Sony Computer Entertainment America Inc., that provides motion simulation capability for animation or gaming applications, including the Playstation® 2 entertainment system available from Sony Computer Entertainment America Inc. In an embodiment,microcode processor 130 is a vector processor capable of handling over eight floating-point operations at a given time. - Operating on
central processor 110 areapplication software 112,system software 114, andmicrocode manager 116.Application software 112 can be any currently available or future developed application, including, but not limited to, a game, word processing, presentation, spreadsheet, graphics, or the like. The formats supported by theapplication software 112 includes, but are not limited to, Virtual Reality Modeling Language (VRML) for three dimensional graphics, GIF for graphics, JPEG for photographs, the QuickTime® software available from Apple Computer, Inc. for dynamic media (i.e., audio and video), the Macromedia® Flash™ software available from Macromedia, Inc. for simple animation, the Macromedia® Shockwave® software available from Macromedia, Inc. for more advanced animation, the Adobe® Acrobat® software available from Adobe Systems Incorporated for documents, the Intrinsic Alchemy™ software available from Intrinsic Graphics, Inc. for gaming, or the like. -
System software 114 includes software for application program interfaces, browsers or operating systems, and interacts with other components ofsystem 100 to implement the instructions fromapplication software 112. In an embodiment,system software 114 includes the browser software, such as the Netscape® browser available from AOL/Netscape Communications, the Microsoft® Internet Explorer browser available from Microsoft Corporation, or the like, that is capable of handling Java, Java Script, C, C++, or like programming languages. In an embodiment,system software 114 includes operating software, such as, the NetWare™ operating system available from Novell®; the MS-DOS®, Windows NT® or Windows® 3.xx/95/98/2000 operating systems available from Microsoft Corporation; the Linux® operating system available from Linux Online Inc.; the Solaris™ operating system available from Sun Microsystems, Inc.; or the like. In an embodiment,system software 114 is the Intrinsic Alchemy™ software available from Intrinsic Graphics, Inc., which can be used to develop video games for personal computers, consoles, television set-top boxes, the Internet, wireless handheld devices, or real-time three dimensional graphic applications, such as a flight simulator for pilot training. In an embodiment,system software 114 is the OpenGL® application program interface, available from Silicon Graphics, Inc. In an embodiment,system software 114 is the DirectX® suite of multimedia application program interfaces available from Microsoft Corporation. -
Microcode manager 116, discussed in greater detailed below, serves as an interface betweenmicrocode processor 130 and various components withincentral processor 110. In an embodiment,microcode manager 116 is a software application loaded or operating as a separate module incentral processor 110. In another embodiment,microcode manager 116 is loaded into or operating as a part ofsystem software 114.Microcode manager 116 primarily receives signals fromsystem software 114 and interacts withmicrocode processor 130.Microcode processor 130 executes commands frommicrocode manager 116 as a sequence of microcode instructions (i.e., microinstructions). In an embodiment, the microinstructions are written specifically for the Vector Unit (VU0 or VU1) in a Playstation® 2 system. - Central processor 110 (including its
components application software 112,system software 114, and microcode manager 116) has access toprimary memory 120.Primary memory 120 contains data, instructions, state variables or the like that are required bycentral processor 110 or its components to carry out various functions. Specifically,primary memory 120 includes aphase code depository 122 that stores microinstructions that are delivered tomicrocode processor 130 for execution. - Similarly,
microcode processor 130 has access tomicrocode instruction memory 132 andmicrocode data memory 134 which store data, instructions, state variables, or the like that are necessary formicrocode processor 130 to function as designed.Microcode instruction memory 132 stores a sequence of microinstructions.Microcode data memory 134 stores a sequence list which is a compilation of addresses to the sequences listed inmicrocode instruction memory 132 in addition to other information required bymicrocode processor 130 and/or the microinstructions. Thus,microcode data memory 134 is queried to ascertain the location of a specific group of microinstructions stored inmicrocode instruction memory 132. -
Primary memory 120,microcode instruction memory 132, andmicrocode data memory 134 can be a component of a main memory, a secondary memory, or a memory cache. AlthoughFIG. 1 showsmicrocode processor 130 interacting directly withmicrocode instruction memory 132 andmicrocode data memory 134, in another embodiment,central processor 110 interacts directly withmicrocode instruction memory 132 and/ormicrocode data memory 134 to supply information tomicrocode processor 130, or for operations independent ofmicrocode processor 130. - As shown,
microcode data memory 134 andmicrocode instruction memory 132 are located externally tomicrocode processor 130. However, in another embodiment,microcode data memory 134 andmicrocode instruction memory 132 are internal components ofmicrocode processor 130. In this embodiment,microcode processor 130,microcode data memory 134, andmicrocode instruction memory 132 are integrated into a single device. -
Auxiliary processor 140 provides additional microcode processing, pixel processing, rasterization, vector processing, or the like.Microcode processor 130 directly communicates withauxiliary processor 140. However, in another embodiment, such communications are filtered or controlled throughcentral processor 110. - In an embodiment,
microcode instruction memory 132 and/ormicrocode data memory 134 interacts directly withauxiliary processor 140. For example,auxiliary processor 140 can be anothermicrocode processor 130, and hence, the present invention is adaptable to supportmultiple microcode processors 130 simultaneously. Moreover in an embodiment,auxiliary processor 140 is anothermicrocode processor 130 that is coupled to its ownmicrocode instruction memory 132 andmicrocode data memory 134. In this embodiment,microcode manager 116 provides centralized control ofmultiple microcode processors 130. - II. Microcode Management
-
FIG. 2 illustrates a block diagram ofmicrocode manager 116 according to an embodiment of the present invention.Microcode manager 116 includes amode detector 212, drawingdata processor 214,phase executor 216,sequence identifier 218, andcode loader 220.Mode detector 212 receives a signal fromsystem software 114. After processing the signal,mode detector 212 exchanges communications with drawingdata processor 214,phase executor 216,sequence identifier 218 and/orcode loader 220, as required. - Based on a signal received from
mode detector 212, drawingdata processor 214 sends drawing data tomicrocode processor 130. The drawing data includes vertices and vertex data used to draw primitives (e.g., points, line segments, and polygon) on a display. Vertex data includes coordinates, colors, normals, texture coordinates, edge flags, or the like. -
Phase executor 216,sequence identifier 218 andcode loader 220 also exchange communications withmode detector 212 andmicrocode processor 130. Based on a signal received frommode detector 212,sequence identifier 218 determines or selects the appropriate microinstructions to be executed bymicrocode processor 130.Sequence identifier 218 also signalscode loader 220 to load the microinstructions intomicrocode processor 130.Phase executor 216 primarily functions to commandmicrocode processor 130 to process the microinstructions according to a predetermined sequence. - In an embodiment, microinstructions for performing certain tasks are grouped in respective phase modules or functions.
Sequence identifier 218 then selects an appropriate set and sequence of phase modules. An example of phase modules selection and sequencing of phase modules in a graphics environment according to the present invention is described below in further detail with respect toFIGS. 3-7 . - As discussed, microinstructions are stored in
phase code depository 122. Therefore,code loader 220 queriesphase code depository 122 to select the appropriate microinstructions and send them tomicrocode instruction memory 132. Alternatively,code loader 220 can commandphase code depository 122 to send the microinstructions directly tomicrocode instruction memory 132. In an embodiment,code loader 220 does not directly communicate withmicrocode instruction memory 132. As such, the microinstructions are delivered tomicrocode processor 130 to route the microinstructions tomicrocode instruction memory 132. - As discussed,
microcode data memory 134 records the memory addresses of the phase modules located inmicrocode instruction memory 132. Accordingly,code loader 220 also ensures that the memory addresses for the phase modules are written tomicrocode data memory 134. -
Code loader 220 also manages the memory pool withinmicrocode instruction memory 132 and/ormicrocode data memory 134. As such,code loader 220 audits and removes or overwrites microinstructions and/or other data frommicrocode instruction memory 132 and/ormicrocode data memory 134 when the contents of the memories exceed certain capacity restrictions. Upon reaching the capacity restrictions,code loader 220 discards or overwrites the unused microinstructions on a first-in-first-out basis. In other words,code loader 220 would go to the beginning of the memory and start to overwrite the unused microinstructions. In an embodiment,code loader 220 analyzes or optimizes the memories by discarding all unused microinstructions prior to writing new microinstructions. In all embodiments,code loader 220 ensures that the addresses stored inmicrocode data memory 134 are updated, and the microinstructions are removed frommicrocode instruction memory 132. - In an embodiment,
code loader 220 polls microcodeinstruction memory 132 and/ormicrocode data memory 134 at a periodically scheduled rate to determine if the memories have exceeded their respective memory capacities or a predetermined threshold. In an alternative embodiment,microcode instruction memory 132 and/ormicrocode data memory 134 notifiescode loader 220 upon reaching a predetermined threshold. In another embodiment,code loader 220 tracks the capacities ofmicrocode instruction memory 132 and/ormicrocode data memory 134 ascode loader 220 loads data into each respective memory. Hence, the present invention supports dynamic code loading to ensure the microinstructions and related data are available formicrocode processor 130 when they are needed, but can be removed to make room for other information when the microinstructions and related data are not needed. Additionally, whencode loader 220 builds a buffer to transfer microinstructions tomicrocode instruction memory 132,code loader 220 is aware of the microinstructions that are currently residing inmicrocode instruction memory 132. Therefore,code loader 220 only selects the microinstructions that need to be transferred. - In an embodiment,
code loader 220 constructs or revises one or more path tables that are used to manage the memory pool withinmicrocode instruction memory 132 andmicrocode data memory 134. A path table (as described in further detail below in reference toFIG. 5 ) includes various information about the microinstructions to enablecode loader 220 to quickly determine the current location of a set of microinstructions. The path table includes other attributes about the microinstructions, such as size, loading state, logical relations, and/or the like, as discussed in further detail below. -
FIG. 1 andFIG. 2 are conceptual illustrations ofmicrocode management system 100 andmicrocode manager 116, respectively, that allow an easy explanation of the present invention. That is, one or more of the blocks can be performed by the same piece of hardware or module of software. It should also be understood that embodiments of the present invention can be implemented in hardware, firmware, software, or any combination thereof. In such an embodiment, the various components and steps would be implemented in hardware, firmware and/or software to perform the functions of the present invention. - III. Phase Module Sequencing
- To render an image in a computer graphics environment, primitives are used to render a model representing the object that is being drawn. The primitives can be drawn in a variety of modes that are set by a user. A user can be a human operator (not shown),
application software 112,system software 114, or the like. Each mode set by the user can be broken-down into one or more phases used to control all fundamental graphical operations in two or three dimensional environments. -
FIG. 3 illustrates an exemplary compilation of phases (also referred to as “groups”) used in a graphics environment. The phases include transformation, lighting, post lighting transformation, clipping, fog, and final. Each phase includes one or more sub-phases. The sub-phases (also referred to as “phase modules” or “functions”) specify the microinstructions for implementing the respective phase or certain attributes of the phase. For example, the fog phase includes phase modules to perform calculations to implement a linear fog or exponential fog effect. Another phase is clipping which is used to fit corresponding primitives into a specified region. The clipping phase includes phase modules to instructmicrocode processor 130 for clipping triangles, clipping strips of triangles, or clipping lines. -
FIG. 3 also includes two types of phase modules for the post lighting transformation phase. One phase module contains microinstructions for implementing no post lighting transformation. The second phase module contains microinstructions for implementing a post lighting projection transformation. - The lighting phase includes a phase module for a single, simple light and a phase module for a single, complex light. The lighting phase also contains a phase module for multiple (i.e., “n”) simple lights, as well as a phase module for multiple complex lights. Phase modules for local or infinite lighting are also provided.
- The transformation phase modules contain microinstructions to implement a model view, normal, texture, projection, or a combination thereof. Although five combinations are shown, any combination or singularly selected view can be used.
- The final output phase module is used to instruct
microcode processor 130 to suspend or cease processing, or send the results of the microcode processing toauxiliary processor 140. Each module contains, or is associated with, instructions or a pointer todirect microcode processor 130 to read or process the microinstructions in the next module, except the output phase module. - The phases and sub-phases presented in
FIG. 3 are illustrative and are not intended to limit the present invention. Other phases, sub-phases or a combination thereof can be used as would be apparent to one skilled in the relevant art(s). - The phase modules, containing microinstructions for a phase or sub-phase, are stored in
phase code depository 122. In an embodiment, the phase modules are prefabricated, tuned and stored inphase code depository 122 to be subsequently selected bysequence identifier 218. In another embodiment, the phase modules are generated bysequence identifier 218 in real time or near term, and transferred to phasecode depository 122. In both embodiments,sequence identifier 218 selects a correct phase module or a sequence of phase modules (collectively referred to as a “phase module sequence”) to implement a desired mode. - The phase modules (excluding the output phase module) are interchangeable and capable of being synthesized in any order to implement a desired mode. However, some phase modules are order dependent and must be executed in a predetermined sequence. In this case, a group of order-dependent phase modules would be interchangeable and capable of being synthesized in any order with respect to other phase modules or groups of order-dependent phase modules.
- Typically in computer graphics, the user supplies function calls to set the vertices, normals, primitives, textual coordinates, other operations, or the like to render an image. These function calls also specify the mode for rendering an image, and are, therefore, referred to as mode commands. As such, a mode command is a request to either initiate or create one or more designated graphics modes, or change a current graphics mode.
- To create or change a mode,
microcode manager 116 would generate, identify or retrieve a sequence of phase modules based on a mode command. As discussed, the phase modules contain the microinstructions for implementing a specific phase or sub-phase. Since a mode consists of one or more designated phases or sub-phases, a phase module sequence can be produced to identify the requisite microinstructions to implement the phases or sub-phases for the desired mode. -
FIG. 4 a shows an example of a phase module sequence according to the present invention. This phase module sequence can be the by-product of a mode command to turn off texture transformation, turn on lighting, use infinite lighting, and turn off fog effects. By analyzing the mode command,sequence identifier 218 would determine that a normal transform phase module is needed because the lighting is turned on. It would also combine the normal transform phase module with the phase modules for model-view and projection transform since the lighting has been specified to be infinite. The infinite lighting phase module is also included to produce infinite lighting effects. Since fog has been turned off, no fog phase modules are needed. Finally, an output module is added to complete the phase module sequence. Hence, the phase module sequence would be assembled as “model-view, normal, projection transformation,” “infinite lighting,” and “output,” as shown inFIG. 4 a. - A phase module sequence produced from a second mode command is shown in
FIG. 4 b. This mode command requests a processor to turn on texture transformation and lighting, use local lighting, and turn on linear fog effects. This mode command would be analyzed to select model-view and projection transformation phase modules because model-space vertices would be needed to support local lighting. The local lighting phase module would be included. A normal transformation phase module is also needed since lighting is turned on. A texture transformation phase module would be included since texture transformation is turned on. A phase module for post lighting projection transformation is required because local lighting has been requested. Finally, a linear fog phase module and output phase module are added. As such, the phase module sequence would be “model-view, normal, texture transformation,” “local lighting,” “post lighting projection transformation,” “linear fog,” and “output,” as shown inFIG. 4 b. In this way, according to the present invention, microcode memory savings can be realized and efficiency improved.Microcode instruction memory 132 andmicrocode data memory 134 need only store and process the selected phase module sequence. Other phase modules which are not selected need not be loaded intomicrocode instruction memory 132. - IV. Phase Module Attributes
-
FIG. 5 a andFIG. 5 b illustrate phase modules according to another embodiment of the present invention. More specifically,FIG. 5 a shows agraphics pipeline 500A containing a plurality of phases or groups 502 (shown as 502 a-502 m), and a plurality of functions or phase modules 504 (shown as 504 a-504 m 2). Hence, each phase module 504 contains the microinstructions executed bymicrocode processor 130 to implement a sub-phase of a phase 502. For example,Fog phase 502 h contains three phase modules 504 h 1-504 h 2. Phase module 504h 1 includes the microinstructions for computing the fog calculations to implement a linear fog effect. Phase module 504 h 2 includes the microinstructions for implementing an exponential fog effect, and phase module 504 h 2 includes the microinstructions for exponential square effects. -
FIG. 5 b shows apre-path graphics pipeline 500B that contains a group module 502 (shown as 506) and a plurality of phase modules 504 (shown as 508-516). The phase modules 504 include a model-view, perspective (or projection) and screen (MVPS)module 508, a model-view and perspective (MVP)module 510, a perspective and screen (PS)module 512, atexgen module 514, and anormal module 516. The matrix construction group module 506 provides the key for calling the microinstructions of phase modules 508-516. As discussed in detail below,pre-path graphics pipeline 500B is used to prepare data for theprimary graphics pipeline 500A. -
FIG. 5 a andFIG. 5 b are provided for illustrative purposes and are not intended to limit the present invention. Other phases, sub-phases or a combination thereof can be used as would be apparent to one skilled in the relevant art(s). In an embodiment,microcode manager 116 permits a user to added a new phase module 504 to increase the functionality of a specific group 502 or add an entirely new group 502. In an embodiment, a user can instructmicrocode manager 116 to delete a phase module 504 or an entire group 502. In another embodiment,microcode manager 116 permits a user to modify the microinstructions and/or related data associated with the microinstructions, as required. - The related data associated with the microinstructions is referred to as metadata. Each phase module 504 contains or is associated with metadata that establishes the attributes for the phase modules 504. The metadata resides in a header coupled to each phase module. Alternatively, the metadata resides in separate file, table or directory, that is associated with one or more phase modules 504.
- The present invention allows the metadata to be used to define various types of attributes. The attributes include a phase module identifier that uniquely identifies each phase module 504, and a group identifier that identifies the assigned group 502. Another attribute is a loading state that indicates whether the respective phase module 504 is currently loaded into
microcode processor 130 orauxiliary processor 140. The attributes also include an address for the respective phase module 504. A source address is used to designate the host address for the phase module 504. The host address is the location of the phase module 504 inphase code depository 122; however, a phase module 504 can also be stored in other memory areas or storage mediums (such as, a hard disk drive, CD-ROM, etc.) as would be apparent to one skilled in the relevant art(s). A destination address is used to designate the location of the phase module 504 inmicrocode processor 130,microcode instruction memory 132, orauxiliary processor 140. In a multiple processing environment having a plurality ofmicrocode processors 130, the destination address indicates the location of the phase module 504 in therespective microcode processor 130. - The metadata also describes the logical relationship of a phase module 504 with another phase module 504. Specifically, the metadata stipulates which phase modules 504 can or cannot be concatenated or executed with another phase module 504. The metadata also stipulates which phase modules 504 must be concatenated or executed with a specific phase module 504.
- In an embodiment, the metadata also includes a descriptor that provides a brief description of the functionality of a respective phase module 504. The description also summarizes the purpose and properties. The data contained in the descriptor facilitates the ability for a user to analyze or edit a phase module 504.
- A phase module type is also stipulated in the metadata. If designated as a static phase module, the phase module 504 always resides in
microcode instruction memory 132. A static phase module is never overwritten or discarded bycode loader 220 during a dynamic code loading operation. Additionally, a static phase module resides at a known address insidemicrocode instruction memory 132. - Another phase module type is a shared phase module. A shared phase module has several functions that use the same code base or share part of the same code. A shared phase module is treated as one module function whenever a load operation needs to get placed. When building a phase code sequence, the needed function will be retrieved from the shared phase module. Referring back to
FIG. 5 b,MVPS module 508 is a shared phase module having functions interlaced with two branch functions, namelyMVP module 510 andPS module 512. Branch functions share part of the microinstructions residing in the shared phase module. InFIG. 5 b,MVP module 510 andPS module 512 share the microinstructions withinMVPS 508 that are pertinent to preparing or processing the transformation data. A shared phase module can be overwritten or discarded bycode loader 220 during dynamic code loading. The metadata associated with a shared phase module is used to track the address of the shared phase module insidemicrocode instruction memory 132. - A third phase module type is a volatile phase module. A volatile phase module can be overwritten or discarded by
code loader 220 during dynamic code loading. However, a volatile phase module cannot be shared.Code loader 220 would read the loading state field to determine the location of a volatile phase module. The metadata associated with a volatile phase module is used to track the address of the volatile phase module insidemicrocode instruction memory 132. - Another attribute specified in the metadata is a group type. The present invention supports two groups 502 of phase modules 506. The groups are a generic group and a merger group.
FIG. 6 illustrates exemplary generic groups 502 a-502 l and merger groups 606 a-610 according to an embodiment of the present invention. Generic groups 502 a-502 l represent individual phases or groups 502 as described in reference toFIG. 5 . - Merger groups 606 a-610 are a combination of two or more generic groups 502 a-502 l. Merger groups 606 a-610 can also be created by concatenating one or more generic groups 502 a-502 l with one or more other merger groups 606 a-610. Additionally, merger groups 606 a-610 can be a combination of multiple merger groups 606 a-610.
- Referring to
FIG. 6 , merger groups 606 a-610 illustrate an embodiment of generic groups 502 a-502 l that have been concatenated logically. In an embodiment,sequence identifier 218 is configured to validate or optimize the concatenation of a merger group. This is implemented by examining the logical relationships and like restrictions stipulated in the metadata for each group 502. - Merger groups 606 a-606 b are a combination of two generic groups. Specifically,
sequence identifier 218 would concatenategeneric group 502 d andgeneric group 502 g to producemerger group 606 a.Sequence identifier 218 would concatenategeneric group 502 g and generic group 502 l to producegeneric group 606 b. - Merger groups 608 a-608 b include a combination of three generic groups.
Merger group 608 a is a combination ofmerger group 606 a and generic group 502 l. Merger group 608 b is a combination ofmerger group 606 a and generic group 502 l. -
Merger group 610 includes a combination of four generic groups. Specifically,merger group 610 is a combination of generic group 502 l andmerger group 608 a. - V. System Operation
- Referring to
FIG. 7 ,flowchart 700 represents the general operational flow of an embodiment of the present invention. More specifically,flowchart 700 shows an example of a control flow for managing the utilization of microcode insystem 100. For convenience, the operation of the control flow inFIG. 7 is described with respect to the examples ofFIG. 4 a andFIG. 4 b. However, this control flow is not necessarily limited to the examples ofFIG. 4 a andFIG. 4 b. - Referring to
FIG. 7 , the control flow offlowchart 700 begins atstep 701 and passes immediately to step 704. Atstep 704,mode detector 212 detects a mode command from the user (e.g.,application software 112,system software 114, or a human operator). The mode command is a request to either initiate or create a designated graphics mode, or change a current mode. - At
step 708,mode detector 212 sends a signal to sequenceidentifier 218 to instruct it to generate, identify or determine a phase module sequence corresponding to the mode command. In an embodiment,sequence identifier 218 analyzes the mode command to determine the microcode requirements for implementation. Afterwards,code loader 220 would queryphase code depository 122 to select one or more phase modules matching the microcode requirements. An example of the results of such a query are shown in the phase code sequences ofFIG. 4 a andFIG. 4 b. - In an embodiment,
sequence identifier 218 constructs a path table for the phase module sequence. The path table contains various metadata associated with each phase module, including its purpose, properties and location.Sequence identifier 218 uses the path table to validate and/or optimize the phase module sequence. The present invention supports several types of validation techniques or methodologies. One type of validation is state validation. During state validation,sequence identifier 218 determines the loading state of each phase module within the phase module sequence. State validation occurs whenever a new mode requires the addition of a new phase module. State validation is not required to be implemented each time a parameter for a phase module changes. - A second type of validation is prepath validation. Referring back to
FIG. 5 b,prepath pipeline 500B is used to implement the microinstructions for prepath validation in an embodiment. Prepath validation is used to preprocess data for the phase module sequence. Prepath validation can be used to calculate values that will be used more than once. - A third type is path validation which is used to build the actual phase module sequence that will be communicated to
code loader 220 and executed bymicrocode processor 130.Sequence identifier 218 analyzes each phase and its associated metadata to choose the optimal phase module. During this phase,sequence identifier 218 identifies which phase modules (or functions) are needed per phase (or group). Additionally,sequence identifier 218 determines if a faster version (or merger group) of the generic phase module sequence exists and is valid based on the requested mode command.Sequence identifier 218 uses a merger group(s) when possible to optimize microcode processing. - Referring back to
FIG. 7 atstep 712, the selected or identified phase code sequence is copied and/or transferred tomicrocode instruction memory 132. In an embodiment,code loader 220 receives a path table after it has been validated bysequence identifier 218.Code loader 220 updates or reconciles the path table to verify the current state and addresses of the specified phase modules. Dynamic code loading can be implemented to ensure that unused phase modules are discarded.Code loader 220 can also ensure that duplicate phase modules are not loaded intomicrocode instruction memory 132. - In addition to loading the phase code sequence into
microcode instruction memory 132,code loader 220 also loads a corresponding sequence list intomicrocode data manager 134. The sequence list contains the memory addresses to the phase modules stored inmicrocode instruction memory 132. Therefore, when the phase module sequence is executed bymicrocode processor 130, the sequence list would instructmicrocode processor 130 where to find the requisite microinstructions. The sequence list can be a copy of the path table or a subset of data from the path table. - At
step 716,mode detector 212 is notified that the phase module sequence has been identified and properly loaded intomicrocode instruction memory 132.Mode detector 212 would then instruct drawingdata processor 214 to send the related drawing data tomicrocode processor 130. The drawing data includes a set of vertices and vertex data (e.g., coordinates, colors, normals, texture coordinates, edge flags or the like) used to draw primitives for an image. In another embodiment,code loader 220 notifies drawingdata processor 214 after the phase module sequence has been loaded, without having to interact withmode detector 212. - After
microcode processor 130 receives the drawing data, a signal is sent to notifyphase executor 216 from eithermode detector 212 or drawingdata processor 214. Atstep 720,phase executor 216 sends a signal tomicrocode processor 130 to command it to execute the phase module sequence designated inmicrocode instruction memory 132. Referring back to the example ofFIG. 4 a,microcode processor 130 would start by executing the microinstructions in the “model-view, normal, projection transformation” phase module.Microcode processor 130 uses the microinstructions to process all the vertices in the drawing data. The last line of code in this phase module instructsmicrocode processor 130 to read the next module. Atstep 724 inFIG. 7 ,microcode processor 130 would read the last line, and atstep 720, would execute the microinstructions in the next phase module inFIG. 4 a, entitled “infinite lighting.” This process is repeated, once again, whenmicrocode processor 130 reads the last line of the “infinite lighting” phase module, and initiates execution of the “output” phase module. The last line in the “output” phase module instructsmicrocode processor 130 that there are no more phase modules in this phase module sequence. - Referring back to
FIG. 7 , atstep 728, the “output” phase module ofFIG. 4 a instructsmicrocode processor 130 to send the results of the microcode processing toauxiliary processor 140.Auxiliary processor 140 would use the results for further microcode processing, pixel processing, or the like. - At
step 732, drawingdata processor 214 is notified that all phase modules for the drawing data has been executed. If additional drawing data is available for the current mode, the control flow passes back to step 716 and drawingdata processor 214 would forward the drawing data tomicrocode processor 130. As a result, the phase module sequence is executed to implement the designated mode for the drawing data. - If, on the other hand, no additional drawing data is required to be processed, the control flow passes to step 736. At
step 736,mode detector 212 determines or verifies whether all mode commands have been executed or whether any new mode commands have been received for execution. State variables used to track mode changes, drawing data or the like can be stored inprimary memory 120 ormicrocode data memory 134. If additional mode commands are present, the control flow passes back to step 704. Otherwise, the control flow ends as indicated bystep 795. - VI. Software and Hardware Embodiments
- The present invention can be implemented using hardware, firmware, software or a combination thereof and can be implemented in one or more computer systems or other processing systems. In fact, in an embodiment, the present invention is directed toward one or more computer systems capable of carrying out the functionality described herein.
- Referring to
FIG. 8 ,computer system 800 is used to show an example environment in which the present invention can operate.Computer system 800 can include any type of computer graphics computer, virtual machine, processor (single bus, multiple bus, or bus-less processor(s)), workstation, and network architecture. In an embodiment, an OpenGL® machine can be used including, but not limited to, graphics workstations manufactured by Silicon Graphics, Inc. -
Computer system 800 includes one or more processors, such asprocessor 804 andgraphics engine 816.Graphics engine 816 can be implemented as one or more processor chips.Graphics engine 816 can be included as a separate processor as shown inFIG. 8 , or as part ofprocessor 804. - For example,
processor 804 can carry out the operations of one or more ofcentral processor 110,microcode processor 130 and auxiliary processor 140 (shown inFIG. 1 ). Similarly,graphics engine 816 can carry out the operations of one or more ofmicrocode processor 130 andauxiliary processor 140. -
Processor 804 andgraphics engine 816 are connected to a communication infrastructure 806 (e.g., a communications bus, cross-over bar, or network). Various software embodiments are described in terms of this exemplary computer system. After reading this description, it will become apparent to a person skilled in the relevant art(s) how to implement the invention using other computer systems and/or computer architectures. -
Computer system 800 can include adisplay interface 802 that forwards graphics, text, and other data from the communication infrastructure 806 (or from a frame buffer not shown) for display on thedisplay unit 830. -
Computer system 800 also includes amain memory 808, preferably random access memory (RAM), and can also include asecondary memory 810. For example, referring back toFIG. 1 ,primary memory 120,microcode instruction memory 132,microcode data memory 134 can be a component of eithermain memory 808 orsecondary memory 810. -
Secondary memory 810 can include, for example, ahard disk drive 812 and/or aremovable storage drive 814, representing a floppy disk drive, a magnetic tape drive, an optical disk drive, etc. Theremovable storage drive 814 reads from and/or writes to aremovable storage unit 818 in a well-known manner.Removable storage unit 818, represents a floppy disk, magnetic tape, optical disk, etc. which is read by and written toremovable storage drive 814. As will be appreciated, theremovable storage unit 818 includes a computer usable storage medium having stored therein computer software and/or data. - In alternative embodiments,
secondary memory 810 can include other similar means for allowing computer programs or other instructions to be loaded intocomputer system 800. Such means can include, for example, aremovable storage unit 822 and aninterface 820. Examples of such can include a program cartridge and cartridge interface (such as that found in video game devices), a removable memory chip (such as an EPROM, or PROM) and associated socket, and otherremovable storage units 822 andinterfaces 820 which allow software and data to be transferred from theremovable storage unit 822 tocomputer system 800. -
Computer system 800 can also include acommunications interface 824. Communications interface 824 allows software and data to be transferred betweencomputer system 800 and external devices. Examples ofcommunications interface 824 can include a modem, a network interface (such as an Ethernet card), a communications port, a PCMCIA slot and card, etc. Software and data transferred viacommunications interface 824 are in the form ofsignals 828 which can be electronic, electromagnetic, optical or other signals capable of being received bycommunications interface 824. Thesesignals 828 are provided tocommunications interface 824 via a communications path (i.e., channel) 826. Thischannel 826 carriessignals 828 and can be implemented using wire or cable, fiber optics, a phone line, a cellular phone link, an RF link and other communications channels. - In this document, the terms “computer program medium” and “computer usable medium” are used to generally refer to media such as
removable storage drive 814, a hard disk installed inhard disk drive 812, and signals 828. These computer program products are means for providing software tocomputer system 800. The invention is directed to such computer program products. - Computer programs (also called computer control logic) are stored in
main memory 808 and/orsecondary memory 810. Computer programs can also be received viacommunications interface 824. Such computer programs, when executed, enable thecomputer system 800 to perform the features of the present invention as discussed herein. In particular, the computer programs, when executed, enable theprocessor 804 to perform the features of the present invention. Accordingly, such computer programs represent controllers of thecomputer system 800. - In an embodiment where the invention is implemented using software, the software can be stored in a computer program product and loaded into
computer system 800 usingremovable storage drive 814,hard drive 812 orcommunications interface 824. The control logic (software), when executed by theprocessor 804, causes theprocessor 804 to perform the functions of the invention as described herein. - In another embodiment, the invention is implemented primarily in hardware using, for example, hardware components such as application specific integrated circuits (ASICs). Implementation of the hardware state machine so as to perform the functions described herein will be apparent to persons skilled in the relevant art(s).
- In yet another embodiment, the invention is implemented using a combination of both hardware and software.
- VII. Conclusion
- While various embodiments of the present invention have been described above, it should be understood that they have been presented by way of example, and not limitation. It will be apparent to persons skilled in the relevant art(s) that various changes in form and detail can be made therein without departing from the spirit and scope of the invention. Thus, the present invention should not be limited by any of the above described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.
Claims (2)
1. A method for managing microcode, comprising the steps of:
evaluating a mode command to initiate or change a mode, said mode having one or more phases; and
identifying a phase module sequence in response to said evaluated mode command, wherein said phase module sequence includes at least one phase module containing microcode to implement a corresponding phase.
2.-23. (canceled)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/512,055 US20070273700A1 (en) | 2001-02-09 | 2006-08-29 | Method, system and computer program product for efficiently utilizing limited resources in a graphics device |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US26743401P | 2001-02-09 | 2001-02-09 | |
US09/904,541 US7098921B2 (en) | 2001-02-09 | 2001-07-16 | Method, system and computer program product for efficiently utilizing limited resources in a graphics device |
US11/512,055 US20070273700A1 (en) | 2001-02-09 | 2006-08-29 | Method, system and computer program product for efficiently utilizing limited resources in a graphics device |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/904,541 Continuation US7098921B2 (en) | 2001-02-09 | 2001-07-16 | Method, system and computer program product for efficiently utilizing limited resources in a graphics device |
Publications (1)
Publication Number | Publication Date |
---|---|
US20070273700A1 true US20070273700A1 (en) | 2007-11-29 |
Family
ID=26952434
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/904,541 Expired - Lifetime US7098921B2 (en) | 2001-02-09 | 2001-07-16 | Method, system and computer program product for efficiently utilizing limited resources in a graphics device |
US11/512,055 Abandoned US20070273700A1 (en) | 2001-02-09 | 2006-08-29 | Method, system and computer program product for efficiently utilizing limited resources in a graphics device |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/904,541 Expired - Lifetime US7098921B2 (en) | 2001-02-09 | 2001-07-16 | Method, system and computer program product for efficiently utilizing limited resources in a graphics device |
Country Status (2)
Country | Link |
---|---|
US (2) | US7098921B2 (en) |
WO (1) | WO2002065281A1 (en) |
Cited By (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8439733B2 (en) | 2007-06-14 | 2013-05-14 | Harmonix Music Systems, Inc. | Systems and methods for reinstating a player within a rhythm-action game |
US8444464B2 (en) | 2010-06-11 | 2013-05-21 | Harmonix Music Systems, Inc. | Prompting a player of a dance game |
US8449360B2 (en) | 2009-05-29 | 2013-05-28 | Harmonix Music Systems, Inc. | Displaying song lyrics and vocal cues |
US8465366B2 (en) | 2009-05-29 | 2013-06-18 | Harmonix Music Systems, Inc. | Biasing a musical performance input to a part |
US8550908B2 (en) | 2010-03-16 | 2013-10-08 | Harmonix Music Systems, Inc. | Simulating musical instruments |
US8663013B2 (en) | 2008-07-08 | 2014-03-04 | Harmonix Music Systems, Inc. | Systems and methods for simulating a rock band experience |
US8678896B2 (en) | 2007-06-14 | 2014-03-25 | Harmonix Music Systems, Inc. | Systems and methods for asynchronous band interaction in a rhythm action game |
US8686269B2 (en) | 2006-03-29 | 2014-04-01 | Harmonix Music Systems, Inc. | Providing realistic interaction to a player of a music-based video game |
US8702485B2 (en) | 2010-06-11 | 2014-04-22 | Harmonix Music Systems, Inc. | Dance game and tutorial |
US9024166B2 (en) | 2010-09-09 | 2015-05-05 | Harmonix Music Systems, Inc. | Preventing subtractive track separation |
US9358456B1 (en) | 2010-06-11 | 2016-06-07 | Harmonix Music Systems, Inc. | Dance competition game |
US9981193B2 (en) | 2009-10-27 | 2018-05-29 | Harmonix Music Systems, Inc. | Movement based recognition and evaluation |
US10357714B2 (en) | 2009-10-27 | 2019-07-23 | Harmonix Music Systems, Inc. | Gesture-based user interface for navigating a menu |
Families Citing this family (19)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP1510915A1 (en) * | 2003-08-26 | 2005-03-02 | Siemens Aktiengesellschaft | Apparatus and method to adapt a hardware platform to any application program |
WO2005031559A1 (en) * | 2003-09-25 | 2005-04-07 | Dai Nippon Printing Co., Ltd | Image outputting apparatus and image outputting method |
US20070076255A1 (en) * | 2003-10-15 | 2007-04-05 | Dai Nipon Printing Co., Ltd | Image output apparatus, image output method, and image display method |
CN1308817C (en) * | 2003-12-29 | 2007-04-04 | 联想(北京)有限公司 | Starting method and device for multiple mode computer system |
US20050198482A1 (en) * | 2004-03-02 | 2005-09-08 | Altek Corporation | Central processing unit having a micro-code engine |
US8704837B2 (en) * | 2004-04-16 | 2014-04-22 | Apple Inc. | High-level program interface for graphics operations |
US8134561B2 (en) | 2004-04-16 | 2012-03-13 | Apple Inc. | System for optimizing graphics operations |
US7216220B2 (en) * | 2004-07-14 | 2007-05-08 | Stexar Corp. | Microprocessor with customer code store |
US20060290705A1 (en) * | 2005-06-24 | 2006-12-28 | Microsoft Corporation | Performing a pre-rendering pass in digital image processing |
US7554550B2 (en) * | 2005-06-24 | 2009-06-30 | Microsoft Corporation | Non-destructive processing of digital image data |
US7619628B2 (en) * | 2005-06-24 | 2009-11-17 | Microsoft Corporation | Caching digital image data |
TWI267003B (en) | 2005-07-05 | 2006-11-21 | Inventec Corp | Development system and method for computer game |
CN101388089A (en) * | 2005-08-09 | 2009-03-18 | 金蝶软件(中国)有限公司 | Service logical processing method and apparatus in workflow |
US9539513B2 (en) * | 2008-07-23 | 2017-01-10 | Jerome Hubert Wei | Method and system for simulations of dynamic motion and position |
US8453084B2 (en) | 2008-09-04 | 2013-05-28 | Synopsys, Inc. | Approximate functional matching in electronic systems |
US10713069B2 (en) | 2008-09-04 | 2020-07-14 | Synopsys, Inc. | Software and hardware emulation system |
US8626344B2 (en) * | 2009-08-21 | 2014-01-07 | Allure Energy, Inc. | Energy management system and method |
KR101849702B1 (en) | 2011-07-25 | 2018-04-17 | 삼성전자주식회사 | External Intrinsic Interface |
US9998284B2 (en) * | 2015-09-24 | 2018-06-12 | Intel Corporation | Methods and apparatus to provide isolated execution environments |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5874955A (en) * | 1994-02-03 | 1999-02-23 | International Business Machines Corporation | Interactive rule based system with selection feedback that parameterizes rules to constrain choices for multiple operations |
US6198488B1 (en) * | 1999-12-06 | 2001-03-06 | Nvidia | Transform, lighting and rasterization system embodied on a single semiconductor platform |
US6342892B1 (en) * | 1995-11-22 | 2002-01-29 | Nintendo Co., Ltd. | Video game system and coprocessor for video game system |
US6487565B1 (en) * | 1998-12-29 | 2002-11-26 | Microsoft Corporation | Updating animated images represented by scene graphs |
US6559842B1 (en) * | 1999-06-14 | 2003-05-06 | Sun Microsystems, Inc. | Compressing and decompressing graphics data using gosub-type instructions and direct and indirect attribute settings |
Family Cites Families (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH02278475A (en) | 1989-04-20 | 1990-11-14 | Hitachi Ltd | Graphic processor, using method for the same and microprocessor |
JPH04211896A (en) | 1990-03-06 | 1992-08-03 | Omron Corp | Program generation device and data processing system using the same |
EP0498067A2 (en) * | 1991-02-08 | 1992-08-12 | International Business Machines Corporation | Microcode generation for a scalable compound instruction set machine |
JP2882495B2 (en) | 1991-02-08 | 1999-04-12 | 三菱電機株式会社 | Communication equipment |
US5813026A (en) | 1994-08-31 | 1998-09-22 | Charles Borg | Portable electronic device for intermittently executing a program stored on transposable memory |
US5808690A (en) | 1996-01-02 | 1998-09-15 | Integrated Device Technology, Inc. | Image generation system, methods and computer program products using distributed processing |
US5956047A (en) | 1997-04-30 | 1999-09-21 | Hewlett-Packard Co. | ROM-based control units in a geometry accelerator for a computer graphics system |
US5914724A (en) * | 1997-06-30 | 1999-06-22 | Sun Microsystems, Inc | Lighting unit for a three-dimensional graphics accelerator with improved handling of incoming color values |
US6332218B1 (en) | 1998-06-30 | 2001-12-18 | Sun Microsystems, Inc. | System and method for automatically instantiating classes in a virtual machine |
US6272674B1 (en) | 1998-12-14 | 2001-08-07 | Nortel Networks Limited | Method and apparatus for loading a Java application program |
-
2001
- 2001-07-16 US US09/904,541 patent/US7098921B2/en not_active Expired - Lifetime
- 2001-08-01 WO PCT/US2001/041494 patent/WO2002065281A1/en active Application Filing
-
2006
- 2006-08-29 US US11/512,055 patent/US20070273700A1/en not_active Abandoned
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5874955A (en) * | 1994-02-03 | 1999-02-23 | International Business Machines Corporation | Interactive rule based system with selection feedback that parameterizes rules to constrain choices for multiple operations |
US6342892B1 (en) * | 1995-11-22 | 2002-01-29 | Nintendo Co., Ltd. | Video game system and coprocessor for video game system |
US6487565B1 (en) * | 1998-12-29 | 2002-11-26 | Microsoft Corporation | Updating animated images represented by scene graphs |
US6559842B1 (en) * | 1999-06-14 | 2003-05-06 | Sun Microsystems, Inc. | Compressing and decompressing graphics data using gosub-type instructions and direct and indirect attribute settings |
US6198488B1 (en) * | 1999-12-06 | 2001-03-06 | Nvidia | Transform, lighting and rasterization system embodied on a single semiconductor platform |
Cited By (22)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8686269B2 (en) | 2006-03-29 | 2014-04-01 | Harmonix Music Systems, Inc. | Providing realistic interaction to a player of a music-based video game |
US8444486B2 (en) | 2007-06-14 | 2013-05-21 | Harmonix Music Systems, Inc. | Systems and methods for indicating input actions in a rhythm-action game |
US8439733B2 (en) | 2007-06-14 | 2013-05-14 | Harmonix Music Systems, Inc. | Systems and methods for reinstating a player within a rhythm-action game |
US8690670B2 (en) | 2007-06-14 | 2014-04-08 | Harmonix Music Systems, Inc. | Systems and methods for simulating a rock band experience |
US8678895B2 (en) | 2007-06-14 | 2014-03-25 | Harmonix Music Systems, Inc. | Systems and methods for online band matching in a rhythm action game |
US8678896B2 (en) | 2007-06-14 | 2014-03-25 | Harmonix Music Systems, Inc. | Systems and methods for asynchronous band interaction in a rhythm action game |
US8663013B2 (en) | 2008-07-08 | 2014-03-04 | Harmonix Music Systems, Inc. | Systems and methods for simulating a rock band experience |
US8449360B2 (en) | 2009-05-29 | 2013-05-28 | Harmonix Music Systems, Inc. | Displaying song lyrics and vocal cues |
US8465366B2 (en) | 2009-05-29 | 2013-06-18 | Harmonix Music Systems, Inc. | Biasing a musical performance input to a part |
US10421013B2 (en) | 2009-10-27 | 2019-09-24 | Harmonix Music Systems, Inc. | Gesture-based user interface |
US10357714B2 (en) | 2009-10-27 | 2019-07-23 | Harmonix Music Systems, Inc. | Gesture-based user interface for navigating a menu |
US9981193B2 (en) | 2009-10-27 | 2018-05-29 | Harmonix Music Systems, Inc. | Movement based recognition and evaluation |
US8550908B2 (en) | 2010-03-16 | 2013-10-08 | Harmonix Music Systems, Inc. | Simulating musical instruments |
US8636572B2 (en) | 2010-03-16 | 2014-01-28 | Harmonix Music Systems, Inc. | Simulating musical instruments |
US8874243B2 (en) | 2010-03-16 | 2014-10-28 | Harmonix Music Systems, Inc. | Simulating musical instruments |
US9278286B2 (en) | 2010-03-16 | 2016-03-08 | Harmonix Music Systems, Inc. | Simulating musical instruments |
US8568234B2 (en) | 2010-03-16 | 2013-10-29 | Harmonix Music Systems, Inc. | Simulating musical instruments |
US8702485B2 (en) | 2010-06-11 | 2014-04-22 | Harmonix Music Systems, Inc. | Dance game and tutorial |
US9358456B1 (en) | 2010-06-11 | 2016-06-07 | Harmonix Music Systems, Inc. | Dance competition game |
US8562403B2 (en) | 2010-06-11 | 2013-10-22 | Harmonix Music Systems, Inc. | Prompting a player of a dance game |
US8444464B2 (en) | 2010-06-11 | 2013-05-21 | Harmonix Music Systems, Inc. | Prompting a player of a dance game |
US9024166B2 (en) | 2010-09-09 | 2015-05-05 | Harmonix Music Systems, Inc. | Preventing subtractive track separation |
Also Published As
Publication number | Publication date |
---|---|
US7098921B2 (en) | 2006-08-29 |
US20020109682A1 (en) | 2002-08-15 |
WO2002065281A1 (en) | 2002-08-22 |
WO2002065281A8 (en) | 2002-12-19 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7098921B2 (en) | Method, system and computer program product for efficiently utilizing limited resources in a graphics device | |
US11907691B2 (en) | Method and system of command buffer between a CPU and GPU | |
US7015909B1 (en) | Efficient use of user-defined shaders to implement graphics operations | |
US6995765B2 (en) | System, method, and computer program product for optimization of a scene graph | |
US7015915B1 (en) | Programming multiple chips from a command buffer | |
US5818469A (en) | Graphics interface processing methodology in symmetric multiprocessing or distributed network environments | |
US8237705B2 (en) | Hierarchical processor array | |
US7750915B1 (en) | Concurrent access of data elements stored across multiple banks in a shared memory resource | |
JPH07504054A (en) | Programming model for coprocessors in computer systems | |
EP1921583A2 (en) | Graphics processing apparatus | |
US8429656B1 (en) | Thread count throttling for efficient resource utilization | |
US5325485A (en) | Method and apparatus for displaying primitives processed by a parallel processor system in a sequential order | |
MX2008015162A (en) | Fast reconfiguration of graphics pipeline state. | |
CN105247478B (en) | For storing the method and relevant apparatus of order | |
GB2245129A (en) | Local display bus architecture and communications method for raster display | |
JP2000092390A (en) | Device and method for processing digital video signal | |
JPH10116346A (en) | High speed down-loading method for texture | |
US11727632B2 (en) | Shader binding management in ray tracing | |
CN110223216B (en) | Data processing method and device based on parallel PLB and computer storage medium | |
CN106325866A (en) | Cross-engine calling method and cross-engine calling device | |
JP2000089959A (en) | Data processor and data processing method | |
JPH10111858A (en) | Method and device for making graphics pipeline parallel | |
CN113971037A (en) | Application processing method and device, electronic equipment and storage medium | |
KR20000012135A (en) | Digital video processing apparatus | |
JPH07200312A (en) | Digital data processing system and error processing method |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |