DOCSLIB.ORG

GPU Benchmarking - for Handsets from a UI Perspective

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
GPU Benchmarking - for Handsets from a UI Perspective GPU Benchmarking - for handsets from a UI perspective ERIK BÄCKSTRÖM KRISTIAN SYLWANDER Master’s Thesis at LTH Supervisor: Fredrik Ademar Examiner: Micheal Doggett Abstract The graphical processing unit (GPU) is becoming an essential part of mo- bile phones and handsets. This improves the ability of handling graphics in handsets significantly. With this new chip it becomes possible to develop new stunning games but also new innovative 3D GUI (Graphical User Interfaces). Today there exist a couple of benchmarking programs targeting mobile GPUs but all of these benchmarking tools are all focused on game performance and not GUI performance. The aim with this master’s thesis is to develop a bench- marking program for mobile GPUs focusing on GUI performance. We have identified five features that are important when benchmarking a handset, from a GUI perspective: scissoring, texture uploads, alpha blending, load times and frame rate. Additionally, we have benchmarked five different devices using our tool. From the test we could conclude that there were big differences in the performance compared to the specification sheets. Acknowledgement This master thesis is done as a completing part of our education at LTH (Lund Institute of Technology) with focus on computer science. During the course of our master thesis we have received invaluable supervision and help from a number of persons both at TAT and at LTH. Therefore we would like to take the opportunity to thank these persons for their advise, knowledge and dedi- cation. First we would like to thank our supervisors at TAT Fredrik Ademar, Fredrik Berglund and Dan Gärdenfors. We also want to thank Michael Dog- gett, our examiner at LTH. Special thanks are directed to Michael Winberg and Emil Wassberger for their invaluable help. We would also like to thank our girlfriends Sania and Pernilla, for all their love and support, and for their comments on the thesis. Contents 1 Introduction 1 1.1 The Problem . 1 1.2 Our Aim . 2 1.3 Collaboration . 2 2 Background 3 2.1 OpenGL . 3 2.1.1 OpenGL 1 . 3 2.1.2 OpenGL 2 . 4 2.2 OpenGL ES . 5 2.3 EGL . 5 3 Benchmarking a GPU 7 3.1 Current Tools on the Market . 7 3.1.1 GLBenchmark . 7 3.1.2 JBenchmark . 8 3.1.3 Futuremark 3D Mobile . 9 3.2 Why a new Benchmarking tool? . 10 4 Method 11 5 Result 13 5.1 Test Framework . 13 5.1.1 PolluxGL . 13 5.2 GUI Characteristics . 16 5.3 Test Cases . 16 5.3.1 Basic . 17 5.3.2 Fill Rates . 17 5.3.3 Textures . 18 5.3.4 Frame Buffer Objects . 18 5.3.5 Triangle Throughput . 19 5.3.6 Shaders . 19 5.3.7 GUI Specific . 19 5.3.8 Pixel Pipeline Performance . 20 5.3.9 Optimizations . 21 5.4 Visualize Result . 21 6 Benchmarked Devices 23 6.1 Tested Devices . 23 6.2 Benchmarking Result . 23 6.2.1 Basic . 24 6.2.2 Fill rates . 24 6.2.3 Textures . 24 6.2.4 Frame Buffer Objects . 25 6.2.5 Triangle Throughput . 25 6.2.6 Shaders . 25 6.2.7 GUI Specific . 26 7 Discussion 27 7.1 Incorporation in a development process . 28 8 Conclusion 29 Appendices 29 A Test Case Descriptions 31 A.1 Frame Buffer Clear . 31 A.2 Draw Triangle . 31 A.3 Color Fill . 31 A.4 Z Fill . 32 A.5 Color-Z Fill . 32 A.6 Texel Rate . 33 A.7 Texture Upload Rate . 33 A.8 Texture Upload Format . 33 A.9 Alpha Blending . 33 A.10 Scene Alpha . 34 A.11 Scissoring . 34 A.12 Frame Buffer Object (FBO) . 34 A.13 Frame Buffer Count . 35 A.14 Triangle Count . 35 A.15 Triangle Count VBO . 35 A.16 Vertex Buffer Object (VBO) count . 35 A.17 Photo River . 36 A.18 Photo River with Mip-map . 36 A.19 Shader Program Switch . 36 A.20 Shader Precision . 37 A.21 Shader Limitation . 37 A.22 Subtexture updates . 37 A.23 Bump Mapping . 37 A.24 Timer test . 38 A.25 Non power of two textures . 38 A.26 Pixel Pipeline Performance . 38 Bibliography 41 Chapter 1 Introduction In the first quarter of 2009 mobile phone sales dropped 8.6 percent compared to the first quarter of 2008. During the same period Smartphone sales increased with 12.7 percent [1]. One reason for this increase is the introduction of the iPhone, which has started the trend of touch screens and put focus on graphics and usability in handsets [2]. Now vendors are trying to create the most visually appealing graphical user interfaces (GUIs) to meet the competition from Apple. But to be able to create this more advanced graphics, new hard- ware is needed in the phones. The key component is the graphical processing unit (GPU). It enables handsets to render advanced 3D graphics, mostly used for 3D games. Since the mobile game industry is estimated to generate 10 million dollars this year it is not supris- ing that the focus is on games, but the GPU can also be used to create new innovative 3D GUIs, and since the user experience is becoming one of the main selling points for mobile phones this is a great opportunity for the operators and vendors [3]. Mobile manufactur- ers need to have the latest technology in their phones to be able to compete on the global market, but they also need to cut their costs. Different mobile phones therefore perform very differently even though they support the same standards. The graphics standard is not always followed and sometimes functions are poorly implemented which can lead to un- expected behavior and/or bad performance especially on a prototype device[4]. Graphics application programming interfaces (API) are often implemented with the main purpose of running games which in turn can lead to functions not commonly used in games being im- plemented incorrectly or inefficiently due to short time frames during development. These functions can for instance be useful in a GUI[4] 1.1 The Problem The problem is that the benchmarking tools available today focus on game performance which makes them unsuitable for GUI benchmarking. Another aspect is that when de- veloping a GUI or anything else using graphics one would like to have information about which specific features that are fast/slow on a certain device. That information is, to our knowledge, not given by any of the tools available today as these use scenario-based test cases. Due to the lack of a sufficient 3D GUI benchmarking tool another problem arises. 1 CHAPTER 1. INTRODUCTION When an unfamiliar device is used in a development process intended to create a graphics application of some kind, the device is not benchmarked prior to the start of the project. This will most certainly lead to surprises about the performance which will arise during development which in turn can lead to costly delays. 1.2 Our Aim Our aim is to develop a benchmarking tool with the purpose of finding the limitations and bottlenecks of a mobile GPU. The tool will be designed with the development of a 3D GUI in mind. Hence the tests performed by the program will be focusing on GUI specific fea- tures. It will also focus on individual low-level features in order to find minor bottlenecks caused by these features. We will also investigate the possibility of using this program to reduce any delays caused by insufficient knowledge about the device from occurring in the development process. 1.3 Collaboration This master thesis has been carried out in collaboration with The Astonishing Tribe (TAT) and the Department for Computer Science at the Faculty of Engineering at Lund University. TAT is a company that develops solutions for GUIs in mobile devices. They have, among many other things, developed the GUI for Android (Google’s operating system for mobile devices) and their products can be found in over 300 million devices worldwide [5]. 2 Chapter 2 Background A very important factor that made it possible to run advanced 3D games on mobile de- vices is the introduction of Open Graphics Library for Embedded Systems (OpenGL ES or GLES), a platform independent API for rendering 2D and 3D graphics on devices with limited resources. In this section we will give a brief background to this API as well as an introduction to the benchmarking tools available on the market today. 2.1 OpenGL Open Graphics Library (OpenGL) is a cross-platform API for rendering 2D and 3D com- puter graphics [6] . In other words, OpenGL is a set of commands for the creation of geometric objects and commands that control how these objects are rendered. One of the strengths of OpenGL is the possibility to develop extensions to add new features that are not specified by the OpenGL standard, which makes sure that OpenGL is current with the latest graphics and rendering algorithms available. Furthermore, it is important to let program- mers adapt their applications to different hardware to achieve the goal of a cross-platform API. OpenGL was initially developed by Silicon Graphics Inc (SGI) as an initiative to create a single, vendor-independent graphics API [7]. However, when the Architecture Re- view Board (ARB) was founded in 1992 they took over maintenance of OpenGL until they became a part of the Khronos Group in 2006. 2.1.1 OpenGL 1 The first version (1.0) of OpenGL was released in 1992 [6]. It contained features like per- vertex lighting, texturing and blending . When OpenGL Version 1.1 was released later that year vertex arrays were introduced as one of the more important additions.
Load more

Recommended publications
  • Scalability of Terrain Visualization in Large Virtual Environments
    WORDT ' Facultyof Mathematics and Natural Department of NIET UITGELEEND Mathematics and Computing Science Scalability of Terrain Visualization in Large Virtual Environments Esger G.N. Abbink Advisors: dr. J.B.TM. Roerdink Department of Mathematics and Computing Science University of Groningen drs. M.J.B. van Delden drs. M. Wierda Virtual Environments, Systems, and Consultancy Zeegse .(,-,-, June,2000 Rkunlv,,,IOIOi*S DDothk W1s*ud. 'iMP* IRS&SIICSIWI'U :.'von S r-;tus800 9' Avr')1rs.r Scalability of terrain visualization in large Virtual Environments Esger G.N. Abbink Department of Mathematics and Computing Science Graduate specialization High Performance Computing and Imaging Studentnumber 0831425 Gerkesklooster/ Zeegse, April 2000 Rapport vesc WR-2000/3 •1 Table of Contents Scalability of terrain visualization in large Virtual Environments..1 1. Introduction 4 2. Virtual Environments 6 2.1 Startingpoints 6 2.2 Means-end analysis 6 2.3 Man-in-the-loop 6 2.4 Hardware 8 2.5 Real-world simulators 9 2.5.1 Flight Simulators 9 2.5.2 Driving Simulators 9 2.5.3 Rail vehicle simulators 10 2.5.4 Ship Simulator 11 2.5.5 yE Walkthrough 11 2.5.6 Entertainment Simulators 12 2.5.7 Telepresence 12 2.5.8 Virtual GIS 13 2.6 Summary & practical continuation 13 3. Scalable terrain visualization 15 3.1 Introduction 15 3.2 The sample implementation 15 3.2.1 Introduction 15 3.2.2 Getting it to work 15 3.2.3 Porting the sample implementation to 4Space 16 3.3 Design 16 3.3.1 Goal 16 3.3.2 Requirements 16 3.3.3 Terrain representation 16 3.3.4 Basic setup 18 3.3.5 Tessellation algorithm 19 3.3.6 Implementation approach 23 3.4 Implementation 24 3.4.1 Terrain data generation 24 3.4.2 Implementing Central Differencing 24 3.4.2 Interfacing 4Space 28 3.4.3 Memory management 29 3.4.4 Dynamic data storages 30 3.4.4.1 Queue 30 3.4.4.2 Dynamic List & Pool 31 3.4.4.3 Red-Black Tree 31 3.4.4.4 Dynamic Storage 32 3.4.4.5 Evaluating performance 33 2 4.
    [Show full text]
  • DRAFT - DATED MATERIAL the CONTENTS of THIS REVIEWER’S GUIDE IS INTENDED SOLELY for REFERENCE WHEN REVIEWING Rev a VERSIONS of VOODOO5 5500 REFERENCE BOARDS
    Voodoo5™ 5500 for the PC Reviewer’s Guide DRAFT - DATED MATERIAL THE CONTENTS OF THIS REVIEWER’S GUIDE IS INTENDED SOLELY FOR REFERENCE WHEN REVIEWING Rev A VERSIONS OF VOODOO5 5500 REFERENCE BOARDS. THIS INFORMATION WILL BE REGULARLY UPDATED, AND REVIEWERS SHOULD CONTACT THE PERSONS LISTED IN THIS GUIDE FOR UPDATES BEFORE EVALUATING ANY VOODOO5 5500BOARD. 3dfx Interactive, Inc. 4435 Fortran Dr. San Jose, Ca 95134 408-935-4400 Brian Burke 214-570-2113 [email protected] PT Barnum 214-570-2226 [email protected] Bubba Wolford 281-578-7782 [email protected] www.3dfx.com www.3dfxgamers.com Copyright 2000 3dfx Interactive, Inc. All Rights Reserved. All other trademarks are the property of their respective owners. Visit the 3dfx Virtual Press Room at http://www.3dfx.com/comp/pressweb/index.html. Voodoo5 5500 Reviewers Guide xxxx 2000 Table of Contents Benchmarking the Voodoo5 5500 Page 5 • Cures for common benchmarking and image quality mistakes • Tips for benchmarking • Overclocking Guide INTRODUCTION Page 11 • Optimized for DVD Acceleration • Scalable Performance • Trend-setting Image quality Features • Texture Compression • Glide 2.x and 3.x Compatibility: The Most Titles • World-class Window’s GUI/video Acceleration SECTION 1: Voodoo5 5500 Board Overview Page 12 • General Features • 3D Features set • 2D Features set • Voodoo5 Video Subsystem • SLI • Texture compression • Fill Rate vs T&L • T-Buffer introduction • Alternative APIs (Al Reyes on Mac, Linux, BeOS and more) • Pricing & Availability • Warranty • Technical Support • Photos, screenshots,
    [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]
  • Mobile 3D Devices They're Not Little
    Mobile 3D Devices -- They’re not little PCs! Stephen Wilkinson – Graphics Software Technical Lead Texas Instruments CSSD/OMAP Who is this guy? ! Involved with simulation and games since 1995 ! Worked on SIMNET for the US Army ! PC gaming ! Titles include WarBirds 1 & 2, Fighter Squadron, AMA SuperBike, NHRA Drag Racing, NHRA Main Event ! 30+ Casino Games (yeah, yeah) ! Worked on core technology for several console games ! D&D Heroes, Mission Impossible: Operation SURMA, and T3: Redemption (NGC, PS2, Xbox) ! Former member of the Graphics and Computer Vision group at Nokia Research Center ! Now the CSSD graphics software technical lead at Texas Instruments working on OMAP Introduction ! Mobile 3D hardware is not a “Mini-me” of your desktop PC. ! To obtain similar features and relatively high levels of performance, mobile hardware has made some tradeoffs compared to the power of your desktop Introduction… ! If you are just learning mobile 3D or have learned about graphics and performance on a more “traditional” platform such as a PC or console, this presentation should help you: ! Recognize the most important areas in mobile power and performance for 3D and game development ! Take appropriate lessons learned from desktop development whenever possible… ! Avoid lessons from the desktop which can make your game slower or more power-hungry than it could be! Mobile performance preview ! Some you know, some you may not… Sorted by acronym the main problems are: ! CPU ! GPU ! Memory ! Your game The Mobile CPU ! No, it doesn’t have a Hemi. The Mobile GPU ! No, there’s not really a tiny 3dfx Voodoo™ card in that handset Mobile Memory ! It’s SLOOOOOOOW….
    [Show full text]
  • AMD Radeon E8860
    Components for AMD’s Embedded Radeon™ E8860 GPU INTRODUCTION The E8860 Embedded Radeon GPU available from CoreAVI is comprised of temperature screened GPUs, safety certi- fiable OpenGL®-based drivers, and safety certifiable GPU tools which have been pre-integrated and validated together to significantly de-risk the challenges typically faced when integrating hardware and software components. The plat- form is an off-the-shelf foundation upon which safety certifiable applications can be built with confidence. Figure 1: CoreAVI Support for E8860 GPU EXTENDED TEMPERATURE RANGE CoreAVI provides extended temperature versions of the E8860 GPU to facilitate its use in rugged embedded applications. CoreAVI functionally tests the E8860 over -40C Tj to +105 Tj, increasing the manufacturing yield for hardware suppliers while reducing supply delays to end customers. coreavi.com [email protected] Revision - 13Nov2020 1 E8860 GPU LONG TERM SUPPLY AND SUPPORT CoreAVI has provided consistent and dedicated support for the supply and use of the AMD embedded GPUs within the rugged Mil/Aero/Avionics market segment for over a decade. With the E8860, CoreAVI will continue that focused support to ensure that the software, hardware and long-life support are provided to meet the needs of customers’ system life cy- cles. CoreAVI has extensive environmentally controlled storage facilities which are used to store the GPUs supplied to the Mil/ Aero/Avionics marketplace, ensuring that a ready supply is available for the duration of any program. CoreAVI also provides the post Last Time Buy storage of GPUs and is often able to provide additional quantities of com- ponents when COTS hardware partners receive increased volume for existing products / systems requiring additional inventory.
    [Show full text]
  • John Carmack Archive - .Plan (1998)
    John Carmack Archive - .plan (1998) http://www.team5150.com/~andrew/carmack March 18, 2007 Contents 1 January 5 1.1 Some of the things I have changed recently (Jan 01, 1998) . 5 1.2 Jan 02, 1998 ............................ 6 1.3 New stuff fixed (Jan 03, 1998) ................. 7 1.4 Version 3.10 patch is now out. (Jan 04, 1998) ......... 8 1.5 Jan 09, 1998 ............................ 9 1.6 I AM GOING OUT OF TOWN NEXT WEEK, DON’T SEND ME ANY MAIL! (Jan 11, 1998) ................. 10 2 February 12 2.1 Ok, I’m overdue for an update. (Feb 04, 1998) ........ 12 2.2 Just got back from the Q2 wrap party in vegas that Activi- sion threw for us. (Feb 09, 1998) ................ 14 2.3 Feb 12, 1998 ........................... 15 2.4 8 mb or 12 mb voodoo 2? (Feb 16, 1998) ........... 19 2.5 I just read the Wired article about all the Doom spawn. (Feb 17, 1998) .......................... 20 2.6 Feb 22, 1998 ........................... 21 1 John Carmack Archive 2 .plan 1998 3 March 22 3.1 American McGee has been let go from Id. (Mar 12, 1998) . 22 3.2 The Old Plan (Mar 13, 1998) .................. 22 3.3 Mar 20, 1998 ........................... 25 3.4 I just shut down the last of the NEXTSTEP systems running at id. (Mar 21, 1998) ....................... 26 3.5 Mar 26, 1998 ........................... 28 4 April 30 4.1 Drag strip day! (Apr 02, 1998) ................. 30 4.2 Things are progressing reasonably well on the Quake 3 en- gine. (Apr 08, 1998) ....................... 31 4.3 Apr 16, 1998 ..........................
    [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]
  • 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]
  • Efficient Algorithms for Large-Scale Image Analysis
    Efficient Algorithms for Large-Scale Image Analysis zur Erlangung des akademischen Grades eines Doktors der Ingenieurwissenschaften der Fakultät für Informatik des Karlsruher Instituts für Technologie genehmigte Dissertation von Jan Wassenberg aus Koblenz Tag der mündlichen Prüfung: 24. Oktober 2011 Erster Gutachter: Prof. Dr. Peter Sanders Zweiter Gutachter: Prof. Dr.-Ing. Jürgen Beyerer Abstract The past decade has seen major improvements in the capabilities and availability of imaging sensor systems. Commercial satellites routinely provide panchromatic images with sub-meter resolution. Airborne line scanner cameras yield multi-spectral data with a ground sample distance of 5 cm. The resulting overabundance of data brings with it the challenge of timely analysis. Fully auto- mated processing still appears infeasible, but an intermediate step might involve a computer-assisted search for interesting objects. This would reduce the amount of data for an analyst to examine, but remains a challenge in terms of processing speed and working memory. This work begins by discussing the trade-offs among the various hardware architectures that might be brought to bear upon the problem. FPGA and GPU-based solutions are less universal and entail longer development cycles, hence the choice of commodity multi-core CPU architectures. Distributed processing on a cluster is deemed too costly. We will demonstrate the feasibility of processing aerial images of 100 km × 100 km areas at 1 m resolution within 2 hours on a single workstation with two processors and a total of twelve cores. Because existing approaches cannot cope with such amounts of data, each stage of the image processing pipeline – from data access and signal processing to object extraction and feature computation – will have to be designed from the ground up for maximum performance.
    [Show full text]
  • Texture Mapping  Opengl Has a Pixel Pipeline Along with the Geometry Pipeline (From Processor Memory to Frame Buffer)
    Pixel pipeline Texture Mapping OpenGL has a pixel pipeline along with the geometry pipeline (from processor memory to frame buffer) Tom Shermer Richard (Hao) Zhang There is a whole set of OpenGL functions on pixel Introduction to Computer Graphics manipulation, see OpenGL reference cards CMPT 361 – Lecture 18 Many functions for texture mapping and manipulation 1 2 Texture mapping Texture mapping in OpenGL How to map an image (texture) onto a surface In older versions, 1D and 2D texture mapping Now 3D/solid textures are supported in OpenGL Basic steps of texture mapping, see Chapter 7 in text 1. Generate a texture image and place it in texture memory on the GPU, e.g., glGenTextures(), glBindTexture(), etc. 2. Assign texture coordinates (references to texture image) to Image-related (2D) but also incorporating 3D data each fragment (pixel) in-between, texture mapping between Textures are assigned by texture coordinates image to surface (then fragments) associated with points on a surface 3. Apply texture to each fragment 3 4 1 Why texture mapping? Effect of texture mapping Real-world objects often have complex surface details even of a stochastic nature, e.g., the surface of an orange, patterns on a wood table, etc. Using many small polygons and smooth shading them to capture the details is too expensive A “cheat” : use an image (it is easy to take a photo and digitize it) to capture the details and patterns and paint it onto simple surfaces 5 6 Effect of texture mapping Textures Textures are patterns e.g., stripes, checkerboard,
    [Show full text]
  • Integrating Mali GPU with the Browser
    Integrating Mali GPU with the Browser Wasim Abbas Staff Engineer, Mali Ecosystem 1 What’s Coming? § Introduction § Mali architecture § Optimizing for Mali § Common pitfalls § Questions 2 Introduction § Technical Lead of Middleware graphics team in Mali Ecosystem § Working with Skia, FireFox (Gecko) and WebKit teams (GPU acceleration for The Web) § Have worked with Mali content optimization and creation tools § Past expertise in the Game industry, engine development § Past expertise teaching Game engine architecture § Who are you? 3 Graphics in the Embedded World § Embedded / mobile graphics fundamentally different from PC § Not just a scaled down version of the desktop world § Completely different power and bandwidth budgets § No dedicated GPU memory or bus – all shared with CPU, video, DSP § Need to last days rather than hours on a single battery charge § Requires dedicated solutions § Must handle “PC use cases” with a mobile phone power budget § Maximize processing efficiency in an embedded memory subsystem 4 Optimizing for Mali § Understanding Mali architecture § Understanding your browser and underlying renderer § Understanding OpenGL ES API and what happens under the hood § Multi-level optimizations at system and application level § Optimizations at client level 5 Abstract Rendering Machine glDraw(1) glDraw(2) glDraw(3) eglSwapBuffers() Original article from Peter Harris at http://community.arm.com/groups/arm-mali-graphics/blog/2014/02/03/the-mali-gpu-an-abstract-machine-part-1 6 Abstract Rendering Machine Synchronous API, asynchronous
    [Show full text]
  • Matrox in the New Millennium: Parhelia Reviewed Matrox in the New Millennium: Parhelia Reviewed by Brian Neal – July 2002
    Ace’s Hardware Matrox in the New Millennium: Parhelia Reviewed Matrox in the New Millennium: Parhelia Reviewed By Brian Neal – July 2002 Introduction For some time following the introduction of the Matrox G400 and later the G450, we heard rumors about a "G800" project. About a year and a month ago, Matrox introduced the world to the G550. But the G550 lacked the performance and features of its competitors, and was relegated mostly to 2D work. The G550 was more an evolution of the G450 than anything else, but this time, things are different. Matrox's new Parhelia is an all-new design, incorporating modern features such as Direct X 8.1-compliant pixel and vertex shaders. The G550's 166 MHz 64-bit DDR SDRAM memory interface has been replaced with a far more robust 275 MHz (250 MHz OEM/bulk) 256-bit DDR SDRAM interface capable of 17.6 GB/s. This combined with some interesting and innovative features like hardware displacement-mapping, triple-head surround gaming, and the prospects for Matrox's next- generation product are looking quite good. The Matrox Parhelia But not everything is looking so bright for Parhelia. Manufactured on a 0.15µ process, the 80 million transistor GPU is quite large and also quite hot. Consequently, it currently clocks in at only 220 MHz. To contrast, compare the GeForce 4 Ti4400's 300 MHz clockrate. The low clockrate is compounded by a lack of hardware occlusion culling, which means the quad-pipeline renderer is significantly less efficient than many other contemporary designs when it comes to overdraw.
    [Show full text]