Scalable Graphics Architectures: Interface & Texture

Total Page:16

File Type:pdf, Size:1020Kb

Scalable Graphics Architectures: Interface & Texture SCALABLE GRAPHICS ARCHITECTURES: INTERFACE & TEXTURE A DISSERTATION SUBMITTED TO THE COMPUTER SCIENCE DEPARTMENT AND THE COMMITTEE ON GRADUATE STUDIES OF STANFORD UNIVERSITY IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF DOCTOR OF PHILOSOPHY Homan Igehy May 2000 © Copyright by Homan Igehy 2000 All Rights Reserved ii I certify that I have read this dissertation and that in my opinion it is fully adequate, in scope and quality, as a dissertation for the degree of Doctor of Philosophy. ___________________________________ Pat Hanrahan (Principal Advisor) I certify that I have read this dissertation and that in my opinion it is fully adequate, in scope and quality, as a dissertation for the degree of Doctor of Philosophy. ___________________________________ Mark Horowitz I certify that I have read this dissertation and that in my opinion it is fully adequate, in scope and quality, as a dissertation for the degree of Doctor of Philosophy. ___________________________________ Bill Dally Approved for the University Committee on Graduate Studies: ___________________________________ iii iv Abstract With today's technology, it is possible to place a significant amount graphics processing power on a single chip. While this allows computers to render very impressive imagery, many interactive graphics applications require several orders of magnitude more in proc- essing power. Parallelism is one way of achieving increased power, and scalable solu- tions achieve parallelism through the replication of a basic unit. In this dissertation, we discuss scalable graphics architectures and present novel techniques for scaling two im- portant aspects of graphics architectures that have not been addressed by the literature: interface and texture. First, we analyze parallelism in the graphics pipeline. By looking at the virtual ma- chine defined by the graphics API and analyzing its dependencies, we are able to exam- ine the sources of parallelism. We define the metrics of scalability and analyze the extent to which existing graphics architectures are able to scale. Second, we present a novel parallel graphics interface that allows for scalable input rates. This interface allows mul- tiple graphics contexts to simultaneously submit commands to the graphics system while explicitly ordering the drawing of graphics primitives. Even with scenes that require a total order, fully scalable submission and rendering are demonstrated. Finally, we pre- sent a scalable texture architecture based on a shared texture memory. In order to tolerate the high and variable latencies of a shared texture memory, a novel texture prefetching architecture is described. The effects of parallel texture caching are examined in detail, demonstrating the applicability of such an approach across a wide variety of rasterization architectures. v vi Acknowledgements I would like to thank all the people who helped me through my years at Stanford. Be- cause I did my undergraduate education here as well as my graduate education, I have spent 9 years out of my 27 years of life here: one-third of my life. You’ll understand if I forget someone…. First and foremost, I would like to thank my advisor, Pat Hanrahan. Stylistically, he was very much a hands-off advisor that let me pursue my interests. Sometimes this would mean video games and guitar, and sometimes this would mean fruitful research. The research in this dissertation, as well as research beyond the scope of this dissertation, was guided by a person who had the knowledge to push me in the right direction and the wisdom to let me find my way from there. I would also like to thank Bill Dally and Mark Horowitz, the other members of my reading committee. Mark’s comments over the years have always been to the point and have helped me gain a greater technical understanding of the work in this thesis. Bill’s viewpoints called into question many of my assumptions and have helped me gain a better understanding of graphics architectures from a more general perspective. My colleagues in the Stanford graphics lab have been a source of fun and learning. The course project of implementing a graphics pipeline in a class by Marc Levoy sparked my interest in graphics architecture, and I still recall trying to keep up with the torrent pace of lecturing by Leo Guibas in a couple of classes. I also owe a great debt to the other students who helped me with my research over the years, particularly Matthew El- dridge, Gordon Stoll, Kekoa Proudfoot, John Owens, Matt Pharr, Milton Chen, Ian Buck, vii James Davis, Bill Mark, Maneesh Agrawala, Timothy Purcell, Lucas Pereira, Greg Hum- phreys, Afra Zomorodian, and Phil Lacroute. I would like to thank my parents, Jeff and Golie, for their love and support over the years. I would like to thank my brother, Alex, and his fiancée, Dana, for looking out for me over the years. I thank my friends, who have made me laugh through good times and bad times, and I thank Sepi, who puts a smile on my face every day. Finally, I would like to thank DARPA, under contract DABT63-95-C-0085-P00006, and Intel Corporation for the financial support of my research. viii Contents Abstract v Acknowledgements vii Chapter 1 Introduction 1 1.1 Trends in Graphics Architecture .......................................................................... 2 1.2 The Rendering Problem ....................................................................................... 5 1.2.1 Representations and Algorithms .............................................................. 5 1.2.2 Interactive Rendering ............................................................................... 7 1.3 The Graphics Pipeline.......................................................................................... 8 1.4 Summary of Original Contributions................................................................... 14 Chapter 2 Analysis of Parallel Graphics 17 2.1 Sources of Parallelism........................................................................................ 18 2.1.1 Instruction Set........................................................................................ 19 2.1.2 Data Dependencies................................................................................. 21 2.1.2.1 Dependencies and Parallelism.......................................................... 21 2.1.2.2 Data Dependencies in Graphics Architectures................................. 23 2.1.3 Control Dependencies ............................................................................ 26 2.1.4 Discussion .............................................................................................. 27 2.2 Scaling the Graphics Pipeline ............................................................................ 29 ix 2.2.1 Scalability Metrics.................................................................................. 29 2.2.2 Analysis of Scalable Architectures ........................................................ 32 2.2.2.1 Sort-First Architectures.................................................................... 35 2.2.2.2 Sort-Middle Architectures................................................................ 38 2.2.2.3 Fragment-sorting Architectures........................................................ 42 2.2.2.4 Image-Composition Architectures ................................................... 43 2.2.2.5 Pomegranate Architecture................................................................ 45 2.3 Conclusion ......................................................................................................... 48 Chapter 3 Scalable Graphics Interface 49 3.1 Introduction........................................................................................................ 50 3.2 Motivation.......................................................................................................... 51 3.3 Related Work ..................................................................................................... 53 3.4 The Parallel API Extensions .............................................................................. 55 3.4.1 Existing Constructs................................................................................ 56 3.4.2 The Wait Construct ................................................................................ 57 3.4.3 Synchronization Constructs....................................................................58 3.5 Using the Parallel Graphics API ........................................................................ 59 3.5.1 Simple Interactive Loop......................................................................... 60 3.5.2 Marching Cubes..................................................................................... 61 3.6 Implementations................................................................................................. 63 3.6.1 Argus: A Software Implementation ....................................................... 63 3.6.1.1 Architecture...................................................................................... 63 3.6.1.2 Performance ..................................................................................... 67 3.6.2 Pomegranate: A Hardware Implementation........................................... 73 3.6.2.1 Architecture...................................................................................... 73 3.6.2.2 Performance ..................................................................................... 76 3.6.3 WireGL: A Transparent Implementation
Recommended publications
  • (12) United States Patent (10) Patent No.: US 7,133,041 B2 Kaufman Et Al
    US007133041B2 (12) United States Patent (10) Patent No.: US 7,133,041 B2 Kaufman et al. (45) Date of Patent: Nov. 7, 2006 (54) APPARATUS AND METHOD FOR VOLUME (56) References Cited PROCESSING AND RENDERING U.S. PATENT DOCUMENTS (75) Inventors: Arie E. Kaufman, Plainview, NY (US); 4,314,351 A 2f1982 Postel et al. Ingmar Bitter, Lake Grove, NY (US); 4,371,933 A 2, 1983 Bresenham et al. Frank Dachille, Amityville, NY (US); Kevin Kreeger, East Setauket, NY (Continued) (US); Baoquan Chen, Maple Grove, FOREIGN PATENT DOCUMENTS MN (US) EP O 216 156 A2 4f1987 (73) Assignee: The Research Foundation of State University of New York, Albany, NY (Continued) (US) OTHER PUBLICATIONS (*) Notice: Subject to any disclaimer, the term of this Knittel, G., TriangleCaster: extensions to 3D-texturing units for patent is extended or adjusted under 35 accelerated volume rendering, 1999, Proceedings of the ACM U.S.C. 154(b) by 742 days. SIGGRAPH/EUROGRAPHICS workshop on Graphics hardware, pp. 25-34.* (21) Appl. No.: 10/204,685 (Continued) PCT Fed: Feb. 26, 2001 (22) Primary Examiner Ulka Chauhan (86) PCT No.: PCT/USO1 (O6345 Assistant Examiner Said Broome (74) Attorney, Agent, or Firm Hoffmann & Baron, LLP S 371 (c)(1), (2), (4) Date: Jan. 9, 2003 (57) ABSTRACT (87) PCT Pub. No.: WOO1A63561 An apparatus and method for real-time Volume processing and universal three-dimensional rendering. The apparatus PCT Pub. Date: Aug. 30, 2001 includes a plurality of three-dimensional (3D) memory units; at least one pixel bus for providing global horizontal (65) Prior Publication Data communication; a plurality of rendering pipelines; at least one geometry bus; and a control unit.
    [Show full text]
  • SIMD Extensions
    SIMD Extensions PDF generated using the open source mwlib toolkit. See http://code.pediapress.com/ for more information. PDF generated at: Sat, 12 May 2012 17:14:46 UTC Contents Articles SIMD 1 MMX (instruction set) 6 3DNow! 8 Streaming SIMD Extensions 12 SSE2 16 SSE3 18 SSSE3 20 SSE4 22 SSE5 26 Advanced Vector Extensions 28 CVT16 instruction set 31 XOP instruction set 31 References Article Sources and Contributors 33 Image Sources, Licenses and Contributors 34 Article Licenses License 35 SIMD 1 SIMD Single instruction Multiple instruction Single data SISD MISD Multiple data SIMD MIMD Single instruction, multiple data (SIMD), is a class of parallel computers in Flynn's taxonomy. It describes computers with multiple processing elements that perform the same operation on multiple data simultaneously. Thus, such machines exploit data level parallelism. History The first use of SIMD instructions was in vector supercomputers of the early 1970s such as the CDC Star-100 and the Texas Instruments ASC, which could operate on a vector of data with a single instruction. Vector processing was especially popularized by Cray in the 1970s and 1980s. Vector-processing architectures are now considered separate from SIMD machines, based on the fact that vector machines processed the vectors one word at a time through pipelined processors (though still based on a single instruction), whereas modern SIMD machines process all elements of the vector simultaneously.[1] The first era of modern SIMD machines was characterized by massively parallel processing-style supercomputers such as the Thinking Machines CM-1 and CM-2. These machines had many limited-functionality processors that would work in parallel.
    [Show full text]
  • Real-Time Rendering Techniques with Hardware Tessellation
    Volume 34 (2015), Number x pp. 0–24 COMPUTER GRAPHICS forum Real-time Rendering Techniques with Hardware Tessellation M. Nießner1 and B. Keinert2 and M. Fisher1 and M. Stamminger2 and C. Loop3 and H. Schäfer2 1Stanford University 2University of Erlangen-Nuremberg 3Microsoft Research Abstract Graphics hardware has been progressively optimized to render more triangles with increasingly flexible shading. For highly detailed geometry, interactive applications restricted themselves to performing transforms on fixed geometry, since they could not incur the cost required to generate and transfer smooth or displaced geometry to the GPU at render time. As a result of recent advances in graphics hardware, in particular the GPU tessellation unit, complex geometry can now be generated on-the-fly within the GPU’s rendering pipeline. This has enabled the generation and displacement of smooth parametric surfaces in real-time applications. However, many well- established approaches in offline rendering are not directly transferable due to the limited tessellation patterns or the parallel execution model of the tessellation stage. In this survey, we provide an overview of recent work and challenges in this topic by summarizing, discussing, and comparing methods for the rendering of smooth and highly-detailed surfaces in real-time. 1. Introduction Hardware tessellation has attained widespread use in computer games for displaying highly-detailed, possibly an- Graphics hardware originated with the goal of efficiently imated, objects. In the animation industry, where displaced rendering geometric surfaces. GPUs achieve high perfor- subdivision surfaces are the typical modeling and rendering mance by using a pipeline where large components are per- primitive, hardware tessellation has also been identified as a formed independently and in parallel.
    [Show full text]
  • Troubleshooting Guide Table of Contents -1- General Information
    Troubleshooting Guide This troubleshooting guide will provide you with information about Star Wars®: Episode I Battle for Naboo™. You will find solutions to problems that were encountered while running this program in the Windows 95, 98, 2000 and Millennium Edition (ME) Operating Systems. Table of Contents 1. General Information 2. General Troubleshooting 3. Installation 4. Performance 5. Video Issues 6. Sound Issues 7. CD-ROM Drive Issues 8. Controller Device Issues 9. DirectX Setup 10. How to Contact LucasArts 11. Web Sites -1- General Information DISCLAIMER This troubleshooting guide reflects LucasArts’ best efforts to account for and attempt to solve 6 problems that you may encounter while playing the Battle for Naboo computer video game. LucasArts makes no representation or warranty about the accuracy of the information provided in this troubleshooting guide, what may result or not result from following the suggestions contained in this troubleshooting guide or your success in solving the problems that are causing you to consult this troubleshooting guide. Your decision to follow the suggestions contained in this troubleshooting guide is entirely at your own risk and subject to the specific terms and legal disclaimers stated below and set forth in the Software License and Limited Warranty to which you previously agreed to be bound. This troubleshooting guide also contains reference to third parties and/or third party web sites. The third party web sites are not under the control of LucasArts and LucasArts is not responsible for the contents of any third party web site referenced in this troubleshooting guide or in any other materials provided by LucasArts with the Battle for Naboo computer video game, including without limitation any link contained in a third party web site, or any changes or updates to a third party web site.
    [Show full text]
  • Bid Bulletin
    Bidding No.: GOODS-21-40 Bidding Title: Supply and Delivery of Office and I.T. Equipment and Supplies Location of the Project: VSU Main, Visca, Baybay City Leyte B I D B U L L E T I N 0 1 Date: 18 August 2021 Project Title: Supply and Delivery of Office and I.T. Equipment and Supplies (GOODS-21-40) Location: VSU Main, Visca, Baybay City, Leyte Bidders are hereby informed/reminded of the following addendums/amendments/clarifications: I. LIST OF REQUIREMENTS (1st Envelope) TECHNICAL COMPONENT ENVELOPE Legal Documents 1 PhilGEPS Certificate of Registration (Platinum) or a. Registration Certificate (SEC, DTI or CDA) b. Mayor's/Business Permit c. Tax Clearance Technical Documents 2 Statement of All On-Going Government & Private Contracts Statement of Bidder's Single Largest Completed Contract (at least 3 50% of the ABC or Php 1,509,108.50 Or Statement of at least two (2) similar completed contracts w/ total amount of at least Php 1,509,108.50 and the largest of which should be at least Php 754,554.25. 4 Bid Security 5 Technical Specifications 6 SCHEDULE of Requirements/Production and delivery schedule 7 Manpower Requirements After Sales service/parts from acceptance of delivered goods (at least 8 1 year for equipment and 3 months for supplies) 9 Original Duly Signed Omnibus Sworn Statement Financial Documents 10 The Supplier’s Audited Financial Statements 11 Net Financial Contracting Capacity (at least Php 3,018,217.00) Or Committed Line of Credit (at least Php 301,821.70) (2nd Envelope) FINANCIAL COMPONENT ENVELOPE 12 Original of duly signed and accomplished Financial Bid Form 13 Original of duly signed and accomplished Price Schedule(s) Bidding No.: GOODS-21-40 Bidding Title: Supply and Delivery of Office and I.T.
    [Show full text]
  • This Is Your Presentation Title
    Introduction to GPU/Parallel Computing Ioannis E. Venetis University of Patras 1 Introduction to GPU/Parallel Computing www.prace-ri.eu Introduction to High Performance Systems 2 Introduction to GPU/Parallel Computing www.prace-ri.eu Wait, what? Aren’t we here to talk about GPUs? And how to program them with CUDA? Yes, but we need to understand their place and their purpose in modern High Performance Systems This will make it clear when it is beneficial to use them 3 Introduction to GPU/Parallel Computing www.prace-ri.eu Top 500 (June 2017) CPU Accel. Rmax Rpeak Power Rank Site System Cores Cores (TFlop/s) (TFlop/s) (kW) National Sunway TaihuLight - Sunway MPP, Supercomputing Center Sunway SW26010 260C 1.45GHz, 1 10.649.600 - 93.014,6 125.435,9 15.371 in Wuxi Sunway China NRCPC National Super Tianhe-2 (MilkyWay-2) - TH-IVB-FEP Computer Center in Cluster, Intel Xeon E5-2692 12C 2 Guangzhou 2.200GHz, TH Express-2, Intel Xeon 3.120.000 2.736.000 33.862,7 54.902,4 17.808 China Phi 31S1P NUDT Swiss National Piz Daint - Cray XC50, Xeon E5- Supercomputing Centre 2690v3 12C 2.6GHz, Aries interconnect 3 361.760 297.920 19.590,0 25.326,3 2.272 (CSCS) , NVIDIA Tesla P100 Cray Inc. DOE/SC/Oak Ridge Titan - Cray XK7 , Opteron 6274 16C National Laboratory 2.200GHz, Cray Gemini interconnect, 4 560.640 261.632 17.590,0 27.112,5 8.209 United States NVIDIA K20x Cray Inc. DOE/NNSA/LLNL Sequoia - BlueGene/Q, Power BQC 5 United States 16C 1.60 GHz, Custom 1.572.864 - 17.173,2 20.132,7 7.890 4 Introduction to GPU/ParallelIBM Computing www.prace-ri.eu How do
    [Show full text]
  • 9.Texture Mapping
    OpenGL_PG.book Page 359 Thursday, October 23, 2003 3:23 PM Chapter 9 9.Texture Mapping Chapter Objectives After reading this chapter, you’ll be able to do the following: • Understand what texture mapping can add to your scene • Specify texture images in compressed and uncompressed formats • Control how a texture image is filtered as it’s applied to a fragment • Create and manage texture images in texture objects and, if available, control a high-performance working set of those texture objects • Specify how the color values in the image combine with those of the fragment to which it’s being applied • Supply texture coordinates to indicate how the texture image should be aligned with the objects in your scene • Generate texture coordinates automatically to produce effects such as contour maps and environment maps • Perform complex texture operations in a single pass with multitexturing (sequential texture units) • Use texture combiner functions to mathematically operate on texture, fragment, and constant color values • After texturing, process fragments with secondary colors • Perform transformations on texture coordinates using the texture matrix • Render shadowed objects, using depth textures 359 OpenGL_PG.book Page 360 Thursday, October 23, 2003 3:23 PM So far, every geometric primitive has been drawn as either a solid color or smoothly shaded between the colors at its vertices—that is, they’ve been drawn without texture mapping. If you want to draw a large brick wall without texture mapping, for example, each brick must be drawn as a separate polygon. Without texturing, a large flat wall—which is really a single rectangle—might require thousands of individual bricks, and even then the bricks may appear too smooth and regular to be realistic.
    [Show full text]
  • PACKET 22 BOOKSTORE, TEXTBOOK CHAPTER Reading Graphics
    A.11 GRAPHICS CARDS, Historical Perspective (edited by J Wunderlich PhD in 2020) Graphics Pipeline Evolution 3D graphics pipeline hardware evolved from the large expensive systems of the early 1980s to small workstations and then to PC accelerators in the 1990s, to $X,000 graphics cards of the 2020’s During this period, three major transitions occurred: 1. Performance-leading graphics subsystems PRICE changed from $50,000 in 1980’s down to $200 in 1990’s, then up to $X,0000 in 2020’s. 2. PERFORMANCE increased from 50 million PIXELS PER SECOND in 1980’s to 1 billion pixels per second in 1990’’s and from 100,000 VERTICES PER SECOND to 10 million vertices per second in the 1990’s. In the 2020’s performance is measured more in FRAMES PER SECOND (FPS) 3. Hardware RENDERING evolved from WIREFRAME to FILLED POLYGONS, to FULL- SCENE TEXTURE MAPPING Fixed-Function Graphics Pipelines Throughout the early evolution, graphics hardware was configurable, but not programmable by the application developer. With each generation, incremental improvements were offered. But developers were growing more sophisticated and asking for more new features than could be reasonably offered as built-in fixed functions. The NVIDIA GeForce 3, described by Lindholm, et al. [2001], took the first step toward true general shader programmability. It exposed to the application developer what had been the private internal instruction set of the floating-point vertex engine. This coincided with the release of Microsoft’s DirectX 8 and OpenGL’s vertex shader extensions. Later GPUs, at the time of DirectX 9, extended general programmability and floating point capability to the pixel fragment stage, and made texture available at the vertex stage.
    [Show full text]
  • Linux Hardware Compatibility HOWTO
    Linux Hardware Compatibility HOWTO Steven Pritchard Southern Illinois Linux Users Group [email protected] 3.1.5 Copyright © 2001−2002 by Steven Pritchard Copyright © 1997−1999 by Patrick Reijnen 2002−03−28 This document attempts to list most of the hardware known to be either supported or unsupported under Linux. Linux Hardware Compatibility HOWTO Table of Contents 1. Introduction.....................................................................................................................................................1 1.1. Notes on binary−only drivers...........................................................................................................1 1.2. Notes on commercial drivers............................................................................................................1 1.3. System architectures.........................................................................................................................1 1.4. Related sources of information.........................................................................................................2 1.5. Known problems with this document...............................................................................................2 1.6. New versions of this document.........................................................................................................2 1.7. Feedback and corrections..................................................................................................................3 1.8. Acknowledgments.............................................................................................................................3
    [Show full text]
  • Programming Guide: Revision 1.4 June 14, 1999 Ccopyright 1998 3Dfxo Interactive,N Inc
    Voodoo3 High-Performance Graphics Engine for 3D Game Acceleration June 14, 1999 al Voodoo3ti HIGH-PERFORMANCEopy en GdRAPHICS E NGINEC FOR fi ot 3D GAME ACCELERATION on Programming Guide: Revision 1.4 June 14, 1999 CCopyright 1998 3Dfxo Interactive,N Inc. All Rights Reserved D 3Dfx Interactive, Inc. 4435 Fortran Drive San Jose CA 95134 Phone: (408) 935-4400 Fax: (408) 935-4424 Copyright 1998 3Dfx Interactive, Inc. Revision 1.4 Proprietary and Preliminary 1 June 14, 1999 Confidential Voodoo3 High-Performance Graphics Engine for 3D Game Acceleration Notice: 3Dfx Interactive, Inc. has made best efforts to ensure that the information contained in this document is accurate and reliable. The information is subject to change without notice. No responsibility is assumed by 3Dfx Interactive, Inc. for the use of this information, nor for infringements of patents or the rights of third parties. This document is the property of 3Dfx Interactive, Inc. and implies no license under patents, copyrights, or trade secrets. Trademarks: All trademarks are the property of their respective owners. Copyright Notice: No part of this publication may be copied, reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photographic, or otherwise, or used as the basis for manufacture or sale of any items without the prior written consent of 3Dfx Interactive, Inc. If this document is downloaded from the 3Dfx Interactive, Inc. world wide web site, the user may view or print it, but may not transmit copies to any other party and may not post it on any other site or location.
    [Show full text]
  • Antialiasing
    Antialiasing CSE 781 Han-Wei Shen What is alias? Alias - A false signal in telecommunication links from beats between signal frequency and sampling frequency (from dictionary.com) Not just telecommunication, alias is everywhere in computer graphics because rendering is essentially a sampling process Examples: Jagged edges False texture patterns Alias caused by under-sampling 1D signal sampling example Actual signal Sampled signal Alias caused by under-sampling 2D texture display example Minor aliasing worse aliasing How often is enough? What is the right sampling frequency? Sampling theorem (or Nyquist limit) - the sampling frequency has to be at least twice the maximum frequency of the signal to be sampled Need two samples in this cycle Reconstruction After the (ideal) sampling is done, we need to reconstruct back the original continuous signal The reconstruction is done by reconstruction filter Reconstruction Filters Common reconstruction filters: Box filter Tent filter Sinc filter = sin(πx)/πx Anti-aliased texture mapping Two problems to address – Magnification Minification Re-sampling Minification and Magnification – resample the signal to a different resolution Minification Magnification (note the minification is done badly here) Magnification Simpler to handle, just resample the reconstructed signal Reconstructed signal Resample the reconstructed signal Magnification Common methods: nearest neighbor (box filter) or linear interpolation (tent filter) Nearest neighbor bilinear interpolation Minification Harder to handle The signal’s frequency is too high to avoid aliasing A possible solution: Increase the low pass filter width of the ideal sinc filter – this effectively blur the image Blur the image first (using any method), and then sample it Minification Several texels cover one pixel (under sampling happens) Solution: Either increase sampling rate or reduce the texture Frequency one pixel We will discuss: Under sample artifact 1.
    [Show full text]
  • 3D Computer Graphics Compiled By: H
    animation Charge-coupled device Charts on SO(3) chemistry chirality chromatic aberration chrominance Cinema 4D cinematography CinePaint Circle circumference ClanLib Class of the Titans clean room design Clifford algebra Clip Mapping Clipping (computer graphics) Clipping_(computer_graphics) Cocoa (API) CODE V collinear collision detection color color buffer comic book Comm. ACM Command & Conquer: Tiberian series Commutative operation Compact disc Comparison of Direct3D and OpenGL compiler Compiz complement (set theory) complex analysis complex number complex polygon Component Object Model composite pattern compositing Compression artifacts computationReverse computational Catmull-Clark fluid dynamics computational geometry subdivision Computational_geometry computed surface axial tomography Cel-shaded Computed tomography computer animation Computer Aided Design computerCg andprogramming video games Computer animation computer cluster computer display computer file computer game computer games computer generated image computer graphics Computer hardware Computer History Museum Computer keyboard Computer mouse computer program Computer programming computer science computer software computer storage Computer-aided design Computer-aided design#Capabilities computer-aided manufacturing computer-generated imagery concave cone (solid)language Cone tracing Conjugacy_class#Conjugacy_as_group_action Clipmap COLLADA consortium constraints Comparison Constructive solid geometry of continuous Direct3D function contrast ratioand conversion OpenGL between
    [Show full text]