Source: http://www.google.com/patents/US7570268?dq=7634659
Timestamp: 2018-01-21 03:08:23
Document Index: 648592713

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

Patent US7570268 - Systems and methods for providing graphics data in parallel to graphics ... - Google Patents
A method and system for controlling the algorithmic elements in 3D graphics systems via an improved 3D graphics API is provided. In one aspect, in a 3D graphics system having privatized formats with privatized drivers used to increase the efficiency of display, existing problems are eliminated that are...http://www.google.com/patents/US7570268?utm_source=gb-gplus-sharePatent US7570268 - Systems and methods for providing graphics data in parallel to graphics processing hardware
Publication number US7570268 B2
Application number US 10/973,359
Also published as US6828975, US6954205, US7187384, US7466317, US7646388, US8432407, US20020122040, US20050001845, US20050083327, US20050083334, US20050083335, US20050093870, US20100020071
Publication number 10973359, 973359, US 7570268 B2, US 7570268B2, US-B2-7570268, US7570268 B2, US7570268B2
Patent Citations (18), Non-Patent Citations (62), Referenced by (4), Classifications (11), Legal Events (3)
Systems and methods for providing graphics data in parallel to graphics processing hardware
US 7570268 B2
This application is a continuation of U.S. patent application Ser. No. 09/796,787, filed Mar. 1, 2001, now U.S Pat. No. 6,828,975, which is hereby incorporated by reference in its entirety.
For example, in the past, when a developer switched graphics data from one memory location to another, the developer had to deal with switching the data i.e., by destroying and recreating the data. In this regard, there are two types of ‘containers’ that today's graphics APIs present to a developer for use: one for pixels and one for polygons. Essentially, by passing arguments to the graphics API (placing data into the containers), the developers can manipulate and render various chunks of data. Once these containers are filled with data, there are various places, such as system memory or on a 3D card or chip, where this data may, be stored for further manipulation. The filling and placement of the containers is achieved via various components or function calls of the graphics API. The decision as to where to place this data is generally a performance issue. Data for which fast access is not necessary can be stored in system memory, whereas data for which speed of access is more important may be stored on a graphics chip designed for ultra fast access.
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, in a 3D graphics system having privatized formats with privatized drivers used to increase the efficiency of-display, the present invention eliminates existing problems associated with multiple redundant copies of the publicly formatted graphics data made in host system memory pursuant to various graphics operations e.g., lock and unlock operations. The present invention thus exposes the ability to make a system copy of publicly formatted data to the developer, eliminating the creation of unnecessary, and redundant copies. Efficient switching between the privatized and public format remains hidden from the developers so that applications execute efficiently while removing consideration thereof from the developers. Thus, developers are free to consider other tasks. In the event that a developer wishes to make a copy of the data, the data is copied pursuant to an operation that the developer calls and over which the developer has control, ensuring that multiple redundant copies of the graphics data are not made in host system memory.
(D3DVSD‘13 MAKETOKENTYPE(D3DVSD_TOKEN_STREAM) |
(D3DVSD_MAKETOKENTYPE(D3DVSD_TOKEN—
STREAMDATA) | \
STREAMDATA) | 0x10000000 | \
CONSTMEM) | \
((_Count) << D3DVSD_CONSTCOUNTSHIFT) | (—
ConstantAddress))
#define D3DVSD_TESSNORMAL( _VertexRegisterIn, —
VertexRegisterOut ) \
TESSELLATOR) | \
TESSELLATOR) | 0x10000000 | \
#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
(((_DWordSize)<<D3DSI_COMMENTSIZE_SHIFT)&D3DSI—
COMMENTSIZE_MASK)|D3DSIO_COMMENT)
Currently, when data is stored in hardware memory, the data is implemented in the privatized format illustrated in FIG. 7A. When graphics data is stored in main memory, it is stored in the public, more easily understood format. The privatized driver performs this transition. However, previously when graphics data stored in the hardware memory was .asked for pursuant to some command or fumction call, the data was shuffled back to the public format, and then transmitted according to the private format for hardware purposes. Thus, upon an ‘unlock’ command, the data was copied to system memory in the public format, and then the data was transformed to the privatized format where necessary. Unfortunately, a problem arises wherein the same data may be ‘unlocked’ from hardware memory according to multiple function calls or commands, and consequently, multiple copies of the same data may be copied to the system memory. The present invention addresses this problem by only allowing data to be copied into system memory space when the developer specifically makes such a request, and thus ensuring that only copies that the developer knows about are resident in the system. Reductions in performance as a result of multiple copies resident in main memory, when unnecessary, are thus avoided. In recognition that the data does not always need to be accessed from system memory space, the present invention thus allows the developer more freedom to command when data is copied to system memory when stored in the privatized format associated with hardware memory.
16 Goris, A. et al., "A Configurable Pixel Cache for Fast Image Generation," IEEE Computer Graphics and Applications, Mar. 1987, 24-32.
18 Grimes, 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.
24 James, M., "3-D graphics to become accessible to all," Scientific Computing World, Feb. 1997, 41 and 43.
25 Johnson, 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.
26 Jones, M. et al., "High-Performance Graphics Via Silicon Compilation," VLSI Systems Design, Mar. 1987, 32, 33, 36 and 38.
27 Kaya, 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.
28 Kumar, S. et al., "Efficient rendering of trimmed NURBS surfaces," Computer-Aided Design, Jul. 1995, 27(7), 509-521.
29 Labsik, U. et al., "Progressive transmission of subdivision surfaces," Computational Geometry, 2000, 15, 25-39.
30 Lachaud, J-O. et al., "Continuous Analogs of Digital Boundaries: A Topological Approach to Iso-Surfaces," Graphical Models, 2000, 62, 129-164.
31 Lapidous, E. et al., "Optimal Depth Buffer for Low-Cost Graphics Hardware," Trident Microsystems, Inc., 1999, 67-73.
32 Lastra, A. et al., "Real-Time Programmable Shading," Proceedings: 1995 Symposium on Interactive 3D Graphics, Monterey, California, Apr. 9-12, 1995, 59-66.
33 Lee, J-A. et al., "SPARP: a single pass antialiased rasterization processor," Comput. & Graphics, 2000, 24, 233-243.
34 Lichten, L., "A Solution to Surface Connectivity Problems in Computer-Aided Design," Computer Graphics, Mar. 1981, 14(4), 168-199.
35 Mabin, F.H. et al., "A Parallel Algorithm to Reconstruct Bounding Surfaces in 3D Images," J. Supercomputing, 1998, 12, 137-155.
36 McManus, D. et al., "Optimal Static 2-Dimensional Screen Subdivision for Parallel Rasterization Architectures," Comput. & Graphics, 1997, 21(2), 159-169.
37 Meyers, D. et al., "Surfaces from Contours," ACM Transactions on Graphics, Jul. 1992, 11(3), 228-258.
38 Micikevicius, 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.
39 Nishimura, 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.
40 NVIDIA Corporation, "System Platform Processor (SPP) / Integrated Graphics Processor (IGP): Redefining System and Graphics Performance," nForce SPP/IGP Product Overview, Jan. 2002, Version 1, 2 pages.
41 NVIDIA Corporation, "Technical Brief: NVIDIA nfiniteFX II Engine From Research to Real Time," Jan. 16, 2002, 7 pages.
42 NVIDIA Corporation, "Technical Brief: NVIDIA nForce Platform Processing Architecture," 2001, 1-9.
43 Ohbuchi, 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.
44 Ohhashi, M. et al., "A 32b 3-D Graphic Processor Chip with 10M Pixels/s Gouraud Shading," 1988 IEEE International Solid-State Circuits Conference Digest of Technical Papers, Feb. 1988, 168-169 and 352.
45 Rowlan, J.S. et al., "A distributed, parallel, interactive volume rendering package," IEEE: Proceedings-Visualization '94, Washington, D.C., Oct. 17-21, 1994, 21-30.
46 Schneider, B-O. et al., "An adaptive framework for 3D graphics over networks," Comput. & Graphics, 1999, 23, 867-874.
47 Schneider, B-O. et al., "M-Buffer: A Flexible MISD Architecture for Advanced Graphics," Comput. & Graphics, 1995, 19(2), 239-246.
48 Senthinathan, 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.
49 Shinya, M., "Improvements on the Pixel-tracing Filter: Reflection/Refraction, Shadows, and Jittering," Proceedings: Graphics Interface '95, May 7-19, 1995, 92-102.
50 Shirali, N.S. et al., "A Parallel Architecture Graphics Processor," IEEE Southeastcon: Conference Proceedings, Knoxville, Tennessee, Apr. 11-13, 1998, 108-111.
51 Smith, D.R. et al., "A Circuit-Switched Shared-Memory Multiprocessor," International J. Mini Microcomputers, 1995, 17(3), 108-118.
52 Sussman, H. et al., "Graphics Memory Architectures," Wescon/86 Conference Record, 1986, 1-6.
53 Swanson, R.W. et al., "A Fast Shaded-Polygon Rendered," Computer Graphics, Aug. 1986, 20(4), 95-101.
54 Teonnies, 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.
55 Thompson, T., "An inside look at the most popular 3-D environments: OpenGL, QuickDraw 3D, and Direct3D," Must-See 3-D Engines, Jun. 1996, http://byte.com/art/9606/sec11/art4.htm, 7 pages.
56 Thompson, T., "Direct3D's Engine," Must-See 3-D Engines, Jun. 1996, http://byte.com/art/9606/sec11/art7.htm, 1 page.
57 Thompson, T., "Open GL's Command Structure," Must-See 3-D Engines, Jun. 1996, http://byte.com/art/9606/sec11/art5.htm, 1 page.
58 Thompson, T., "QuickDraw 3D's Command Structure," Must-See 3-D Engines, Jun. 1996, http://byte.com/art/9606/sec11/art6.htm, 1 page.
59 Thompson, T., "Three Ways to Tackle Multithreading," Must-See 3-D Engines, Jun. 1996, http://byte.com/art/9606/sec11/art8.htm, 1 page.
60 Wilson, J.L. et al., "Designing a Graphics Application Interface," Proceedings Graphics Interface '85, Montreal, Quebec, May 27-31, 1985, 373-380.
61 Yoshida, M. et al., "Trend of the computer graphics hardware," Information Processing Soc. of Japan, Oct. 1988, 29(10), 1109-1115.
62 Zheng, Y. et al., "Three-dimensional unstructured mesh generation: Part 2. Surface meshes," Comput. Methods Appl. Mech. Engrg., 1996, 134, 269-284.
U.S. Classification 345/522, 345/537, 345/503, 345/501
International Classification G06T15/00, G06F15/16, G06T1/00, G06T1/20, G06F13/00