USING BINDLESS RESOURCES with DIRECTX RAYTRACING Matt Pettineo Ready at Dawn Studios

Total Page:16

File Type:pdf, Size:1020Kb

USING BINDLESS RESOURCES with DIRECTX RAYTRACING Matt Pettineo Ready at Dawn Studios CHAPTER 17 USING BINDLESS RESOURCES WITH DIRECTX RAYTRACING Matt Pettineo Ready At Dawn Studios ABSTRACT Resource binding in Direct3D 12 can be complex and diffcult to implement correctly, particularly when used in conjunction with DirectX Raytracing. This chapter will explain how to use bindless techniques to provide shaders with global access to all resources, which can simplify application and shader code while also enabling new techniques. 17.1 INTRODUCTION Prior to the introduction of Direct3D 12, GPU texture and buffer resources were accessed using a simple CPU-driven binding model. The GPU’s resource access capabilities were typically exposed as a fxed set of “slots” that were Figure 17-1. The Unreal Engine Sun Temple scene [5] rendered with an open source DXR path tracer [9] that uses bindless resources. © NVIDIA 2021 A. Marrs, P. Shirley, I. Wald (eds.), Ray Tracing Gems II, https://doi.org/10.1007/978-1-4842-7185-8_17 257 RAY TRACING GEMS II tied to a particular stage of the logical GPU pipeline, and API functions were provided that allowed the GPU to “bind” a resource view to one of the exposed slots. This sort of binding model was a natural ft for earlier GPUs, which typically featured a fxed set of hardware descriptor registers that were used by the shader cores to access resources. While this old style of binding was relatively simple and well understood, it naturally came with many limitations. The limited nature of the binding slots meant that programs could typically only bind the exact set of resources that would be accessed by a particular shader program, which would often have to be done before every draw or dispatch. The CPU-driven nature of binding demanded that a shader’s required resources had to be statically known after compilation, which naturally led to inherent restrictions on the complexity of a shader program. As ray tracing on the GPU started to gain traction, the classic binding model reached its breaking point. Ray tracing tends to be an inherently global process: one shader program might launch rays that could potentially interact with every material in the scene. This is largely incompatible with the notion of having the CPU bind a fxed set of resources prior to dispatch. Techniques such as atlasing or Sparse Virtual Texturing [1] can be viable as a means of emulating global resource access, but may also require adding signifcant complexity to a renderer. Fortunately, newer GPUs and APIs no longer suffer from the same limitations. Most recent GPU architectures have shifted to a model where resource descriptors can be loaded from memory instead of from registers, and in some cases they can also access resources directly from a memory address. This removes the prior restrictions on the number of resources that can be accessed by a particular shader program, and also opens the door for those shader programs to dynamically choose which resource is actually accessed. This newfound fexibility is directly refected in the binding model of Direct3D 12, which has been completely revamped compared to previous versions of the API. In particular, it supports features that collectively enable a technique commonly known as bindless resources [2]. When implemented, bindless techniques effectively provide shader programs with full global access to the full set of textures and buffers that are present on the GPU. Instead of requiring the CPU to bind a view for each individual resource, shaders can instead access an individual resource using a simple 32-bit index that can be 258 CHAPTER 17. USING BINDLESS RESOURCES WITH DIRECTX RAYTRACING freely embedded in user-defned data structures. While this level of fexibility can be incredibly useful in more traditional rasterization scenarios [6], they are borderline essential when using DirectX Raytracing (DXR). The remainder of this chapter will cover the details of how to enable bindless resource access using Direct3D 12 (D3D12), and will also cover the basics of how to use bindless techniques in a DXR ray tracer. Basic familiarity with both D3D12 and DXR is assumed, and we refer the reader to an introductory chapter from the frst volume of Ray Tracing Gems [11]. 17.2 TRADITIONAL BINDING WITH DXR Like the rest of D3D12, DXR utilizes root signatures to specify how resources should be made available to shader programs. These root signatures specify collections of root descriptors, descriptor tables, and 32-bit constants and map those to ranges of HLSL binding registers. When using DXR, we actually deal with two different types of root signatures: a global root signature and a local root signature. The global root signature is applicable to the ray generation shader as well as all executed miss, any-hit, closest-hit, and intersection shaders. The local root signature only applies to a particular hit group. Used together, global and local root signatures can implement a fairly traditional binding model where the CPU code “pushes” descriptors for all resources that are needed by the shader program. In a typical rendering scenario, this would likely involve having the local root signature provide a descriptor table containing all textures and constant buffers required by the particular material assigned to the mesh in the hit group. An example of this traditional model of resource binding is shown in Figure 17-2. Though this approach can be workable, there are several problems that make it less than ideal. First, the mechanics of the local root signature are somewhat inconsistent with how root signatures normally work within D3D12. Standard root signatures require using command list APIs to specify which constants, root descriptors, and descriptor table should be bound to corresponding entries in the root signature. Local root signatures do not work this way because there can be many different root signatures contained within a single state object. Instead, the parameters for the root signature entries must be placed inline within a shader record in the hit group shader table, immediately following the shader identifer. This setup is further complicated by the fact that both shader records and root signature parameters have specifc alignment requirements that must be observed. Shader identifers 259 RAY TRACING GEMS II Root Signature Descriptor Heap SRV Table A SRV Table B Descriptor 17 Root CBV Descriptor 18 Descriptor 19 Descriptor 23 Descriptor 24 Descriptor 25 Constants Figure 17-2. An example of traditional resource binding in D3D12. A root signature contains two entries for Shader Resource View (SRV) descriptor tables, each of which point to a range of contiguous SRV descriptors within a global descriptor heap, as well as contains the root Constant Buffer View (CBV). consume 32 bytes (D3D12_SHADER_IDENTIFIER_SIZE_IN_BYTES) and must also be located at an offset that is aligned to 32 bytes (D3D12_RAYTRACING_SHADER_RECORD_BYTE_ALIGNMENT). Root signature parameters that are 8 bytes in size (such as root descriptors) must also be placed at offsets that are aligned to 8 bytes. Thus, carefully written packing code or helper types have to be used in order to fulfll these specifc rules when generating the shader table. The following code shows an example of what shader record helper structs might look like: 1 struct ShaderIdentifier 2 { 3 uint8_t Data[D3D12_SHADER_IDENTIFIER_SIZE_IN_BYTES] = { }; 4 5 ShaderIdentifier() = default; 6 explicit ShaderIdentifier(const void* idPointer) 7 { 8 memcpy(Data, idPointer, D3D12_SHADER_IDENTIFIER_SIZE_IN_BYTES); 9 } 10 }; 11 12 struct HitGroupRecord 13 { 14 ShaderIdentifier ID; 15 D3D12_GPU_DESCRIPTOR_HANDLE SRVTableA = { }; 16 D3D12_GPU_DESCRIPTOR_HANDLE SRVTableB = { }; 17 uint32_t Padding1 = 0; // Ensure that CBV has 8-byte alignment. 18 uint64_t CBV = 0; 19 uint8_t Padding[8] = { }; // Needed to keep shader ID at 20 // 32-byte alignment 21 }; 260 CHAPTER 17. USING BINDLESS RESOURCES WITH DIRECTX RAYTRACING For more complex scenarios with many meshes and materials, the local root signature approach can quickly become unwieldy and error-prone. Generating the local root signature arguments on the CPU as part of flling the hit shader table is the most straightforward approach, but this can consume precious CPU cycles if it needs to be done frequently in order to support dynamic arguments. It also subjects us to some of the same limitations on our shader programs that we had in previous versions of D3D: the set of resources required for a hit shader must be known in advance, and the shader itself must be written so that it uses a static set of resource bindings. Generation of the shader table on the GPU using compute shaders is a viable option that allows for more GPU-driven rendering approaches, however this can be considerably more diffcult to write, validate, and debug compared with the equivalent CPU implementation. It also does not remove the limitations regarding shader programs and dynamically selecting which resources to access. Both approaches are fundamentally incompatible with the new inline raytracing functionality that was added for DXR 1.1, since using a local root signature is no longer an option. This means that we must consider a less restrictive binding solution in order to make use of the new RayQuery APIs for general rendering scenarios. 17.3 BINDLESS RESOURCES IN D3D12 As mentioned earlier, bindless techniques allow us to effectively provide our shader programs with global access to all currently loaded resources instead of being restricted to a small subset. D3D12 supports bindless access to every resource type that utilizes shader visible descriptor heaps: Shader Resource Views (SRVs), Constant Buffer Views (CBVs), Unordered Access Views (UAVs), and Samplers. However, these types each have different limitations that can prevent their use in bindless scenarios, most of which are dictated by the value of D3D12_RESOURCE_BINDING_TIER that is exposed by the device. We will cover some of these limitations in more detail in Section 17.5, but for now we will primarily focus on using bindless techniques for SRVs because they typically form the bulk of resources accessed by shader programs.
Recommended publications
  • Peter Shirley, NVIDIA
    Course slides, resources, information: intro-to-dxr.cwyman.org Introduction to DirectX Raytracing Welcome & Introductions Chris Wyman, NVIDIA Shawn Hargreaves, Microsoft Peter Shirley, NVIDIA Colin Barré-Brisebois, SEED Course slides, resources, information: intro-to-dxr.cwyman.org Photography & Recording Encouraged 1 Image rendered with our course tutorials: Emerald Square scene from Open Research Content Archive Welcome • Why have this course? 2 Welcome • Why have this course? • Microsoft announced DirectX Raytracing at GDC • My Twitter feed blew up – With people (re)trying ray tracing How many times did you see this image on Twitter?3 Welcome • Why have this course? • Microsoft announced DirectX Raytracing at GDC • My Twitter feed blew up – With people (re)trying ray tracing A simple scene with added ray traced lighting • Now: Widely used API w/ray tracing support – Straightforward sharing of GPU resources – Compelling demos suggest real use cases 4 Welcome • Why have this course? • Microsoft announced DirectX Raytracing at GDC • My Twitter feed blew up – With people (re)trying ray tracing Left: Feasible sample count today in real-time • Now: Widely used API w/ray tracing support – Straightforward sharing of GPU resources – Compelling demos suggest real use cases • Not yet full path traced renderers – Only fast enough for a few rays per pixel – Research needed: reconstruct from low samples Right: Fully converged path tracing5 Welcome • Why have this course? • Microsoft announced DirectX Raytracing at GDC • My Twitter feed blew up –
    [Show full text]
  • 'Call of Duty: Modern Warfare' to Support Directx Raytracing on PC
    ‘Call of Duty: Modern Warfare’ to Support DirectX Raytracing on PC, Powered by NVIDIA GeForce RTX One of the Most Anticipated Games of the Year to Leverage NVIDIA RTX Technology on PC NVIDIA and Activision today announced that NVIDIA is the official PC partner for Call of Duty®: Modern Warfare®, the highly anticipated, all-new title scheduled for release on Oct. 25. NVIDIA is working side by side with developer Infinity Ward to bring real-time DirectX Raytracing (DXR), and NVIDIA® Adaptive Shading gaming technologies to the PC version of the new Modern Warfare. “Call of Duty: Modern Warfare is poised to reset the bar upon release this October,'' said Matt Wuebbling, head of GeForce marketing at NVIDIA. “NVIDIA is proud to partner closely with this epic development and contribute toward the creation of this gripping experience. Our teams of engineers have been working closely with Infinity Ward to use NVIDIA RTX technologies to display the realistic effects and incredible immersion that Modern Warfare offers.'' The most celebrated series in Call of Duty will make its return in a powerful experience reimagined from the ground up. Published by Activision and developed by Infinity Ward, the PC version of Call of Duty: Modern Warfare will release on Blizzard Battle.net. Modern Warfare features a unified narrative experience and progression across an epic, heart-racing, single-player story, an action-packed multiplayer playground, and new cooperative gameplay. “Our work with NVIDIA GPUs has helped us throughout the PC development of Modern Warfare,'' said Dave Stohl, co-studio head at Infinity Ward. “We've seamlessly integrated the RTX features like ray tracing and adaptive shading into our rendering pipeline.
    [Show full text]
  • GPU Developments 2018
    GPU Developments 2018 2018 GPU Developments 2018 © Copyright Jon Peddie Research 2019. All rights reserved. Reproduction in whole or in part is prohibited without written permission from Jon Peddie Research. This report is the property of Jon Peddie Research (JPR) and made available to a restricted number of clients only upon these terms and conditions. Agreement not to copy or disclose. This report and all future reports or other materials provided by JPR pursuant to this subscription (collectively, “Reports”) are protected by: (i) federal copyright, pursuant to the Copyright Act of 1976; and (ii) the nondisclosure provisions set forth immediately following. License, exclusive use, and agreement not to disclose. Reports are the trade secret property exclusively of JPR and are made available to a restricted number of clients, for their exclusive use and only upon the following terms and conditions. JPR grants site-wide license to read and utilize the information in the Reports, exclusively to the initial subscriber to the Reports, its subsidiaries, divisions, and employees (collectively, “Subscriber”). The Reports shall, at all times, be treated by Subscriber as proprietary and confidential documents, for internal use only. Subscriber agrees that it will not reproduce for or share any of the material in the Reports (“Material”) with any entity or individual other than Subscriber (“Shared Third Party”) (collectively, “Share” or “Sharing”), without the advance written permission of JPR. Subscriber shall be liable for any breach of this agreement and shall be subject to cancellation of its subscription to Reports. Without limiting this liability, Subscriber shall be liable for any damages suffered by JPR as a result of any Sharing of any Material, without advance written permission of JPR.
    [Show full text]
  • Are We Done with Ray Tracing? State-Of-The-Art and Challenges in Game Ray Tracing
    Are We Done With Ray Tracing? State-of-the-Art and Challenges in Game Ray Tracing Colin Barré-Brisebois, @ZigguratVertigo SEED – Electronic Arts How did we get here? GDC 2018 – DXR Unveiled “Ray tracing is the future and ever will be” [Electronic Arts, SEED] [Epic Games, NVIDIA, ILMxLAB] [SEED 2018] Real-Time Ray Tracing in Software and Hardware Real-Time Hybrid Ray Tracing in Unreal Engine 4 [https://docs.unrealengine.com/en-US/Engine/Rendering/RayTracing/index.html] [Courtesy of Epic Games, Goodbye Kansas, Deep Forest Films] [Courtesy of Epic Games, Goodbye Kansas, Deep Forest Films] [Tatarchuk 2019, Courtesy of Unity Technologies] Left: real-world footage. Right rendered with Unity [Tatarchuk 2019, Courtesy of Unity Technologies] Left: real-world footage. Right rendered with Unity [Tatarchuk 2019, Courtesy of Unity Technologies] Left: real-world footage. Right rendered with Unity [Tatarchuk 2019, Courtesy of Unity Technologies] [Christophe Schied, NVIDIA Lightspeed Studios™] SIGGRAPH 2019 – Are We Done With Ray Tracing? – State-of-the-Art and Challenges in Game Ray Tracing And many more… ▪ Assetto Corsa ▪ JX3 ▪ Atomic Heart ▪ Mech Warrior V: Mercenaries ▪ Call of Duty: Modern Warfare ▪ Project DH ▪ Cyberpunk 2077 ▪ Stay in the Light ▪ Enlisted ▪ Vampire: The Masquerade – Bloodlines 2 ▪ Justice ▪ Watch Dogs: Legion ▪ Wolfenstein: Youngblood Just the beginning of real-time ray tracing making its way into game products We’re in for a great ride, and the work is not done! This is super exciting! ☺ SIGGRAPH 2019 – Are We Done With Ray Tracing?
    [Show full text]
  • Exploiting Hardware-Accelerated Ray Tracing for Monte Carlo Particle Transport with Openmc
    Exploiting Hardware-Accelerated Ray Tracing for Monte Carlo Particle Transport with OpenMC Justin Lewis Salmon, Simon McIntosh Smith Department of Computer Science University of Bristol Bristol, U.K. fjustin.salmon.2018, [email protected] Abstract—OpenMC is a CPU-based Monte Carlo particle HPC due to their proliferation in modern supercomputer transport simulation code recently developed in the Computa- designs such as Summit [6]. tional Reactor Physics Group at MIT, and which is currently being evaluated by the UK Atomic Energy Authority for use on A. OpenMC the ITER fusion reactor project. In this paper we present a novel port of OpenMC to run on the new ray tracing (RT) cores in OpenMC is a Monte Carlo particle transport code focussed NVIDIA’s latest Turing GPUs. We show here that the OpenMC on neutron criticality simulations, recently developed in the GPU port yields up to 9.8x speedup on a single node over a Computational Reactor Physics Group at MIT [7]. OpenMC 16-core CPU using the native constructive solid geometry, and is written in modern C++, and has been developed using up to 13x speedup using approximate triangle mesh geometry. Furthermore, since the expensive 3D geometric operations re- high code quality standards to ensure maintainability and quired during particle transport simulation can be formulated consistency. This is in contrast to many older codes, which as a ray tracing problem, there is an opportunity to gain even are often written in obsolete versions of Fortran, and have higher performance on triangle meshes by exploiting the RT grown to become highly complex and difficult to maintain.
    [Show full text]
  • Multi-Hit Ray Tracing in DXR Christiaan Gribble SURVICE Engineering
    CHAPTER 9 Multi-Hit Ray Tracing in DXR Christiaan Gribble SURVICE Engineering ABSTRACT Multi-hit ray traversal is a class of ray traversal algorithm that finds one or more, and possibly all, primitives intersected by a ray, ordered by point of intersection. Multi- hit traversal generalizes traditional first-hit ray traversal and is useful in computer graphics and physics-based simulation. We present several possible multi-hit implementations using Microsoft DirectX Raytracing and explore the performance of these implementations in an example GPU ray tracer. 9.1 INTRODUCTION Ray casting has been used to solve the visibility problem in computer graphics since its introduction to the field over 50 years ago. First-hit traversal returns information regarding the nearest primitive intersected by a ray, as shown on the left in Figure 9-1. When applied recursively, first-hit traversal can also be used to incorporate visual effects such as reflection, refraction, and other forms of indirect illumination. As a result, most ray tracing APIs are heavily optimized for first-hit performance. Figure 9-1. Three categories of ray traversal. First-hit traversal and any-hit traversal are well-known and often-used ray traversal algorithms in computer graphics applications for effects like visibility (left) and ambient occlusion (center). We explore multi-hit ray traversal, the third major category of ray traversal that returns the N closest primitives ordered by point of intersection (for N ≥ 1). Multi- hit ray traversal is useful in a number of computer graphics and physics-based simulation applications, including optical transparency (right). © NVIDIA 2019 111 E.
    [Show full text]
  • Evaluating the Use of Proxy Geometry for RTX-Based Ray Traced Diffuse Global Illumination
    Evaluating the Use of Proxy Geometry for RTX-based Ray Traced Diffuse Global Illumination Master’s thesis in computer science and engineering Simon Moos Department of Computer Science and Engineering CHALMERS UNIVERSITY OF TECHNOLOGY UNIVERSITY OF GOTHENBURG Gothenburg, Sweden 2020 Master’s thesis 2020 Evaluating the Use of Proxy Geometry for RTX-based Ray Traced Diffuse Global Illumination Simon Moos Department of Computer Science and Engineering Chalmers University of Technology University of Gothenburg Gothenburg, Sweden 2020 Evaluating the Use of Proxy Geometry for RTX-based Ray Traced Diffuse Global Illumination Simon Moos © Simon Moos, 2020. Supervisor: Erik Sintorn, Department of Computer Science and Engineering Examiner: Ulf Assarsson, Department of Computer Science and Engineering Advisor: Magnus Pettersson, RapidImages Master’s Thesis 2020 Department of Computer Science and Engineering Chalmers University of Technology and University of Gothenburg SE-412 96 Gothenburg Telephone +46 31 772 1000 Cover: Visualization of sphere set proxy geometry, with superimposed diffuse global illumination Typeset in LATEX Gothenburg, Sweden 2020 iv Evaluating the Use of Proxy Geometry for RTX-based Ray Traced Diffuse Global Illumination Simon Moos Department of Computer Science and Engineering Chalmers University of Technology Abstract Diffuse global illumination is vital for photorealistic rendering, but accurately eval- uating it is computationally expensive and usually involves ray tracing. Ray tracing has often been considered prohibitively expensive for real-time rendering, but with the new RTX technology it can be done many times faster than what was previously possible. While ray tracing is now faster, ray traced diffuse global illumination is still relatively slow on GPUs, and we see the potential of improving performance on the application-level.
    [Show full text]
  • A Survey on Bounding Volume Hierarchies for Ray Tracing
    DOI: 10.1111/cgf.142662 EUROGRAPHICS 2021 Volume 40 (2021), Number 2 H. Rushmeier and K. Bühler STAR – State of The Art Report (Guest Editors) A Survey on Bounding Volume Hierarchies for Ray Tracing yDaniel Meister1z yShinji Ogaki2 Carsten Benthin3 Michael J. Doyle3 Michael Guthe4 Jiríˇ Bittner5 1The University of Tokyo 2ZOZO Research 3Intel Corporation 4University of Bayreuth 5Czech Technical University in Prague Figure 1: Bounding volume hierarchies (BVHs) are the ray tracing acceleration data structure of choice in many state of the art rendering applications. The figure shows a ray-traced scene, with a visualization of the otherwise hidden structure of the BVH (left), and a visualization of the success of the BVH in reducing ray intersection operations (right). Abstract Ray tracing is an inherent part of photorealistic image synthesis algorithms. The problem of ray tracing is to find the nearest intersection with a given ray and scene. Although this geometric operation is relatively simple, in practice, we have to evaluate billions of such operations as the scene consists of millions of primitives, and the image synthesis algorithms require a high number of samples to provide a plausible result. Thus, scene primitives are commonly arranged in spatial data structures to accelerate the search. In the last two decades, the bounding volume hierarchy (BVH) has become the de facto standard acceleration data structure for ray tracing-based rendering algorithms in offline and recently also in real-time applications. In this report, we review the basic principles of bounding volume hierarchies as well as advanced state of the art methods with a focus on the construction and traversal.
    [Show full text]
  • Directx Raytracing
    DirectX Raytracing Matt Sandy Program Manager DirectX Agenda • Why Raytracing? • DXR Deep Dive • Tools & Helpers • Applied Raytracing (EA/SEED) • Get Started 3D Graphics is a Lie • Solving the Visibility Problem Emergence of Exceptions • Dynamic Shadows • Environment Mapping • Reflections • Global Illumination A Brief History of Pixels • 1999 – Hardware T&L • 2000 – Simple Programmable Shaders • 2002 – Complex Programmable Shaders • 2008 – Compute Shaders • 2014 – Asynchronous Compute • 2018… A Brief History of Pixels • 1999 – Hardware T&L • 2000 – Simple Programmable Shaders • 2002 – Complex Programmable Shaders • 2008 – Compute Shaders • 2014 – Asynchronous Compute • 2018 – DirectX Raytracing Raytracing 101 1. Construct a 3D representation of a scene. 2. Trace rays into the scene from a point of interest (e.g. camera). 3. Accumulate data about ray intersections. 4. Optional: go to step 2. 5. Process the accumulated data to form an image. ⁛ ⁛ ⁛ ⁛ ⁛ ⁛ ⁛ ⁛ ⁛ ⁛ ⁛ ⁛ ⁛ ⁛ ⁛ ⁛ Case Study: SSR DXR 101 Case Study: SSR DXR 101 Raytracing Requirements • Scene geometry representation • Trace rays into scene and get intersections • Determine and execute material shaders Raytracing Requirements • Scene geometry representation • Trace rays into scene and get intersections • Determine and execute material shaders Acceleration Structures • Opaque buffers that represent a scene • Constructed on the GPU • Two-level hierarchy [M] [M] [M] [M] Geometries • Triangles • Vertex Buffer (float16x3 or float32x3) • Index Buffer (uint16 or uint32) • Transformation
    [Show full text]
  • Realtime Rendering: PC Cluster with Special Hardware
    Hannes Kaufmann 3D Graphics Hardware Hannes Kaufmann Interactive Media Systems Group (IMS) Institute of Software Technology and Interactive Systems Thanks to Dieter Schmalstieg and Michael Wimmer for providing slides/images/diagrams Hannes Kaufmann Motivation • VR/AR environment = Hardware setup + VR Software Framework + Application • Detailled knowledge is needed about – Hardware: Input Devices & Tracking, Output Devices, 3D Graphics – Software: Standards, Toolkits, VR frameworks – Human Factors: Usability, Evaluations, Psychological Factors (Perception,…) 2 Hannes Kaufmann 3D Graphics Hardware -Development • Incredible development boost of consumer cards in previous ~20 years • Development driven by game industry • PC graphics surpassed workstations (~2001) 3 Consumer Graphics – History • Up to 1995 – 2D only (S3, Cirrus Logic, Tseng Labs, Trident) • 1996 3DFX Vodoo (first real 3D card); Introduction of DX3 • 1997 Triangle rendering (… DX5) • 1999 Multi-Pipe, Multitexture (…DX7) • 2000 Transform and lighting (…DX8) • 2001 Programmable shaders – PCs surpass workstations • 2002 Full floating point • 2004 Full looping and conditionals • 2006/07 Geometry/Primitive shaders (DX10, OpenGL 2.1) • 2007/08 CUDA (Nvidia) - GPU General Purpose Computing • 2009 DX11: Multithreaded rend., Compute shaders, Tessel. •4 2018 Ray-Tracing Cores (RTX) & DirectX Raytracing (in DX12) Hannes Kaufmann Moore‘s Law • Gordon Moore, Intel co-founder, 1965 • Exponential growth in number of transistors • Doubles every 18 months – yearly growth: factor 1.6 – Slow development
    [Show full text]
  • And Inline Ray Tracing in DXR an Application in Soft Shadows
    Master of Science in Engineering: Game and Software Engineering June 2021 A Performance Comparison of Dynamic- and Inline Ray Tracing in DXR An application in soft shadows Joakim Sjöberg Filip Zachrisson Faculty of Computing, Blekinge Institute of Technology, 371 79 Karlskrona, Sweden This thesis is submitted to the Faculty of Computing at Blekinge Institute of Technology in partial fulfillment of the requirements for the degree of Master of Science in Engineering: Game and Software Engineering. The thesis is equivalent to 20 weeks of full-time studies. The authors declare that they are the sole authors of this thesis and that they have not used any sources other than those listed in the bibliography and identified as references. They further declare that they have not submitted this thesis at any other institution to obtain a degree. Contact Information: Author(s): Joakim Sjöberg E-mail: [email protected] Filip Zachrisson E-mail: fi[email protected] University advisor: Associate Professor, Veronica Sundstedt Department of Computer Science External advisor at AMD: SMTS Software Development Engineer, Stefan Petersson Faculty of Computing Internet : www.bth.se Blekinge Institute of Technology Phone : +46 455 38 50 00 SE–371 79 Karlskrona, Sweden Fax : +46 455 38 50 57 Abstract Background. Ray tracing is a tool that can be used to increase the quality of the graphics in games. One application in graphics that ray tracing excels in is generat- ing shadows because ray tracing can simulate how shadows are generated in real life more accurately than rasterization techniques can. With the release of GPUs with hardware support for ray tracing, it can now be used in real-time graphics appli- cations to some extent.
    [Show full text]
  • Running on Raygun Arxiv:2001.09792V1 [Cs.GR]
    Running on Raygun Alexander Hirsch Peter Thoman With the introduction of Nvidia RTX hardware, ray tracing is now viable as a general real time rendering technique for complex 3D scenes. Leveraging this new technology, we present Raygun, an open source1 rendering, simulation, and game engine focusing on simplicity, expandability, and the topic of ray tracing realized through Nvidia’s Vulkan ray tracing extension. arXiv:2001.09792v1 [cs.GR] 27 Jan 2020 1 Introduction In the beginning, Nvidia RTX [7] could only be used via Nvidia OptiX [6], their dedicated ray tracing application framework, or via Microsoft DXR [5]. As many developers were hoping for a more open approach to this technology, Nvidia released an (experimental) extension for Vulkan [2] with their 411.63 graphics driver [9]. This advancement in technology is what makes Raygun possible. At the time consumers got their hands on Nvidia RTX capable graphics cards, none of the modern, publicly accessible video game engines allowed using Nvidia RTX for the whole rendering process. Initially we looked at Unity2, Unreal3, 1https://github.com/W4RH4WK/Raygun (MIT license) 2https://unity.com 3https://www.unrealengine.com 1 and Godot4 just to find out that RTX is not yet available in these engines. Unity’s engine is closed source, Unreal is far too large for us to add RTX support in a tangible amount of time, and Godot has not made the transition (from OpenGL) to Vulkan yet. This spawned the incipient idea of Raygun. While Quake II RTX [1], an implementation of RTX ray tracing using the Quake II engine, already existed at this time, we decided to create our own engine using C++ and modern libraries, focusing on a slim core with expandability in mind.
    [Show full text]