DOCSLIB.ORG

Shaders Traditional Rendering Pipeline

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Shaders Traditional Rendering Pipeline Shaders (some slides taken from David M. course) Doron Nussbaum Doron Nussbaum COMP 3501 - Shaders 1 Traditional Rendering Pipeline • Traditional pipeline (older graphics Vertex Pixel Operations Operations cards) restricts developer to texture and the 3-term lighting model Rasterization Transformation and • Pixel information was interpolated to Lighting vertices Pixel Colouring Texture Mapping Primitive • Shaders Assembly – Lift the restrictions Per pixel – Allow developers to manipulate operation (Blending) outcome Viewport Culling • Result Clipping – vertex shaders Frame buffer – Pixel/fragment shaders operations Doron Nussbaum COMP 3501 - Shaders 2 Vertex Shader • Act in parallel across all vertices • Responsible for transforming – Initial lighting of vertex Transformation and Vertex Shader – Vertex transformation Lighting – Normal transformation & normalization – Texture coordinate generation & transformation Primitive Assembly • Compute temporary variables to be consumed by fragment shader Viewport Culling Clipping • Per-vertex processing – only information from one vertex available Doron Nussbaum COMP 3501 - Shaders 3 Fragment (pixel) Shader • Act in parallel across all fragments Rasterization • Responsible for computing depth and color information Pixel Colouring Texture Mapping Pixel Shader • Only information from current fragment available Per pixel operation – Operations on interpolated values (Blending) – Texture access (multipass shaders) Frame buffer • Produces Colour operations Doron Nussbaum COMP 3501 - Shaders 4 Shading languages (last) • High level shading languages available • Three main ones: – Cg (NVIDIA's "C for graphics") – HLSL (MS's "high level shading language") – GLSL (OpenGL's shading language) • All quite similar, differ in details of API • DirectX – shader code is added during runtime – Shader code is written in a separate file – Requires “transfer” of data to the shader code Doron Nussbaum COMP 3501 - Shaders 5 The Graphics Pipeline Transformations Vertex Clipping & Lighting Shading Rasterization and Interpolation Texturin Frame Buffer Pixel Shading g Operations Doron Nussbaum COMP 3501 - Shaders 6 6 Vertex Shader(s) • Replaces fixed functionality of vertex processor • Normally get: – vertex transformation – normal transformation – illumination • Now, can write programs that do anything – same program on all vertices Doron Nussbaum COMP 3501 - Shaders 7 7 Vertex Shaders • Input: – Built-in attributes • color • normal • position • texture coordinate – User-defined attributes – Texture maps Doron Nussbaum COMP 3501 - Shaders 8 8 Vertex Shaders • Transform and light a single vertex • Output: – position – color – user-defined variables (for fragment shader) Doron Nussbaum COMP 3501 - Shaders 9 9 Vertex Shader • Changing vertex position in a shader – create simple animations • Use time as input, compute x(t), θ(t) – perform displacement mapping (to mesh resolution) – Generally, modify the geometry at runtime Doron Nussbaum COMP 3501 - Shaders 10 10 Rasterization and Interpolation • Turns the space between vertices into fragments • Computes input values for fragments by interpolating values from vertices Doron Nussbaum COMP 3501 - Shaders 11 11 Pixel Shader • Operates on fragments • Input: – color – texture coordinates – user-defined variables (from vertex shader) – texture maps • Cannot access other pixels – although, texture can be exploited for this Doron Nussbaum COMP 3501 - Shaders 12 12 Pixel Shader • Output: – color (RGBA) – depth • Note, cannot change position at this point • But, can compute color in sophisticated way, in parallel at each pixel Doron Nussbaum COMP 3501 - Shaders 13 13 Shader input • Previously mentioned inputs available per- vertex (per-pixel) • Also have shader parameters that can be set (like global variables) – E.g., direction of sun, location of viewer (same for all primitives) – E.g., specific parameters (material glossiness, what texture to use) Doron Nussbaum COMP 3501 - Shaders 14 14 Phong and Gouraud Shading • Traditional Gouraud shading: per-vertex lighting, interpolated to pixels • Various problems: – Visible mesh boundaries – Strange effects at low mesh resolution • Phong shading: normals interpolated, per- pixel lighting: done in pixel shader Doron Nussbaum COMP 3501 - Shaders 15 15 Render to Texture • Shaders are “memoryless” • Also, limit to how many instructions in shader (varies with card) • Can render display buffer to texture, then use texture as input to later (or same) shader – Or, just display texture on object • eg, mirror Doron Nussbaum COMP 3501 - Shaders 16 16 Render to Texture • Simple postprocessing effects: – render to texture – apply pixel shader involving texture – draw texture to screen • Create quad covering screen, apply texture • Color modification, darken/brighten, fade/dissolve Doron Nussbaum COMP 3501 - Shaders 17 17 Shaders in DirectX • Write a single .fx file with: – list of shader parameters – structure definitions for shader I/O – vertex shader – pixel shader – technique and pass definition Doron Nussbaum COMP 3501 - Shaders 18 18 Data flow Vertex Vertex Shader Shader Input Pixel Pixel Shader Shader Input Pixel Shader Doron Nussbaum COMP 3501 - Shaders 19 Output 19 Shader I/O Semantics • Markers that suggest how data is passed into and out of the shaders – e.g., put "position" data in POSITION semantic • Example vertex shader input: struct vs_in { float4 pos : POSITION0; float4 col : COLOR0; }; Doron Nussbaum COMP 3501 - Shaders 20 20 Available semantics • Differ depending on what the structure is – position semantic not available for pixel shader output, for example • TEXCOORD semantic for user-defined variables • Can be used multiple times: TEXCOORD0 for first, then TEXCOORD1, TEXCOORD2... Doron Nussbaum COMP 3501 - Shaders 21 21 Vertex Shader Input Semantics • POSITION – vertex location in space • COLOR – for the vertex color • NORMAL – surface normal • TEXCOORD – texture coordinates, also "generic" • PSIZE – point size (used with point sprites, chiefly for particle system effects) Doron Nussbaum COMP 3501 - Shaders 22 22 Vertex Shader Output Semantics • subset of the inputs • POSITION •COLOR •TEXCOORD • PSIZE Doron Nussbaum COMP 3501 - Shaders 23 23 Pixel Shader Input Semantics • Only COLOR and TEXCOORD are allowed • Note: considered good practice to use vertex shader output as pixel shader input – but permitted semantics different! – notably, POSITION required for vs_out, prohibited by ps_in • "Illegal" semantics ignored by compiler in definition, but DO NOT USE in ps code Doron Nussbaum COMP 3501 - Shaders 24 24 Pixel Shader Output Semantics • COLOR • DEPTH – depth value for depth test • In routine operation, one color value (ultimate pixel color) and one depth value • Can have more outputs if multipass shader, unconventional operation Doron Nussbaum COMP 3501 - Shaders 25 25 Techniques and Passes technique mytechnique { // one or more passes, ordinarily one pass mypass { vertexshader = compile vs_1_1 myvs(); pixelshader = compile ps_2_0 myps(); } } Doron Nussbaum COMP 3501 - Shaders 26 26 Shader Code • Written in C-like HLSL – if, for, = for assignment... • scalar, vector, and matrix types – int, float – float2, float3, float4 – float4x4 • Texture type (2D texture) Doron Nussbaum COMP 3501 - Shaders 27 27 Intrinsic Functions • Some functions are built in • Various mathematical functions – math (exp, pow, log) – trigonometric (sin, cos, tan, asin...) – vector (dot, cross) – "housekeeping" (clamp, lerp, abs, max) • Functions for dealing with texture • Partial list (common ones) in textbook Doron Nussbaum COMP 3501 - Shaders 28 28 Shader Code • Take control of the pipeline • Very abstract right now, but examples to come in the following weeks –texture – procedural texture – basic lighting (Phong shading) – specialized lighting – particle systems Doron Nussbaum COMP 3501 - Shaders 29 29 Connecting your Shader • May need a custom vertex format, if your vertex shader input is different from all existing vertex formats • Set all your parameters • Link to project, configure Doron Nussbaum COMP 3501 - Shaders 30 30 Recap • Can program parts of the graphics pipeline – vertex shader • output is position, color, texture coordinates – pixel shader • output is color • for DirectX, use HLSL, a C-like language with many built-in functions Doron Nussbaum COMP 3501 - Shaders 31 Recap • Things to know: – graphics pipeline • tasks of vertex and pixel shaders • rasterization and interpolation – vertex and pixel shader input and output semantics • To learn by practice: writing your own shaders Doron Nussbaum COMP 3501 - Shaders 32.
Load more

Recommended publications
  • GLSL 4.50 Spec
    The OpenGL® Shading Language Language Version: 4.50 Document Revision: 7 09-May-2017 Editor: John Kessenich, Google Version 1.1 Authors: John Kessenich, Dave Baldwin, Randi Rost Copyright (c) 2008-2017 The Khronos Group Inc. All Rights Reserved. This specification is protected by copyright laws and contains material proprietary to the Khronos Group, Inc. It or any components may not be reproduced, republished, distributed, transmitted, displayed, broadcast, or otherwise exploited in any manner without the express prior written permission of Khronos Group. You may use this specification for implementing the functionality therein, without altering or removing any trademark, copyright or other notice from the specification, but the receipt or possession of this specification does not convey any rights to reproduce, disclose, or distribute its contents, or to manufacture, use, or sell anything that it may describe, in whole or in part. Khronos Group grants express permission to any current Promoter, Contributor or Adopter member of Khronos to copy and redistribute UNMODIFIED versions of this specification in any fashion, provided that NO CHARGE is made for the specification and the latest available update of the specification for any version of the API is used whenever possible. Such distributed specification may be reformatted AS LONG AS the contents of the specification are not changed in any way. The specification may be incorporated into a product that is sold as long as such product includes significant independent work developed by the seller. A link to the current version of this specification on the Khronos Group website should be included whenever possible with specification distributions.
    [Show full text]
  • First Person Shooting (FPS) Game
    International Research Journal of Engineering and Technology (IRJET) e-ISSN: 2395-0056 Volume: 05 Issue: 04 | Apr-2018 www.irjet.net p-ISSN: 2395-0072 Thunder Force - First Person Shooting (FPS) Game Swati Nadkarni1, Panjab Mane2, Prathamesh Raikar3, Saurabh Sawant4, Prasad Sawant5, Nitesh Kuwalekar6 1 Head of Department, Department of Information Technology, Shah & Anchor Kutchhi Engineering College 2 Assistant Professor, Department of Information Technology, Shah & Anchor Kutchhi Engineering College 3,4,5,6 B.E. student, Department of Information Technology, Shah & Anchor Kutchhi Engineering College ----------------------------------------------------------------***----------------------------------------------------------------- Abstract— It has been found in researches that there is an have challenged hardware development, and multiplayer association between playing first-person shooter video games gaming has been integral. First-person shooters are a type of and having superior mental flexibility. It was found that three-dimensional shooter game featuring a first-person people playing such games require a significantly shorter point of view with which the player sees the action through reaction time for switching between complex tasks, mainly the eyes of the player character. They are unlike third- because when playing fps games they require to rapidly react person shooters in which the player can see (usually from to fast moving visuals by developing a more responsive mind behind) the character they are controlling. The primary set and to shift back and forth between different sub-duties. design element is combat, mainly involving firearms. First person-shooter games are also of ten categorized as being The successful design of the FPS game with correct distinct from light gun shooters, a similar genre with a first- direction, attractive graphics and models will give the best person perspective which uses light gun peripherals, in experience to play the game.
    [Show full text]
  • Advanced Computer Graphics to Do Motivation Real-Time Rendering
    To Do Advanced Computer Graphics § Assignment 2 due Feb 19 § Should already be well on way. CSE 190 [Winter 2016], Lecture 12 § Contact us for difficulties etc. Ravi Ramamoorthi http://www.cs.ucsd.edu/~ravir Motivation Real-Time Rendering § Today, create photorealistic computer graphics § Goal: interactive rendering. Critical in many apps § Complex geometry, lighting, materials, shadows § Games, visualization, computer-aided design, … § Computer-generated movies/special effects (difficult or impossible to tell real from rendered…) § Until 10-15 years ago, focus on complex geometry § CSE 168 images from rendering competition (2011) § § But algorithms are very slow (hours to days) Chasm between interactivity, realism Evolution of 3D graphics rendering Offline 3D Graphics Rendering Interactive 3D graphics pipeline as in OpenGL Ray tracing, radiosity, photon mapping § Earliest SGI machines (Clark 82) to today § High realism (global illum, shadows, refraction, lighting,..) § Most of focus on more geometry, texture mapping § But historically very slow techniques § Some tweaks for realism (shadow mapping, accum. buffer) “So, while you and your children’s children are waiting for ray tracing to take over the world, what do you do in the meantime?” Real-Time Rendering SGI Reality Engine 93 (Kurt Akeley) Pictures courtesy Henrik Wann Jensen 1 New Trend: Acquired Data 15 years ago § Image-Based Rendering: Real/precomputed images as input § High quality rendering: ray tracing, global illumination § Little change in CSE 168 syllabus, from 2003 to
    [Show full text]
  • Developer Tools Showcase
    Developer Tools Showcase Randy Fernando Developer Tools Product Manager NVISION 2008 Software Content Creation Performance Education Development FX Composer Shader PerfKit Conference Presentations Debugger mental mill PerfHUD Whitepapers Artist Edition Direct3D SDK PerfSDK GPU Programming Guide NVIDIA OpenGL SDK Shader Library GLExpert Videos CUDA SDK NV PIX Plug‐in Photoshop Plug‐ins Books Cg Toolkit gDEBugger GPU Gems 3 Texture Tools NVSG GPU Gems 2 Melody PhysX SDK ShaderPerf GPU Gems PhysX Plug‐Ins PhysX VRD PhysX Tools The Cg Tutorial NVIDIA FX Composer 2.5 The World’s Most Advanced Shader Authoring Environment DirectX 10 Support NVIDIA Shader Debugger Support ShaderPerf 2.0 Integration Visual Models & Styles Particle Systems Improved User Interface Particle Systems All-New Start Page 350Z Sample Project Visual Models & Styles Other Major Features Shader Creation Wizard Code Editor Quickly create common shaders Full editor with assisted Shader Library code generation Hundreds of samples Properties Panel Texture Viewer HDR Color Picker Materials Panel View, organize, and apply textures Even More Features Automatic Light Binding Complete Scripting Support Support for DirectX 10 (Geometry Shaders, Stream Out, Texture Arrays) Support for COLLADA, .FBX, .OBJ, .3DS, .X Extensible Plug‐in Architecture with SDK Customizable Layouts Semantic and Annotation Remapping Vertex Attribute Packing Remote Control Capability New Sample Projects 350Z Visual Styles Atmospheric Scattering DirectX 10 PCSS Soft Shadows Materials Post‐Processing Simple Shadows
    [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]
  • Slang: Language Mechanisms for Extensible Real-Time Shading Systems
    Slang: language mechanisms for extensible real-time shading systems YONG HE, Carnegie Mellon University KAYVON FATAHALIAN, Stanford University TIM FOLEY, NVIDIA Designers of real-time rendering engines must balance the conicting goals and GPU eciently, and minimizing CPU overhead using the new of maintaining clear, extensible shading systems and achieving high render- parameter binding model oered by the modern Direct3D 12 and ing performance. In response, engine architects have established eective de- Vulkan graphics APIs. sign patterns for authoring shading systems, and developed engine-specic To help navigate the tension between performance and maintain- code synthesis tools, ranging from preprocessor hacking to domain-specic able/extensible code, engine architects have established eective shading languages, to productively implement these patterns. The problem is design patterns for authoring shading systems, and developed code that proprietary tools add signicant complexity to modern engines, lack ad- vanced language features, and create additional challenges for learning and synthesis tools, ranging from preprocessor hacking, to metapro- adoption. We argue that the advantages of engine-specic code generation gramming, to engine-proprietary domain-specic languages (DSLs) tools can be achieved using the underlying GPU shading language directly, [Tatarchuk and Tchou 2017], for implementing these patterns. For provided the shading language is extended with a small number of best- example, the idea of shader components [He et al. 2017] was recently practice principles from modern, well-established programming languages. presented as a pattern for achieving both high rendering perfor- We identify that adding generics with interface constraints, associated types, mance and maintainable code structure when specializing shader and interface/structure extensions to existing C-like GPU shading languages code to coarse-grained features such as a surface material pattern or enables real-time renderer developers to build shading systems that are a tessellation eect.
    [Show full text]
  • NVIDIA Quadro P620
    UNMATCHED POWER. UNMATCHED CREATIVE FREEDOM. NVIDIA® QUADRO® P620 Powerful Professional Graphics with FEATURES > Four Mini DisplayPort 1.4 Expansive 4K Visual Workspace Connectors1 > DisplayPort with Audio The NVIDIA Quadro P620 combines a 512 CUDA core > NVIDIA nView® Desktop Pascal GPU, large on-board memory and advanced Management Software display technologies to deliver amazing performance > HDCP 2.2 Support for a range of professional workflows. 2 GB of ultra- > NVIDIA Mosaic2 fast GPU memory enables the creation of complex 2D > Dedicated hardware video encode and decode engines3 and 3D models and a flexible single-slot, low-profile SPECIFICATIONS form factor makes it compatible with even the most GPU Memory 2 GB GDDR5 space and power-constrained chassis. Support for Memory Interface 128-bit up to four 4K displays (4096x2160 @ 60 Hz) with HDR Memory Bandwidth Up to 80 GB/s color gives you an expansive visual workspace to view NVIDIA CUDA® Cores 512 your creations in stunning detail. System Interface PCI Express 3.0 x16 Quadro cards are certified with a broad range of Max Power Consumption 40 W sophisticated professional applications, tested by Thermal Solution Active leading workstation manufacturers, and backed by Form Factor 2.713” H x 5.7” L, a global team of support specialists, giving you the Single Slot, Low Profile peace of mind to focus on doing your best work. Display Connectors 4x Mini DisplayPort 1.4 Whether you’re developing revolutionary products or Max Simultaneous 4 direct, 4x DisplayPort telling spectacularly vivid visual stories, Quadro gives Displays 1.4 Multi-Stream you the performance to do it brilliantly.
    [Show full text]
  • Opengl Shading Languag 2Nd Edition (Orange Book)
    OpenGL® Shading Language, Second Edition By Randi J. Rost ............................................... Publisher: Addison Wesley Professional Pub Date: January 25, 2006 Print ISBN-10: 0-321-33489-2 Print ISBN-13: 978-0-321-33489-3 Pages: 800 Table of Contents | Index "As the 'Red Book' is known to be the gold standard for OpenGL, the 'Orange Book' is considered to be the gold standard for the OpenGL Shading Language. With Randi's extensive knowledge of OpenGL and GLSL, you can be assured you will be learning from a graphics industry veteran. Within the pages of the second edition you can find topics from beginning shader development to advanced topics such as the spherical harmonic lighting model and more." David Tommeraasen, CEO/Programmer, Plasma Software "This will be the definitive guide for OpenGL shaders; no other book goes into this detail. Rost has done an excellent job at setting the stage for shader development, what the purpose is, how to do it, and how it all fits together. The book includes great examples and details, and good additional coverage of 2.0 changes!" Jeffery Galinovsky, Director of Emerging Market Platform Development, Intel Corporation "The coverage in this new edition of the book is pitched just right to help many new shader- writers get started, but with enough deep information for the 'old hands.'" Marc Olano, Assistant Professor, University of Maryland "This is a really great book on GLSLwell written and organized, very accessible, and with good real-world examples and sample code. The topics flow naturally and easily, explanatory code fragments are inserted in very logical places to illustrate concepts, and all in all, this book makes an excellent tutorial as well as a reference." John Carey, Chief Technology Officer, C.O.R.E.
    [Show full text]
  • Nvidia Quadro T1000
    NVIDIA professional laptop GPUs power the world’s most advanced thin and light mobile workstations and unique compact devices to meet the visual computing needs of professionals across a wide range of industries. The latest generation of NVIDIA RTX professional laptop GPUs, built on the NVIDIA Ampere architecture combine the latest advancements in real-time ray tracing, advanced shading, and AI-based capabilities to tackle the most demanding design and visualization workflows on the go. With the NVIDIA PROFESSIONAL latest graphics technology, enhanced performance, and added compute power, NVIDIA professional laptop GPUs give designers, scientists, and artists the tools they need to NVIDIA MOBILE GRAPHICS SOLUTIONS work efficiently from anywhere. LINE CARD GPU SPECIFICATIONS PERFORMANCE OPTIONS 2 1 ® / TXAA™ Anti- ® ™ 3 4 * 5 NVIDIA FXAA Aliasing Manager NVIDIA RTX Desktop Support Vulkan NVIDIA Optimus NVIDIA CUDA NVIDIA RT Cores Cores Tensor GPU Memory Memory Bandwidth* Peak Memory Type Memory Interface Consumption Max Power TGP DisplayPort Open GL Shader Model DirectX PCIe Generation Floating-Point Precision Single Peak)* (TFLOPS, Performance (TFLOPS, Performance Tensor Peak) Gen MAX-Q Technology 3rd NVENC / NVDEC Processing Cores Processing Laptop GPUs 48 (2nd 192 (3rd NVIDIA RTX A5000 6,144 16 GB 448 GB/s GDDR6 256-bit 80 - 165 W* 1.4 4.6 7.0 12 Ultimate 4 21.7 174.0 Gen) Gen) 40 (2nd 160 (3rd NVIDIA RTX A4000 5,120 8 GB 384 GB/s GDDR6 256-bit 80 - 140 W* 1.4 4.6 7.0 12 Ultimate 4 17.8 142.5 Gen) Gen) 32 (2nd 128 (3rd NVIDIA RTX A3000
    [Show full text]
  • Opengl 4.0 Shading Language Cookbook
    OpenGL 4.0 Shading Language Cookbook Over 60 highly focused, practical recipes to maximize your use of the OpenGL Shading Language David Wolff BIRMINGHAM - MUMBAI OpenGL 4.0 Shading Language Cookbook Copyright © 2011 Packt Publishing All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews. Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing, and its dealers and distributors will be held liable for any damages caused or alleged to be caused directly or indirectly by this book. Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information. First published: July 2011 Production Reference: 1180711 Published by Packt Publishing Ltd. 32 Lincoln Road Olton Birmingham, B27 6PA, UK. ISBN 978-1-849514-76-7 www.packtpub.com Cover Image by Fillipo ([email protected]) Credits Author Project Coordinator David Wolff Srimoyee Ghoshal Reviewers Proofreader Martin Christen Bernadette Watkins Nicolas Delalondre Indexer Markus Pabst Hemangini Bari Brandon Whitley Graphics Acquisition Editor Nilesh Mohite Usha Iyer Valentina J. D’silva Development Editor Production Coordinators Chris Rodrigues Kruthika Bangera Technical Editors Adline Swetha Jesuthas Kavita Iyer Cover Work Azharuddin Sheikh Kruthika Bangera Copy Editor Neha Shetty About the Author David Wolff is an associate professor in the Computer Science and Computer Engineering Department at Pacific Lutheran University (PLU).
    [Show full text]
  • A Qualitative Comparison Study Between Common GPGPU Frameworks
    A Qualitative Comparison Study Between Common GPGPU Frameworks. Adam Söderström Department of Computer and Information Science Linköping University This dissertation is submitted for the degree of M. Sc. in Media Technology and Engineering June 2018 Acknowledgements I would like to acknowledge MindRoad AB and Åsa Detterfelt for making this work possible. I would also like to thank Ingemar Ragnemalm and August Ernstsson at Linköping University. Abstract The development of graphic processing units have during the last decade improved signif- icantly in performance while at the same time becoming cheaper. This has developed a new type of usage of the device where the massive parallelism available in modern GPU’s are used for more general purpose computing, also known as GPGPU. Frameworks have been developed just for this purpose and some of the most popular are CUDA, OpenCL and DirectX Compute Shaders, also known as DirectCompute. The choice of what framework to use may depend on factors such as features, portability and framework complexity. This paper aims to evaluate these concepts, while also comparing the speedup of a parallel imple- mentation of the N-Body problem with Barnes-hut optimization, compared to a sequential implementation. Table of contents List of figures xi List of tables xiii Nomenclature xv 1 Introduction1 1.1 Motivation . .1 1.2 Aim . .3 1.3 Research questions . .3 1.4 Delimitations . .4 1.5 Related work . .4 1.5.1 Framework comparison . .4 1.5.2 N-Body with Barnes-Hut . .5 2 Theory9 2.1 Background . .9 2.1.1 GPGPU History . 10 2.2 GPU Architecture .
    [Show full text]
  • Graphics Shaders Mike Hergaarden January 2011, VU Amsterdam
    Graphics shaders Mike Hergaarden January 2011, VU Amsterdam [Source: http://unity3d.com/support/documentation/Manual/Materials.html] Abstract Shaders are the key to finalizing any image rendering, be it computer games, images or movies. Shaders have greatly improved the output of computer generated media; from photo-realistic computer generated humans to more vivid cartoon movies. Furthermore shaders paved the way to general-purpose computation on GPU (GPGPU). This paper introduces shaders by discussing the theory and practice. Introduction A shader is a piece of code that is executed on the Graphics Processing Unit (GPU), usually found on a graphics card, to manipulate an image before it is drawn to the screen. Shaders allow for various kinds of rendering effect, ranging from adding an X-Ray view to adding cartoony outlines to rendering output. The history of shaders starts at LucasFilm in the early 1980’s. LucasFilm hired graphics programmers to computerize the special effects industry [1]. This proved a success for the film/ rendering industry, especially at Pixars Toy Story movie launch in 1995. RenderMan introduced the notion of Shaders; “The Renderman Shading Language allows material definitions of surfaces to be described in not only a simple manner, but also highly complex and custom manner using a C like language. Using this method as opposed to a pre-defined set of materials allows for complex procedural textures, new shading models and programmable lighting. Another thing that sets the renderers based on the RISpec apart from many other renderers, is the ability to output arbitrary variables as an image—surface normals, separate lighting passes and pretty much anything else can be output from the renderer in one pass.” [1] The term shader was first only used to refer to “pixel shaders”, but soon enough new uses of shaders such as vertex and geometry shaders were introduced, making the term shaders more general.
    [Show full text]