Source: http://www.google.com/patents/US6831635?dq=6519629
Timestamp: 2015-04-21 19:21:16
Document Index: 282171825

Matched Legal Cases: ['art/9612', 'art4', 'art/9606', 'art4', 'art/9606', 'art7', 'art/9606', 'art5', 'art/9606', 'art6', 'art/9606', 'art8', 'art 2']

Patent US6831635 - Method and system for providing a unified API for both 2D and 3D graphics ... - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inAdvanced Patent SearchPatentsA method for controlling the algorithmic elements in 3D graphics systems via an improved 3D graphics API is provided. In one aspect, the invention unifies separately provided 2D and 3D graphics APIs into a single graphics interface, thereby eliminating redundancy of functionality and unnecessary data...http://www.google.com/patents/US6831635?utm_source=gb-gplus-sharePatent US6831635 - Method and system for providing a unified API for both 2D and 3D graphics objectsAdvanced Patent SearchPublication numberUS6831635 B2Publication typeGrantApplication numberUS 09/796,885Publication dateDec 14, 2004Filing dateMar 1, 2001Priority dateMar 1, 2001Fee statusPaidAlso published asUS20020178301Publication number09796885, 796885, US 6831635 B2, US 6831635B2, US-B2-6831635, US6831635 B2, US6831635B2InventorsCharles N. Boyd, Jeff M. J. Noyle, Michael A. ToelleOriginal AssigneeMicrosoft CorporationExport CitationBiBTeX, EndNote, RefManPatent Citations (24), Non-Patent Citations (68), Referenced by (24), Classifications (7), Legal Events (3) External Links: USPTO, USPTO Assignment, EspacenetMethod and system for providing a unified API for both 2D and 3D graphics objects
US 6831635 B2Abstract
A method for controlling the algorithmic elements in 3D graphics systems via an improved 3D graphics API is provided. In one aspect, the invention unifies separately provided 2D and 3D graphics APIs into a single graphics interface, thereby eliminating redundancy of functionality and unnecessary data types. As a result, a single mapping to various graphics objects replaces redundant mappings. A single texture download that optimizes the use of different graphics hardware is provided. A single instruction for effecting a resolution change is also provided.
What is claimed is: 1. A method for providing an interface between an application and a graphics pipeline that renders and processes graphics data, comprising:
merging a 2D graphics application programming interface (API) and a 3D graphics API into a single graphics API for both 2D and 3D graphics, wherein data types for the single graphics API apply to both 2D and 3D graphics, thereby eliminating redundant function calls for performing a specific function, such that only one function call for the specific function is utilized for both 2D data objects and 3D data objects. 2. A method according to claim 1, wherein redundant ftunction calls for performing a texture download are eliminated and wherein data is transferred from a system memory surface to a display memory surface, such that only one function call for the texture download is utilized for both 2D data objects and 3D data objects.
3. A method according to claim 2, further including utilizing a single texture download for at least one of a plurality of different texture download techniques, depending upon the hardware used incident thereto.
4. A method according to claim 3, further including optimizing the choice of said at least one of a plurality of different texture download techniques based upon a data transfer rate.
5. A method according to claim 4, wherein said optimizing is configured staticly beforehand, so as to control the number and order of hardware components that are used and in connection with the texture download.
6. A method according to claim 4, wherein said optimizing includes said single graphics API keeping track of how well hardware components, corresponding to said plurality of different texture download techniques, are keeping up in terms of free memory (capacity) and speed of data processing.
7. A method according to claim 6, wherein said optimizing is performed dynamically based upon an evaluation of the performance of texture downloading, with feedback from the hardware components.
8. A method according to claim 1, wherein redundant mappings to the same object are eliminated, such that only one mapping exists from the single graphics API to that object for both 2D data and 3D data.
9. A method according to claim 1, wherein redundant function calls for performing a resolution change are eliminated, such that only one function call for resolution change is utilized for both 2D data objects and 3D data objects.
10. A method according to claim 1, wherein redundant function calls for performing memory management are eliminated, such that only one way to manage memory is utilized for both 2D data objects and 3D data objects.
11. A method according to claim 10, wherein the single way to manage memory includes a single way to allocate memory for both 2D data and 3D data.
12. A method according to claim 11, wherein the single way to manage memory includes formatting the data according to the same memory structure for both 2D data and 3D data.
13. A modulated data signal carrying computer executable instiuctions of the single graphics API provided by the method of claim 1.
14. A computer readable medium bearing computer executable instructions for a single graphics API provided by the steps of merging a 2D graphics API and a 3D graphics API into the single graphics API for both 2D and 3D graphics, wherein data types for the single graphics API apply to both 2D and 3D graphics,
thereby eliminating redundant function calls for performing a specific function, such that only one function call for the specific function is utilized for both 2D data objects and 3D data objects. 15. The computer readable medium of claim 14, further comprising computer executable instructions for transferring data from a system memory surface to a display memory surface, such that only one function call for a texture download is utilized for both 2D data objects and 3D data objects.
16. The computer readable medium of claim 15, further comprising computer executable instructions for utilizing the single texture download for at least one of a plurality of different texture download techniques, depending upon the hardware used incident thereto.
17. The computer readable medium of claim 16, further comprising computer executable instructions for optimizing the choice of said at least one of a plurality of different texture download techniques based upon the data transfer rate.
18. The computer readable medium of claim 14, further comprising computer executable instructions for utilizing only one function call for resolution change for both 2D data objects and 3D data objects.
19. The computer readable medium of claim 14, further comprising computer executable instructions for utilizing only one way to manage memory for both 2D data objects and 3D data objects.
20. A computing device having a 3D graphics software interface as a layer between executing applications and a graphics pipeline that renders and processes graphics data, comprising:
a 3D graphics API, wherein said 3D graphics API merges a 2D graphics API and a 3D graphics API into a single graphics API for both 2D and 3D graphics, wherein data types for the single graphics API apply to both 2D and 3D graphics, and whereby redundant function calls for performing a specific function are eliminated, such that only one function call for the specific function is utilized for both 2D data objects and 3D data objects. 21. A computing device according to claim 20, wherein the specific function is a texture download wherein data is transferred from a system memory surface to a display memory surface.
22. A computing device according to claim 21, wherein redundant texture download function calls are eliminated, and a single texture download is provided for both 2D objects and 3D objects.
23. A computing device according to claim 22, wherein the single texture download utilizes at least one of a plurality of different texture download techniques, depending upon the hardware used incident thereto.
24. A computing device according to claim 23, wherein the choice of said at least one of a plurality of different texture download techniques is made according to optimization of the data transfer rate of the texture download.
25. A computing device according to claim 24, wherein said optimization is configured staticly beforehand, so as to control the number and order of hardware components that are used and in connection with the texture download.
26. A computing device according to claim 24, wherein said optimization includes said single graphics API keeping track of how well hardware components, corresponding to said plurality of different texture download techniques, are keeping up in terms of free memory (capacity) and speed of data processing.
27. A computing device according to claim 26, wherein said optimization is performed dynamically based upon an evaluation of the performance of texture downloading, with feedback from the hardware components.
28. A computing device according to claim 20, further including eliminating redundant mappings to the same object, such that only one mapping exists from the single graphics API to that object for both 2D data and 3D data.
29. A computing device according to claim 20, wherein the specific function is a resolution change.
30. A computing device according to claim 29, wherein the single graphics API includes a single command to effect a resolution change, for presenting both 2D data and 3D data.
31. A computing device according to claim 20, wherein the specific function is memory management.
32. A computing device according to claim 31, wherein the single graphics API includes a single way to manage memory for both 2D data and 3D data.
33. A computing device according to claim 32, wherein the single way to manage memory includes a single way to allocate memory for both 2D data and 3D data.
34. A computing device according to claim 32, wherein the single way to manage memory includes formatting the data to the same memory structure for both 2D data and 3D data.
35. An application programming interface (API) comprising a single graphics API for both 2D and 3D graphics comprising a merged 2D graphics API and a 3D graphics API, wherein data types for the single graphics API apply to both 2D and 3D graphics, and whereby redundant function calls for performing a specific function are eliminated, such that only one function call for the specific function is utilized for both 2D data objects and 3D data objects.
The present invention provides a new and improved software interface as a layer between application developers and the graphics pipeline that renders and processes the graphics data.
For the vast majority of applications, application programmers rely on or utilize some form of software interface to interact with a computer and its associated devices. For graphics applications, developers or programmers typically utilize a graphics software interface, such as a 3D graphics application programming interface (API), to facilitate the interaction with constituent parts of a graphics system. Programmers typically rely on software interfaces to peripherals and devices so that they can focus on the specifics of their application rather than on the specifics of controlling a particular device and so that their efforts are not duplicated from application to application. However, even after generations of software interfaces, there are certain aspects of today's software interfaces that do not provide the level of performance desired and thus can be improved.
In view of the foregoing, the present invention provides a method and system for controlling the algorithmic elements in 3D graphics systems via an improved 3D graphics API. In one aspect, the invention unifies separately provided 2D and 3D graphics APIs into a single graphics interface, thereby eliminating redundancy of functionality and unnecessary data types. As a result, a single mapping to various graphics objects replaces redundant mappings. A single texture download that optimizes the use of different graphics hardware is provided. A single instruction for effecting a resolution change is provided.
The system and methods for controlling the algorithmic elements in 3D graphics systems are further described with reference to the accompanying drawings in which:
The present invention provides a new and improved API as a layer between application developers and the current state of the art of graphics hardware and the pipeline that renders and processes the graphics data. In recognition that current implementations of graphics API objects consist of two sets of processes that have evolved asynchronously and in parallel i.e., that 2D graphics APIs have evolved earlier and differently than 3D graphics APIs, a single unified set of graphics APIs is provided in accordance with the present invention for processing both 2D and 3D data objects. Due to the separate evolution of 2D and 3D APIs, there is overlapping or redundant functionality that exists from the perspective of the developer. For example, there are redundant mappings to various types of graphics systems objects. Similarly, there are currently too many ways to perform a texture download depending upon the hardware implicated. As a result, the developer is left with the task of optimizing a strategy for texture downloads. In accordance with the set of APIs of the present invention, a single way for performing a texture download is provided, wherein various ways of optimizing the hardware utilized in connection with the texture download are hidden from the developer. Additionally, while it previously required at least five instructions to effect a resolution change, the present invention enables a resolution change with a single instruction irrespective of whether the data being presented is a 2D data object or a 3D data object.
Computer 110 typically includes a variety of computer readable media. Computer readable media can be any available media that can be accessed by computer 110 and includes both volatile and nonvolatile media, removable and non-removable media. By way of example, and not limitation, computer readable media may comprise computer storage media and communication media. Computer storage media includes both volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CDROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can accessed by computer 110. Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term �modulated data signal� means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media Combinations of any of the above should also be included within the scope of computer readable media.
The computer 110 may also include other removable/non-removable, volatile/nonvolatile computer storage media By way of example only, FIG. 1 illustrates a hard disk drive 141 that reads from or writes to non-removable, nonvolatile magnetic media, a magnetic disk drive 151 that reads from or writes to a removable, nonvolatile magnetic disk 152, and an optical disk drive 155 that reads from or writes to a removable, nonvolatile optical disk 156, such as a CD ROM or other optical media. Other removable/non-removable, volatile/nonvolatile computer storage media that can be used in the exemplary operating environment include, but are not limited to, magnetic tape cassettes, flash memory cards, digital versatile disks, digital video tape, solid state RAM, solid state ROM, and the like. The hard disk drive 141 is typically connected to the system bus 121 through an non-removable memory interface such as interface 140, and magnetic disk drive 151 and optical disk drive 155 are typically connected to the system bus 121 by a removable memory interface, such as interface 150.
For example, while the creation, processing and rendering of 3D objects by a 3D API utilizes algorithms and function calls of the 2D API, a single set of APIs does not exist for the purpose of creating both 2D and 3D objects. There are thus typically multiple choices for a developer to make, when creating, processing or rendering an object, which makes the developer's work more complex. For example, with reference to FIG. 4A, there are numerous instances where the current 2D graphics API shares functionality with the current 3D graphics API, because, for example, both include the same function calls. There are also instances wherein to perform a function 410 a with the 3D graphics API 410 may involve a function call to function 400 a of the 2D graphics API, and vice versa. While the overlap in the figure is illustrated simply with dashed lines, the reality of current inter-operation is far from simple, and leaves the developer with too many choices. The present invention thus provides a single 2D and 3D graphics API, providing a unified programming body with which developers may work.
Currently, there are no 3D graphics APIs that unify 2D and 3D graphics data types. Historically, due to the evolution of 2D and 3D graphics processing, with �modem� 2D graphics applications beginning as early as the 1970s and with 3D graphics applications developing in parallel fashion at a later time, 2D and 3D data types have simply been treated differently by different applications i.e., memory allocation, memory structures and memory management have been different as between 2D and 3D data types. Thus, because the present invention unifies data types and choices with respect to 2D and 3D data types, memory management techniques have been unified in accordance with the present invention, eliminating ad hoc memory management based on whether the data was a 2D data type or a 3D data type. Due to the unification of 2D and 3D data formatting, the definition of data is simplified from the perspective of the developer. Thus, a long felt need in the art for a unified 2D and 3D API is addressed by the present invention.
Optimization of graphics components used incident to a texture download, such as hardware 430 a, 430 b, . . . 430 n, is thus performed by the API object 340_td in accordance with the present invention, thereby freeing the developer to be concerned with other aspects of the graphics application. For example, according to one optimization, the number of times used and order of hardware components 430 a, 430 b, etc. utilized in connection with a texture download is hidden from the developer. For example, in one embodiment, object 340_td keeps track of how well the hardware objects 430 a, 430 b, etc. are keeping up in terms of free memory (capacity) and speed of data processing and transfer. This may be configured statically beforehand, so as to control the number and order of hardware components 430 a, 430 b, etc. that may be used and in connection with a texture download, or this may be performed dynamically based upon an evaluation of the performance of texture downloading, with feedback from the hardware components 430 a, 430 b, etc.
In addition, there are a number of instances in which existing 3D graphics APIs inconvenience the developer by requiring the developer to write substantially more complex code than is necessary in view of today's computing environments. For example, currently it requires at least five programming steps to effect a resolution change, inconveniencing the developer each time a resolution change is desired. While coding five steps is still better than interfacing directly with graphics system components, the present invention unifies the command structure of a resolution change, allowing a developer to effect a resolution change with a single API command. The present invention thus provides a single command to effect a resolution change, insulating the developer from the detailed changes that are made in the graphics system in order to effect the change. This is yet another example where current graphics APIs require the developer to have an overly detailed understanding of the underlying graphics hardware. As shown in FIG. 4D, there are currently five steps or commands 340_rc1 , 340_rc2, 340_rc3, 340_rc4 and 340_rc5 that a developer D1 must enter in order to effect a graphics system resolution change RC. Each of commands 340_rc1, 340_rc2, 340_rc3, 340_rc4 and 340_rc5 has an independent bearing on the graphics system which can involve overlapping functionality or redundant arguments. Thus, as FIG. 4E illustrates, the present invention provides a single efficient API object 340_rc to achieve a resolution change. Thus, in these and other instances, the present invention unifies existing API command structures into concrete, atomic algorithmic elements that ease the task of development for a developer.
Thus, by way of the API of the present invention, 3D algorithmic elements written by a developer can be downloaded to the 3D chip for improved performance characteristics. FIG. 5 illustrates this process whereby a developer D1 writes a routine 500 that may be downloaded to 3D graphics chip 510. Similar to this case where a developer may write a routine 500 downloadable to the 3D chip 510, there are also a set of algorithmic elements that are provided in connection with the API of the present invention (routines that do not have to be written by developer D1, but which have already been programmed for the developer D1), that are downloadable to the programmable chip 510 for improved performance. As shown in sit FIG. 5, a developer D1 may download preexisting API objects 340 a, 340 b, . . . 340 n to 3D graphics chip 510. While graphics applications generally involve a performance specification that includes fast processing and fast rendering, the ability to control 3D algorithmic elements in this fashion is very advantageous, because it allows a developer access to the fastest, highest performance portions of the graphics processing system, enabling the developer to download efficient algorithmic elements to the graphics chip 510 that are tailored to the application at hand.
In an exemplary embodiment, a developer adheres to a specific format for packing up an algorithmic element, or set of instructions, for implementation by a 3D graphics chip. The developer packs the instruction set into an array of numbers, by referring to a list of �tokens� understood by the 3D graphics chip. This array of numbers in turn is mapped correctly to the 3D graphics chip for implementation of the algorithmic element by the 3D graphics chip. Further background, hereby incorporated by reference in its entirety, may be found in U.S. Patent Appln. entitled �API Communications For Vertex And Pixel Shaders� having inventors Boyd and Toelle (Attorney Docket No. MSFT-0238).
Thus, with previous 3D APIs, the API did not provide the developer with flexibility as to operations that could be performed in connection with procedural shaders, such as vertex and pixel shaders. Vertex and pixel shaders, which may be implemented with software or in hardware or with a combination of both, have specialized functionality. Currently, in order to utilize useful algorithmic elements of a procedural shader, or otherwise use fixed and limited functionality of the procedural shader, a developer has to invariably design software procedural shader algorithms from scratch for each application. While the core commands for use with the procedural shaders were available to the developer, the effective or efficient combination of these commands is left to the developer. Consequently, algorithms that are unique, common and useful in connection with typical 3D graphics processes, such as for typical use in connection with procedural shaders, are developed from the ground up for each application. Conceptually, these elements for acting on procedural shaders have been customized by necessity for each application and thus provided �above� the API, programmed asp as part of the graphics application itself. As shown in FIG. 6A, developer D1, with access to a specification for a procedural shader 610, programs an inflexible object 600 so as to work with or control the procedural shader 610. As FIG. 6A illustrates, developer D1 develops a shading algorithm with code. After customization by the developer D1, object 600 interacts with shader(s) 610 via graphics API 340.
[28:00] 0x1ffffff
Stream Select: streamer=0
Stream Data Definition (Load): type=FLOAT7; register=7
typedef enum _D3DVSD_TOKENTYPE
D3DVSD_TOKEN_NOP = 0,
// NOP or extension
D3DVSD_TOKEN_STREAM,
// stream selector
D3DVSD_TOKEN_STREAMDATA,
// stream data definition (map to vertex input
D3DVSD_TOKEN_TESSELLATOR,
// vertex input memory from tessellator
D3DVSD_TOKEN_CONSTMEM,
// constant memory from shader
D3DVSD_TOKEN_EXT,
D3DVSD_TOKEN_END = 7,
// end-of-array (requires all DWORD bits to be 1)
#define D3DVSD_TOKENTYPESHIFT
#define D3DVSD_TOKENTYPEMASK (7 << D3DVSD_TOKENTYPESHIFT)
#define D3DVSD_STREAMNUMBERSHIFT
#define D3DVSD_DATALOADTYPESHIFT
#define D3DVSD_DATATYPESHIFT
#define D3DVSD_DATATYPEMASK (0xF << D3DVSD_DATATYPESHIFT)
#define D3DVSD_SKIPCOUNTSHIFT
#define D3DVSD_SKIPCOUNTMASK (0xF << D3DVSD_SKIPCOUNTSHIFT)
#define D3DVSD_VERTEXREGSHIFT
#define D3DVSD_VERTEXREGMASK (0x1F << D3DVSD_VERTEXREGSHIFT)
#define D3DVSD_VERTEXREGINSHIFT
#define D3DVSD_VERTEXREGINMASK (0xF << D3DVSD_VERTEXREGINSHIFT)
#define D3DVSD_CONSTCOUNTSHIFT
#define D3DVSD_CONSTCOUNTMASK (0xF << D3DVSD_CONSTCOUNTSHIFT)
#define D3DVSD_CONSTADDRESSSHIFT
#define D3DVSD_CONSTRSSHIFT
#define D3DVSD_CONSTRSMASK (0x1FFF << D3DVSD_CONSTRSSHIFT)
#define D3DVSD_EXTCOUNTSHIFT
#define D3DVSD_EXTCOUNTMASK (0x1F << D3DVSD_EXTCOUNTSHIFT)
#define D3DVSD_EXTINFOSHIFT
#define D3DVSD_EXTINFOMASK (0xFFFFFF << D3DVSD_EXTINFOSHIFT)
#define D3DVSD_STREAM(_StreamNumber)\
(D3DVSD_MAKETOKENTYPE(D3DVSD_TOKEN_STREAM) | (_StreamNumber))
#define D3DVSD_STREAMTESSSHIFT
#define D3DVSD_STREAMTESSMASK (1 << D3DVSD_STREAMTESSSHIFT)
#define D3DVSD_STREAM_TESS( )\
#define D3DVSD_REG(_VertexRegister, _Type)\
(D3DVSD_MAKETOKENTYPE(D3DVSD_TOKEN_STREAMDATA)|
// Skip_DWORDCount DWORDs in vertex
#define D3DVSD_SKIP(_DWORDCount)\
(D3DVSD_MAKETOKENTYPE(D3DVSD_TOKEN_STREAMDATA) | 0x10000000|\
#define D3DVSD_CONST(_ConstantAddress, _Count)\
((_Count) << D3DVSD_CONSTCOUNTSHIFT) | (_ConstantAddress))
will be used in normal computation
#define D3DVSD_TESSNORMAL(_VertexRegisterIn, _VertexRegisterOut) \
((_VertexRegisterIn) << D3DVSD_VERTEXREGINSHIFT)|\
#define D3DVSD_TESSUV(_VertexRegister)\
(D3DVSD_MAKETOKENTYPE(D3DVSD_TOKEN_TESSELLATOR) | 0x10000000|\
#define D3DVSDT_FLOAT1
// 1D float expanded to (value, 0.,
#define D3DVSDT_FLOAT2
// 2D float expanded to (value, value,
#define D3DVSDT_FLOAT3
// 3D float expanded to (value, value,
value, 1.)
#define D3DVSDT_FLOAT4
// 4D float
#define D3DVSDT_D3DCOLOR
// 4D packed unsigned bytes mapped to
0. to 1. range
#define D3DVSDT_UBYTE4
// 4D unsigned byte
#define D3DVSDT_SHORT2
// 2D signed short expanded to (value,
#define D3DVSDT_SHORT4
// 4D signed short
#define D3DVSDE_POSITION
#define D3DVSDE_BLENDWEIGHT
#define D3DVSDE_BLENDINDICES
#define D3DVSDE_NORMAL
#define D3DVSDE_PSIZE
#define D3DVSDE_DIFFUSE
#define D3DVSDE_SPECULAR
#define D3DVSDE_TEXCOORD0
#define D3DVSDE_TEXCOORD1
#define D3DVSDE_TEXCOORD2
#define D3DVSDE_TEXCOORD3
#define D3DVSDE_TEXCOORD4
#define D3DVSDE_TEXCOORD5
#define D3DVSDE_TEXCOORD6
#define D3DVSDE_TEXCOORD7
#define D3DVSDE_POSITION2
#define D3DVSDE_NORMAL2
#define D3DDP_MAXTEXCOORD
PS 0xFFFF
VS 0xFFFE
// [30:16] DWORD Length (up to 2{circumflex over ( )}15 DWORDS = 128KB)
[16] Component 0 (X;Red)
[17] Component 1 (Y;Green)
[18] Component 2 (Z;Blue)
[19] Component 3 (W;Alpha)
PS Result Modifier
VS Reserved 0x0
PS Result Shift Scale (signed shift)
[0x0] Temporary Register File
[0x1] Reserved
[0x2] Reserved
[0x3]
VS Address Register (reg num must be zero)
PS Reserved
[0x4]
VS Rasterizer Output Register File
[0x5]
VS Attribute Output Register File
VS Texture Coordinate Register File
[0x7] Reserved
// **** Source Parameter Token *****
VS Relative Address
PS Reserved 0x0
VS Relative Address Register Component
[17:16] Component 0 Swizzle
[19:18] Component 1 Swizzle
[21:20] Component 2 Swizzle
[23:22] Component 3 Swizzle
[0x0] None
[0x1] Negate
[0x2] Bias
[0x3] Bias and Negate
[0x4] Sign
[0x5] Sign and Negate
[0x6] Complement
[0x7-0xf] Reserved
[0x1] Input Register File
[0x2] Constant Register File
[0x3-0x7] Reserved
#define D3DSI_OPCODE_MASK
typedef enum _D3DSHADER_INSTRUCTION_OPCODE_TYPE
D3DSIO_NOP = 0,
// PS/VS
D3DSIO_MOV,
D3DSIO_ADD,
D3DSIO_SUB,
D3DSIO_MAD,
D3DSIO_MUL,
D3DSIO_RCP,
D3DSIO_RSQ,
D3DSIO_DP3,
D3DSIO_DP4,
D3DSIO_MIN,
D3DSIO_MAX,
D3DSIO_SLT,
D3DSIO_SGE,
D3DSIO_EXP,
D3DSIO_LOG,
D3DSIO_LIT,
D3DSIO_DST,
D3DSIO_LRP,
D3DSIO_FRC,
D3DSIO_M4x4,
D3DSIO_M4x3,
D3DSIO_M3x4,
D3DSIO_M3x3,
D3DSIO_M3x2,
D3DSIO_TEXCOORD = 64,
D3DSIO_TEXKILL,
D3DSIO_TEX,
D3DSIO_TEXBEM,
D3DSIO_TEXBEML,
D3DSIO_TEXREG2AR,
D3DSIO_TEXREG2GB,
D3DSIO_TEXM3x2PAD,
D3DSIO_TEXM3x2TEX,
D3DSIO_TEXM3x3PAD,
D3DSIO_TEXM3x3TEX,
D3DSIO_TEXM3x3DIFF,
D3DSIO_TEXM3x3SPEC,
D3DSIO_TEXM3x3VSPEC,
D3DSIO_EXPP,
D3DSIO_LOGP,
D3DSIO_CND,
D3DSIO_DEF,
D3DSIO_RESERVED0 = 96,
D3DSIO_RESERVED1,
D3DSIO_RESERVED2,
D3DSIO_RESERVED3,
D3DSIO_FORCE_DWORD = 0x7fffffff,
// force 32-bit size enum
#define D3DSI_COISSUE
#define D3DSP_REGNUM_MASK
#define D3DSP_WRITEMASK_0
// Component 0 (X;Red)
#define D3DSP_WRITEMASK_1
// Component 1 (Y;Green)
#define D3DSP_WRITEMASK_2
// Component 2 (Z;Blue)
#define D3DSP_WRITEMASK_3
// Component 3 (W;Alpha)
#define D3DSP_WRITEMASK_ALL
// All Components
#define D3DSP_DSTMOD_SHIFT
#define D3DSP_DSTMOD_MASK
0x00F00000
typedef enum _D3DSHADER_PARAM_DSTMOD_TYPE
D3DSPDM_SATURATE= 1<<D3DSP_DSTMOD_SHIFT, // clamp to 0. to 1. range
D3DSPDM_FORCE_DWORD = 0x7fffffff,
#define D3DSP_DSTSHIFT_SHIFT
#define D3DSP_DSTSHIFT_MASK
0x0F000000
#define D3DSP_REGTYPE_SHIFT
#define D3DSP_REGTYPE_MASK
0x70000000
D3DSPR_TEMP = 0<<D3DSP_REGTYPE_SHIFT, // Temporary Register File
D3DSPR_INPUT = 1<<D3DSP_REGTYPE_SHIFT, // Input Register File
D3DSPR_CONST = 2<<D3DSP_REGTYPE_SHIFT, // Constant Register File
D3DSPR_ADDR = 3<<D3DSP_REGTYPE_SHIFT, // Address Register (VS)
D3DSPR_TEXTURE = 3<<D3DSP_REGTYPE_SHIFT, // Texture Register File
D3DSPR_RASTOUT = 4<<D3DSP_REGTYPE_SHIFT, // Rasterizer Register File
D3DSPR_ATTROUT = 5<<D3DSP_REGTYPE_SHIFT, // Attribute Output Register
D3DSPR_TEXCRDOUT=6<<D3DSP_REGTYPE_SHIFT, // Texture Coordinate Output
D3DSPR_FORCE_DWORD = 0x7fffffff,
typedef enum _D3DVS_RASTOUT_OFFSETS
D3DSRO_FORCE_DWORD = 0x7fffffff,
#define D3DVS_ADDRESSMODE_SHIFT
#define D3DVS_ADDRESSMODE_MASK
(1 << D3DVS_ADDRESSMODE_SHIFT)
D3DVS_ADDRMODE_ABSOLUTE = (0 << D3DVS_ADDRESSMODE_SHIFT),
D3DVS_ADDRMODE_RELATIVE = (1 << D3DVS_ADDRESSMODE_SHIFT), //
Relative to register A0
D3DVS_ADDRMODE_FORCE_DWORD = 0x7fffffff, // force 32-bit size enum
#define D3DVS_SWIZZLE_SHIFT
#define D3DVS_SWIZZLE_MASK
#define D3DVS_X_X
(0 << D3DVS_SWIZZLE_SHIFT)
#define D3DVS_X_Y
(1 << D3DVS_SWIZZLE_SHIFT)
#define D3DVS_X_Z
(2 << D3DVS_SWIZZLE_SHIFT)
#define D3DVS_X_W
(3 << D3DVS_SWIZZLE_SHIFT)
#define D3DVS_Y_X
(0 << (D3DVS_SWIZZLE_SHIFT + 2))
#define D3DVS_Y_Y
(1 << (D3DVS_SWIZZLE_SHIFT + 2))
#define D3DVS_Y_Z
(2 << (D3DVS_SWIZZLE_SHIFT + 2))
#define D3DVS_Y_W
(3 << (D3DVS_SWIZZLE_SHIFT + 2))
#define D3DVS_Z_X
(0 << (D3DVS_SWIZZLE_SHIFT + 4))
#define D3DVS_Z_Y
(1 << (D3DVS_SWIZZLE_SHIFT + 4))
#define D3DVS_Z_Z
(2 << (D3DVS_SWIZZLE_SHIFT + 4))
#define D3DVS_Z_W
(3 << (D3DVS_SWIZZLE_SHIFT + 4))
#define D3DVS_W_X
(0 << (D3DVS_SWIZZLE_SHIFT + 6))
#define D3DVS_W_Y
(1 << (D3DVS_SWIZZLE_SHIFT + 6))
#define D3DVS_W_Z
(2 << (D3DVS_SWIZZLE_SHIFT + 6))
#define D3DVS_W_W
(3 << (D3DVS_SWIZZLE_SHIFT + 6))
#define D3DVS_NOSWIZZLE (D3DVS_X_X | D3DVS_Y_Y | D3DVS_Z_Z |
D3DVS_W_W)
#define D3DSP_SWIZZLE_SHIFT
#define D3DSP_SWIZZLE_MASK
#define D3DSP_NOSWIZZLE\
( (0 << (D3DSP_SWIZZLE_SHIFT + 0)) |\
(1 << (D3DSP_SWIZZLE_SHIFT + 2)) |\
(2 << (D3DSP_SWIZZLE_SHIFT + 4)) |\
( (3 << (D3DSP_SWIZZLE_SHIFT + 0)) |\
(3 << (D3DSP_SWIZZLE_SHIFT + 2)) |\
(3 << (D3DSP_SWIZZLE_SHIFT + 4)) |\
#define D3DSP_SRCMOD_SHIFT
#define D3DSP_SCRMOD_MASK
typedef enum _D3DSHADER_PARAM_SRCMOD_TYPE
D3DSPSM_NONE = 0<<D3DSP_SRCMOD_SHIFT, // nop
D3DSPSM_NEG = 1<<D3DSP_SRCMOD_SHIFT, // negate
D3DSPSM_BIAS = 2<<D3DSP_SRCMOD_SHIFT, // bias
D3DSPSM_BIASNEG = 3<<D3DSP_SRCMOD_SHIFT, // bias and negate
D3DSPSM_SIGN = 4<<D3DSP_SRCMOD_SHIFT, // sign
D3DSPSM_SIGNNEG = 5<<D3DSP_SRCMOD_SHIFT, // sign and negate
D3DSPSM_COMP = 6<<D3DSP_SRCMOD_SHIFT, // complement
D3DSPSM_FORCE_DWORD = 0x7fffffff, // force 32-bit size enum
#define D3DPS_VERSION(_Major,_Minor) (0xFFFF0000|((_Major)<<8)|(_Minor))
#define D3DVS_VERSION(_Major,_Minor) (0xFFFE0000|((_Major)<<8)|(_Minor))
#define D3DSHADER_VERSION_MAJOR(_Version) (((_Version)8)&0xFF)
#define D3DSHADER_VERSION_MINOR(_Version) (((_Version)0)&0xFF)
#define D3DSI_COMMENTSIZE_SHIFT
#define D3DSI_COMMENTSIZE_MASK
0x7FFF0000
((((_DWordSize)<<D3DSI_COMMENTSIZE_SHIFT)&D3DSI_COMMENTSIZE_MASK)|
D3DSIO_COMMENT)
#define D3DPS_END( )
#define D3DVS_END( )
As mentioned above, while direct video memory access was once a possibility, it is no longer a possibility according to today's currently utilized graphics architectures. In accordance with today's graphics pipeline architecture, specialized or private drivers and surface formats are used in connection with very fast graphics accelerators. With direct rasterizer/processor access to display memory surfaces, �chunks� of surfaces can be moved around according to the specialized surface format, and pulled for processing as efficiency dictates. Thus, the pipeline between display memory surface space and the display itself has been made more efficient. With reference to FIG. 7A, an example of the type of modern �chunk� manipulation is illustrated at a microcosmic level i.e., only 4 squares or chunks of data are illustrated. Private driver 700 causes chunks 710 a_1 through 710 a_4 to be grabbed as efficiency dictates and are subsequently manipulated with a rasterizer into an intermediate form 710 b, wherein the original image may be unrecognizable. Then, data is moved along the graphics pipeline to render the final image on display 710 c, whereby band B_1 of data may translate to band B_2 in the displayed image. These mathematical transformations, and timing thereof, have advanced algorithms for determining the efficiency of chunk grabbing and placement. In essence, many images involve redundant data, or data that can be exploited based upon temporal and spatial knowledge, and these algorithms exploit such knowledge to create an extremely efficient and fast graphics data rendering pipeline.
There are also current issues with respect to the transmission of data containers 850, either pixel and polygon, to a 3D chip. Currently, when a developer goes about specifying multiple data objects to fill multiple containers, these data objects are fed to the 3D chip one by one, or in a serial fashion. As illustrated in FIG. 9A, currently, to feed two data containers 850 a and 850 b to graphics chip memory 810, developer D1 must feed the objects serially to memory 810. In the figure, t1<t2. At t1, container 850 a is retrieved from wherever stored or is created and at t2, it is fed to 3D graphics chip memory 810. In a typical representation of a pixel with eight bits, x, y, z and w may be utilized for the spatial position of the pixel and four more o1, o2, o3 and o4 may be utilized to represent the orientation of the surface, or color etc. at that position. When the position and location of graphics data is constantly changing, serial transmission or loading of graphics chip memory may not reduce performance significantly. However, when there is redundancy of data e.g., when only the orientation of a pixel changes while the spatial position stays the same, opportunity to exploit the redundancy is lost. Thus, serialized data in container 850 a is fed to 3D graphics chip memory 810 is fed to 3D graphics chip memory 810. As will become evident, Even when performed very fast, the serial transmission of data containers 850 a and 850 b is not as fast as a parallel transmission when there is some redundancy or other reason to transmit data in parallel.
Patent CitationsCited PatentFiling datePublication dateApplicantTitleUS4805098May 5, 1986Feb 14, 1989Mips Computer Systems, Inc.Write bufferUS4953073Feb 6, 1986Aug 28, 1990Mips Computer Systems, Inc.Cup chip having tag comparator and address translation unit on chip and connected to off-chip cache and main memoriesUS4959779Nov 28, 1988Sep 25, 1990Mips Computer Systems, Inc.Dual byte order computer architecture a functional unit for handling data sets with differnt byte ordersUS5027270Oct 11, 1988Jun 25, 1991Mips Computer Systems, Inc.Processor controlled interface with instruction streamingUS5394524 *Nov 30, 1992Feb 28, 1995International Business Machines CorporationMethod and apparatus for processing two graphics data streams in parallelUS5398328Sep 27, 1993Mar 14, 1995Silicon Graphics, Inc.System for obtaining correct byte addresses by XOR-ING 2 LSB bits of byte address with binary 3 to facilitate compatibility between computer architecture having different memory ordersUS5590294May 24, 1995Dec 31, 1996Silicon Graphics, Inc.Method of processing instructions by a processorUS5673377Sep 2, 1994Sep 30, 1997Ray Dream, Inc.Method and system for displaying a representation of a three-dimensional object with surface features that conform to the surface of the three-dimensional objectUS5801717Apr 25, 1996Sep 1, 1998Microsoft CorporationMethod and system in display device interface for managing surface memoryUS5812136Oct 30, 1996Sep 22, 1998Microsoft CorporationSystem and method for fast rendering of a three dimensional graphical objectUS5822570Oct 30, 1996Oct 13, 1998Microsoft CorporationIn a computer systemUS5835096 *May 1, 1996Nov 10, 19983D LabsRendering system using 3D texture-processing hardware for accelerated 2D renderingUS5844569Apr 25, 1996Dec 1, 1998Microsoft CorporationDisplay device interface including support for generalized flipping of surfacesUS5850232Apr 25, 1996Dec 15, 1998Microsoft CorporationIn a computer systemUS5864703Oct 9, 1997Jan 26, 1999Mips Technologies, Inc.Method for providing extended precision in SIMD vector arithmetic operationsUS5964843Apr 25, 1996Oct 12, 1999Microsoft CorporationSystem for enhancing device driversUS6008816Apr 25, 1996Dec 28, 1999Microsoft CorporationMethod and system for managing color specification using attachable palettes and palettes that refer to other palettesUS6044408 *Apr 25, 1996Mar 28, 2000Microsoft CorporationMultimedia device interface for retrieving and exploiting software and hardware capabilitiesUS6081270 *Jan 27, 1997Jun 27, 2000International Business Machines CorporationMethod and system for providing an improved view of an object in a three-dimensional environment on a computer displayUS6208347 *Jun 23, 1997Mar 27, 2001Real-Time Geometry CorporationSystem and method for computer modeling of 3D objects and 2D images by mesh constructions that incorporate non-spatial data such as color or textureUS6208361 *Jun 15, 1998Mar 27, 2001Silicon Graphics, Inc.Method and system for efficient context switching in a computer graphics systemUS6215495 *May 30, 1997Apr 10, 2001Silicon Graphics, Inc.Platform independent application program interface for interactive 3D scene managementUS6252600 *Oct 2, 1998Jun 26, 2001International Business Machines CorporationComputer graphics system with dual FIFO interfaceUS6289396 *Nov 21, 1995Sep 11, 2001Diamond Multimedia Systems, Inc.Dynamic programmable mode switching device driver architecture* Cited by examinerNon-Patent CitationsReference1Abrash, M., "Inside Xbox Graphics," Dr. Dobb's J., Aug., 2000, 21-22, 24-26.2Antinori, F. et al., "Experience with a 30 cm<2 >silicon pixel plane in CERN experiment WA97," Nucl. Instr. Meth. Phys. Res. A., 1995, 360, 91-97.3Antinori, F. et al., "Experience with a 30 cm2 silicon pixel plane in CERN experiment WA97," Nucl. Instr. Meth. Phys. Res. A., 1995, 360, 91-97.4Bachstein, W. et al., "Single-Chip erledigt Multimedia," Elektronik, 1996, 17, 58-62.5Bajaj, C. et al., "Making 3D Textures Practical," IEEE: Proceedings-Seventh Pacific Conference on Computer Graphics and Applications, Oct. 5-7, 1999, 259-269.6Bakalash, R. et al., "A Barrel Shift Microsystem for Parallel Processing," in MICRO 23 Microprogramming and Microarchitecture, IEEE: Proceedings of the 23<rd >Workshop and Symposium, Orlando Florida, Nov. 27-29, 1990, 223-229.7Bakalash, R. et al., "A Barrel Shift Microsystem for Parallel Processing," in MICRO 23 Microprogramming and Microarchitecture, IEEE: Proceedings of the 23rd Workshop and Symposium, Orlando Florida, Nov. 27-29, 1990, 223-229.8Bankston, J. et al., "Pipeline Processing with Modula-2," J. Pascal, Ada, & Modula-2, 1986, 5(5), 46-51.9Biernat, M.J. et al., "Approximate Shadow Generation," IEEE Montech Conferences, Nov. 9-12, 1987, 97-101.10Brechb�hler, Ch. et al., "Parametrization of Closed Surfaces for 3-D Shape Description," Comp. Vision Image Understanding, Mar., 1995, 61(2), 154-170.11Chen, Li, "Generalization Discrete Object Tracking Algorithms and Implementation," in Vision Geometry VI, Proceedings of SPIE, Melter, R.A. et al. (eds.), Jul. 28-29, 1997, 3168, 184-195.12Chiarulli, D.M. et al., "Draft: A Dynamically Reconfigurable Processor for Integer Arithmetic," IEEE: Proceedings-7<th >Symposium on Computer Arithmetic, University of Illinois, Hwang, K. (ed.), Jun. 4-6, 1985, 309-317.13Chiarulli, D.M. et al., "Draft: A Dynamically Reconfigurable Processor for Integer Arithmetic," IEEE: Proceedings-7th Symposium on Computer Arithmetic, University of Illinois, Hwang, K. (ed.), Jun. 4-6, 1985, 309-317.14Conference Paper, "A Shading and Compositing Processor based on Crossbar Switches and SRAM Memory," 1999, 4 pages.15Cox, M. et al., "Multi-Level Texture Caching for 3D Graphics Hardware," IEEE: Proceedings-The 25<th >Annual International Symposium on Computer Architecture, Barcelona, Spain, Jun. 27-Jul. 1, 1998, 86-97.16Cox, M. et al., "Multi-Level Texture Caching for 3D Graphics Hardware," IEEE: Proceedings-The 25th Annual International Symposium on Computer Architecture, Barcelona, Spain, Jun. 27-Jul. 1, 1998, 86-97.17Dietz, P.H. et al., "Simple Networks for Pixel Plane Median Filtering," IEEE Transactions on Circuits and Systems-II: Analog and Digital Signal Processing, Dec., 1993, 40(12), 799-801.18Gomes, J. et al., "Graphical Objects," The Visual Computer, 1996, 12, 269-282.19Gordon, R.L., Ph.D. et al., Window Management, Graphics, and Operating Systems, Operating Systems Review, Jul., 1987, 21(3), 5-8.20Goris, A. et al., "A Configurable Pixel Cache for Fast Image Generation," IEEE Computer Graphics and Applications, Mar., 1987, 24-32.21Grimes, J. et al., "A New Processor with 3-D Graphics Capabilities," NCGA '89 Conference Proceedings: 10<th >Annual Conference and Exposition Dedicated to Computer Graphics, Philadelphia, Pennsylvania, Apr. 17-20, 1989, vol. 1, 275-284.22Grimes, J. et al., "The Intel i860 64-Bit Processor: A General-Purpose CPU with 3D Graphics Capabilities," IEEE Computer Graphics and Applications, Jul., 1989, 85-94.23Grimes, J. et al., "A New Processor with 3-D Graphics Capabilities," NCGA '89 Conference Proceedings: 10th Annual Conference and Exposition Dedicated to Computer Graphics, Philadelphia, Pennsylvania, Apr. 17-20, 1989, vol. 1, 275-284.24Haig, T., "How to program in machine language," Electronics, Aug., 1982, 94-96, 98, 100-103.25Harrison, J.P. et al., "The Role of Microcomputers in Interactive Graphical Planning," Engin. Software for Microcomputers, Proc., Apr., 1984, 631-641.26Ho, C-H et al., "Efficient Point-Based Rendering Techniques for Haptic Display of Virtual Objects," Presence, Oct., 1999, 8(5), 477-491.27Hoffman, C. et al., "Automatic Surface Generation in Computer Aided Design," supported by the National Science Foundation, Department of Computer Science, Cornell University, Ithaca, New York, Jan., 1985, 1-22.28Hummel, R., "Render Benders: 26 Graphics Cards for Fast 3-D," Byte, Mar., 1998, 112-119.29James, M., "3-D graphics to become accessible to all," Scientific Computing World, Feb., 1997, 41 and 43.30Johnson, S.P., "Direct3D Revealed: Microsoft's 3-D API provides device-independent access to acceleration hardware. Here's how it works," Core Technologies, http://byte.com/art/9612/sec5/art4.htm, Dec. 1996, 5 pages.31Jones, M. et al., "High-Performance Graphics Via Silicon Compilation," VLSI Systems Design, Mar., 1987, 32, 33, 36 and 38.32Kaya, E.M., "New Trends in Graphic Display System Architecture," in Frontiers in Computer Graphics, Proceedings of Computer Graphics, Tokyo '84, Kunii, T.L. (ed.), 1985, 310-320.33Kumar, S. et al., "Efficient rendering of trimmed NURBS surfaces," Computer-Aided Disign, Jul., 1995, 27(7), 509-521.34Labsik, U. et al., "Progressive transmission of subdivision surfaces," Computational Geometry, 2000, 15, 25-39.35Lachaud, J-O. et al., "Continuous Analogs of Digital Boundaries: A Topological Approach to Iso-Surfaces," Graphical Models, 2000, 62, 129-164.36Lapidous, E. et al., "Optimal Depth Buffer for Low-Cost Graphics Hardware," Trident Microsystems, Inc., 1999, 67-73.37Lastra, A. et al., "Real-Time Programmable Shading," Proceedings: 1995 Symposium on Interative 3D Graphics, Monterey, California, Apr. 9-12, 1995, 59-66.38Lee, J-A. et al., "SPARP: a single pass antialiased rasterization processor," Comput. & Graphics, 2000, 24, 233-243.39Lichten, L., "A Solution to Surface Connectivity Problems in Computer-Aided Design," Computer Graphics, Mar., 1981, 14(4), 168-199.40Mabin, F.H. et al., "A Parallel Algorithm to Reconstruct Bounding Surfaces in 3D Images," J. Supercomputing, 1998, 12, 137-155.41McManus, D. et al., "Optimal Static 2-Dimensional Screen Subdivision for Parallel Rasterization Architectures," Comput. & Graphics, 1997, 21(2), 159-169.42Meyers, D. et al., "Surfaces from Contours," ACM Transactions on Graphics, Jul. 1992, 11(3), 228-258.43Micikevicius, P. et al., "Teaching a Computer Graphics Class Using DirectX," J. Comput. in Small Colleges: Proceedings of the Ninth Annual CCSC South Central Conference, (Jackson, Mississippi, Apr. 17-18), Meinke, J.G. (ed.), Mar., 1998, 13(4), 61-66.44Nishimura, H. et al., "A Multicomputer System Links: Its Architecture and Graphics Applications," IECON '84: International Conference on Industrial Electronics Control and Instrumentation, Tokyo, Japan, Oct. 22-26, 1984, 1, 270-274.45NVIDIA Corporation, "System Platform Porcessor (SPP) / Integrated Graphics Processor (IGP): Redefnining System and Graphics Performance," nForce SPP/IGP Product Overview, Jan., 2002, Version 1, 2 pages.46NVIDIA Corporation, "Technical Brief: NVIDIA nfiniteFX II Engine From Research to Real Time," Jan. 16, 2002, 7 pages.47NVIDIA Corporation, "Technical Brief: NVIDIA nForce Platform Processing Architecture," 2001, 1-9.48Ohbuchi, R. et al., "Embedding Data in 3D Models," in Interactive Distributed Multimedia Systems and Telecommunication Services, 4<th >International Workshop, IDMS '97, Darmstadt, Germany, Sep. 10-12, 1997, 1-10.49Ohbuchi, R. et al., "Embedding Data in 3D Models," in Interactive Distributed Multimedia Systems and Telecommunication Services, 4th International Workshop, IDMS '97, Darmstadt, Germany, Sep. 10-12, 1997, 1-10.50Ohhashi, M. et al., "A 32b 3-D Graphic Processor Chip with 10M Pixels/s Gouraud Shading," 1998 IEEE International Solid-State Circuits Conference Digest of Technical Papers, Feb., 1988, 168-169, and 352.51Rowlan, J.S. et al., "A distributed, parallel, interactive volume rendering package," IEEE: Proceedings-Visualization '94, Washington, D.C., Oct. 17-21, 1994, 21-30.52Schneider, B-O. et al., "An adaptive framework for 3D graphics over networks," Comput. & Graphics, 1999, 23, 867-874.53Schneider, B-O. et al., "M-Buffer: A Flexible MISD Architecture for Advanced Graphics," Comput. & Graphics, 1995, 19(2), 239-246.54Senthinathan, R. et al., "A 650-MHz, IA-32 Microprocessor with Enhanced Data Streaming for Graphics and Video," IEEE J. Solid-State Circuits, Nov., 1999, 34(11), 1454-1465.55Shinya, M., "Improvements on the Pixel-tracing Filter: Reflection/Refraction, Shadows, and Jittering," Proceedings: Graphics Interface '95, May 7-19, 1995, 92-102.56Shirali, N.S. et al., "A Parallel Architecture Graphics Processor," IEEE Southeastcon: Conference Proceedings, Knoxville, Tennessee, Apr. 11-13, 1998, 108-111.57Smith, D.R. et al., "A Circuit-Switched Shared-Memory Multiprocessor," International J. Mini Microcomputers, 1995, 17(3), 108-118.58Sussman, H. et al., "Graphics Memory Architectures," Wescon/86 Conference Record, 1986, 1-6.59Swanson, R.W. et al., "A Fast Shaded-Polygon Rendered," Computer Graphics, Aug., 1986, 20(4), 95-101.60Teonnies, K.D. et al., "Volume rendering for interactive 3-d segmentation," in Image Display, Proceeding of SPIE, Newport Beach, California, Feb. 23-25, 1997, 3031, 602-609.61Thompson, T., "An inside look at the most popular 3-D environments: OpenGL, QuickDraw3D, and Direct 3D," Must-See 3-D Engines, Jun., 1996, http://byte.com/art/9606/sec11/art4.htm, 7 pages.62Thompson, T., "Direct3D's Engine," Must-See 3-D Engines, Jun., 1996, http://byte.com/art/9606/sec11/art7.htm, 1 page.63Thompson, T., "Open GL's Command Structure," Must-See 3-D Engines, Jun., 1996, http://byte.com/art/9606/sec11/art5.htm, 1 page.64Thompson, T., "QuickDraw 3D's Command Structure," Must-See 3-D Engines, Jun., 1996, http://byte.com/art/9606/sec11/art6.htm, 1 page.65Thompson, T., "Three Ways to Tackle Multithreading," Must-See 3-D Engines, Jun., 1996, http://byte.com/art/9606/sec11/art8.htm, 1 page.66Wilson, J.L. et al., "Designing a Graphics Application Interface," Proceedings Graphics Interface '85, Montreal, Quebec, May 27-31, 1985, 373-380.67Yoshida, M. et al., "Trend of the computer graphics hardware," Information Processing Soc. of Japan, Oct., 1988, 29(10), 1109-1115.68Zheng, Y. et al. , "Three-dimensional unstructured mesh generation: Part 2. Surface meshes," Comput. Methods Appl. Mech. Engrg., 1996, 134, 269-284.Referenced byCiting PatentFiling datePublication dateApplicantTitleUS7487516 *Aug 1, 2005Feb 3, 2009Nvidia CorporationDesktop composition for incompatible graphics applicationsUS7908178Jul 31, 2009Mar 15, 2011Paul NykampMethods for interactive and synchronous displaying sessionUS7999807Dec 12, 2005Aug 16, 2011Microsoft Corporation2D/3D combined renderingUS8004515 *Mar 15, 2005Aug 23, 2011Nvidia CorporationStereoscopic vertex shader overrideUS8009176Apr 5, 2011Aug 30, 2011Apple Inc.System and method for processing graphics operations with graphics processing unitUS8040353Oct 15, 2010Oct 18, 2011Apple Inc.System for emulating graphics operationsUS8040359Oct 15, 2010Oct 18, 2011Apple Inc.System for emulating graphics operationsUS8044963Oct 15, 2010Oct 25, 2011Apple Inc.System for emulating graphics operationsUS8069087Feb 16, 2010Nov 29, 2011Paul NykampMethods for interactive and synchronous display sessionUS8120622 *Jan 15, 2008Feb 21, 2012Microsoft CorporationProxy direct 3-D device and remote renderingUS8134561Apr 16, 2004Mar 13, 2012Apple Inc.System for optimizing graphics operationsUS8144159May 19, 2011Mar 27, 2012Apple Inc.Partial display updates in a windowing system using a programmable graphics processing unitUS8311894Feb 16, 2010Nov 13, 2012Reliable Tack Acquisitions LlcMethod and apparatus for interactive and synchronous display sessionUS8432407Jul 30, 2009Apr 30, 2013Microsoft CorporationMethod and system for managing graphics objects in a graphics display systemUS8446416Feb 11, 2011May 21, 2013Apple Inc.System for optimizing graphics operationsUS8520021Jul 13, 2011Aug 27, 2013Apple Inc.System and method for processing graphics operations with graphics processing unitUS8704837Apr 16, 2004Apr 22, 2014Apple Inc.High-level program interface for graphics operationsUS8732729Dec 30, 2009May 20, 2014Stmicroelectronics R&D (Shanghai) Co., Ltd.Unified driving method and unified driver apparatusUS8745173Dec 30, 2011Jun 3, 2014hopTo Inc.Client computing system for and method of receiving cross-platform remote access to 3D graphics applicationsUS8766990 *Dec 30, 2011Jul 1, 2014hopTo Inc.Server computing system for and method of providing cross-platform remote access to 3D graphics applicationsUS8769052Feb 17, 2012Jul 1, 2014hopTo Inc.Cloud-based server computing system for and method of providing cross-platform remote access to 3D graphics applicationsUS8813099Feb 14, 2014Aug 19, 2014Stmicroelectronics R&D (Shanghai) Co., Ltd.Unified driving method and unified driver apparatusUS8838749Feb 17, 2012Sep 16, 2014hopTo Inc.Cloud based client computing system for and method of receiving cross-platform remote access to 3D graphics applicationsUS20120050291 *Aug 24, 2010Mar 1, 2012Qualcomm IncorporatedGraphics processing using two-dimensional scissor regions* Cited by examinerClassifications U.S. Classification345/418, 345/629, 719/328International ClassificationG06F17/00, G06F9/46Cooperative ClassificationG06F9/541European ClassificationG06F9/54ALegal EventsDateCodeEventDescriptionMay 16, 2012FPAYFee paymentYear of fee payment: 8May 30, 2008FPAYFee paymentYear of fee payment: 4Apr 30, 2001ASAssignmentOwner name: MICROSOFT CORPORATION, WASHINGTONFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:BOYD, CHARLES N.;NOYLE, JEFFREY M. J.;TOELLE, MICHAEL A.;REEL/FRAME:011760/0287Effective date: 20010227Owner name: MICROSOFT CORPORATION ONE MICROSOFT WAYREDMOND, WAFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:BOYD, CHARLES N. /AR;REEL/FRAME:011760/0287RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services