DOCSLIB.ORG

California State University, Northridge

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
California State University, Northridge CALIFORNIA STATE UNIVERSITY, NORTHRIDGE Comparative Effectiveness of CPU and GPU Ray Tracing With Parallel Computation A thesis submitted in partial fulfillment of the requirements For the degree of Master of Science in Computer Science By Dustin Patrick Delmer May 2017 Copyright Dustin Patrick Delmer 2017 ii The thesis of Dustin Patrick Delmer is approved: _____________________________________________ __________________ Dr. Robert Mcllhenny Date _____________________________________________ __________________ Dr. John Noga Date _____________________________________________ __________________ Dr. G. Michael Barnes, Chair Date California State University, Northridge iii In Loving Memory of my Father, Daniel William Christian Delmer iv Table of Contents Copyright ........................................................................................................................................ ii Signature Page ............................................................................................................................... iii Dedication ….................................................................................................................................. iv List of Figures …........................................................................................................................... vii Abstract …...................................................................................................................................... vi 1. Introduction ….................................................................................................................... 1 2. Related Work ….................................................................................................................. 3 3. Technology Overview ….................................................................................................... 5 3.1. CPU vs GPU …..................................................................................................... 5 3.2. ISPC ….................................................................................................................. 5 3.3. CUDA …............................................................................................................... 6 4. Implementation ….............................................................................................................. 8 4.1. Ray Tracing Algorithm …..................................................................................... 8 4.2. C++ Serial Implementation …............................................................................. 10 4.3. ISPC Implementation …...................................................................................... 10 4.4. CUDA Implementation …................................................................................... 13 4.5. Dynamic Scene Generation …............................................................................ 16 5. Results/Comparison …..................................................................................................... 17 5.1. Hardware …......................................................................................................... 17 5.2. Rendering Results from Default Scene …........................................................... 19 5.3. Dynamic Scene: Sphere Count and Resolution Costs ….................................... 20 5.4. Data Gather Techniques and Results ….............................................................. 21 6. Conclusion …................................................................................................................... 32 v References ….............................................................................................................................. 33 vi List of Figures Figure 4.1. Ray tracing figure …..................................................................................................... 9 Figure 4.2 Reflection and refraction …........................................................................................... 9 Figure 4.3: foreach_tiled loop ...................................................................................................... 11 Figure 4.4: ISPC Multi-core - the task function ........................................................................... 12 Figure 4.5: ISPC multi-core – launch[nTasks] .............................................................................. 12 Figure 4.6: CUDA - malloc and memcpy….................................................................................. 14 Figure 4.7: CUDA - Kernel function …........................................................................................ 15 Figure 4.8: CUDA - Kernel call …................................................................................................ 16 Figure 4.9: Code snippet from common/rand_sphere …............................................................... 17 Figure 5.1: Default config, 640x480, five static spheres and a light ............................................ 19 Figure 5.2: Sphere counts ( 8, 64, 216, 512, 1000) …................................................................... 22 Figure 5.3: Sphere Count vs Time - All Techniques …................................................................ 24 Figure 5.4: Sphere Count vs Time - ISPC Only …........................................................................ 25 Figure 5.5: Sphere Count vs Time - CUDA vs ISPC …................................................................ 26 Figure 5.6: Resolution vs Time - All Techniques …...................................................................... 27 Figure 5.7: Resolution vs Time - ISPC Only …............................................................................ 28 Figure 5.8: Resolution vs Time - CUDA vs ISPC ….................................................................... 29 Figure 5.9: Bar Chart Comparison - ISPC vs CUDA …............................................................... 30 vii Abstract Comparative Effectiveness of CPU and GPU Ray Tracing With Parallel Computation By Dustin Patrick Delmer Master of Science in Computer Science In this thesis, a comparison of GPU and CPU based computation using consumer grade hardware and parallel programming languages in a raytracer is presented. The raytracers presented make use of C++, Intel’s SIMD CPU language and compiler: ISPC, and Nvidia’s GPGPU language/compiler: CUDA. Performance was measured for three levels of image resolution (2562, 5122, 10242) and five levels of image complexity ( sphere counts: 8, 64, 216, 512, 1000). Image resolution had the greatest impact on performance. Image complexity had a constant effect on performance. As image resolution increased the parallel GPU solution offered the best results. This thesis discusses the advantages and disadvantages of CPU vs GPU parallel programming. viii 1. Introduction Parallel programming has become increasingly relevant over the past decade. Manufacturers have shifted their focus from increasing clock speeds to augmenting the core and thread counts in each generation of new CPU’s and GPU’s. In this environment writing applications that take full advantage of these multi-cored components has becoming more and more essential. There are several languages and compilers that exist to help programmers write code capable of generating efficient parallel programs. In this thesis two of these languages will be discussed: ISPC and CUDA. This thesis will show how these languages can be utilized to augment a raytracer, and compare and contrast them. Ray tracing is a technique for generating an image by tracing the path of light through pixels in an image plane and simulating the effects of its encounters with virtual objects. These algorithms are used in 3D rendering and animation and computer graphics. ISPC is an Intel developed compiler with extensions for “single program, multiple data” (SPMD) programming [1]. ISPC simplifies the task of spawning multiple parallel program instances across a CPU. ISPC provides a thin abstraction layer between the programmer and the hardware; to spare the programmer the burden of writing extremely low-level intrinsics to achieve high performance. ISPC methods are exposed to C++ code through *.isph headers, and objects produced by .ispc files are compiled into libraries and executables along with C++ code using conventional c++ compilers. CUDA is an Nvidia developed GPGPU (general purpose programmability on the graphics processing unit) compiler and language that allows programmers to allocate massively 1 parallel tasks directly to the GPU [2]. Through CUDA parallel functions can be written in a seemingly serial manner, which is instanced in many threads, across many blocks within a GPU. When using CUDA, the CPU’s role is allocating memory, copying data, and launching Kernel functions. CUDA programs take advantage of the large number of cores present in modern GPU’s to do the bulk of their computation. In this report there are six sections. Section 2 will present work related to comparisons of serial and parallel programming. Section 3 will present CPU and GPU architectures, and ISPC and CUDA technologies used in this report. Section 4 will present the implementation of the raytracer in C++, ISPC, and CUDA. Section 5 presents the results of running these implementations with five sphere counts, over three image resolutions. Lastly, section 6 will briefly discuss the results. 2 2. Related Work Parallel programming is widely
Load more

Recommended publications
  • NVIDIA CUDA on IBM POWER8: Technical Overview, Software Installation, and Application Development
    Redpaper Dino Quintero Wei Li Wainer dos Santos Moschetta Mauricio Faria de Oliveira Alexander Pozdneev NVIDIA CUDA on IBM POWER8: Technical overview, software installation, and application development Overview The exploitation of general-purpose computing on graphics processing units (GPUs) and modern multi-core processors in a single heterogeneous parallel system has proven highly efficient for running several technical computing workloads. This applied to a wide range of areas such as chemistry, bioinformatics, molecular biology, engineering, and big data analytics. Recently launched, the IBM® Power System S824L comes into play to explore the use of the NVIDIA Tesla K40 GPU, combined with the latest IBM POWER8™ processor, providing a unique technology platform for high performance computing. This IBM Redpaper™ publication discusses the installation of the system, and the development of C/C++ and Java applications using the NVIDIA CUDA platform for IBM POWER8. Note: CUDA stands for Compute Unified Device Architecture. It is a parallel computing platform and programming model created by NVIDIA and implemented by the GPUs that they produce. The following topics are covered: Advantages of NVIDIA on POWER8 The IBM Power Systems S824L server Software stack System monitoring Application development Tuning and debugging Application examples © Copyright IBM Corp. 2015. All rights reserved. ibm.com/redbooks 1 Advantages of NVIDIA on POWER8 The IBM and NVIDIA partnership was announced in November 2013, for the purpose of integrating IBM POWER®-based systems with NVIDIA GPUs, and enablement of GPU-accelerated applications and workloads. The goal is to deliver higher performance and better energy efficiency to companies and data centers. This collaboration produced its initial results in 2014 with: The announcement of the first IBM POWER8 system featuring NVIDIA Tesla GPUs (IBM Power Systems™ S824L).
    [Show full text]
  • Hybrid Programming Using Openshmem and Openacc
    Hybrid Programming using OpenSHMEM and OpenACC Matthew Baker1, Swaroop Pophale3, Jean-Charles Vasnier4, Haoqiang Jin2, and Oscar Hernandez1 1 Oak Ridge National Laboratory, Oak Ridge, Tennessee, 37840, USA [email protected],[email protected] 2 NASA Ames, Moffet Field, California USA, [email protected] 3 University of Houston, Houston, Texas 77004, USA, [email protected] 4 CAPS entreprise, France, [email protected] Abstract. With high performance systems exploiting multicore and accelerator-based architectures on a distributed shared memory system, heterogenous hybrid programming models are the natural choice to ex- ploit all the hardware made available on these systems. Previous efforts looking into hybrid models have primarily focused on using OpenMP directives (for shared memory programming) with MPI (for inter-node programming on a cluster), using OpenMP to spawn threads on a node and communication libraries like MPI to communicate across nodes. As accelerators get added into the mix, and there is better hardware sup- port for PGAS languages/APIs, this means that new and unexplored heterogenous hybrid models will be needed to effectively leverage the new hardware. In this paper we explore the use of OpenACC directives to program GPUs and the use of OpenSHMEM, a PGAS library for one- sided communication between nodes. We use the NAS-BT Multi-zone benchmark that was converted to use the OpenSHMEM library API for network communication between nodes and OpenACC to exploit accel- erators that are present within a node. We evaluate the performance of the benchmark and discuss our experiences during the development of the OpenSHMEM+OpenACC hybrid program.
    [Show full text]
  • Nvidia Cuda Toolkit V5.0
    NVIDIA CUDA TOOLKIT V5.0 v5.0 | October 2012 Release Notes for Windows, Linux, and Mac OS REVISION HISTORY ‣ 10/2012 Version 5.0 ‣ 08/2012 Version 5.0 RC ‣ 05/2012 Version 5.0 EA/Preview ‣ 04/2012 Version 4.2 ‣ 01/2012 Version 4.1 Production ‣ 11/2011 Version 4.1 RC2 ‣ 10/2011 Version 4.1 RC1 ‣ 09/2011 Version 4.1 EA (Information in ReadMe.txt) ‣ 05/2011 Version 4.0 ‣ 04/2011 Version 4.0 RC2 (Errata) ‣ 02/2011 Version 4.0 RC ‣ 11/2010 Version 3.2 ‣ 10/2010 Version 3.2 RC2 ‣ 09/2010 Version 3.2 RC www.nvidia.com NVIDIA CUDA Toolkit v5.0 v5.0 | ii TABLE OF CONTENTS Chapter 1. Release Highlights................................................................................. 1 Chapter 2. Documentation..................................................................................... 2 Chapter 3. List of Important Files............................................................................3 3.1 Core Files.................................................................................................. 3 3.2 Windows lib Files......................................................................................... 4 3.3 Linux lib Files............................................................................................. 4 3.4 Mac OS X lib Files........................................................................................ 4 Chapter 4. Supported NVIDIA Hardware.....................................................................5 Chapter 5. Supported Operating Systems...................................................................6
    [Show full text]
  • Applications Kernels
    C-DAC Four Days Technology Workshop ON Hybrid Computing – Coprocessors/Accelerators Power-Aware Computing – Performance of Applications Kernels hyPACK-2013 (Mode-4 : GPUs) Lecture Topic: An Overview of CUDA enabled GPUs Venue : CMSD, UoHYD ; Date : October 15-18, 2013 C-DAC hyPACK-2013 An Overview of CUDA enabled NVIDIA GPUs 1 An Overview of CUDA enabled NVIDIA GPUs Lecture Outline Following topics will be discussed An overview of CUDA enabled NVIDIA GPU Tuning & Performance Issues on NVIDIA GPUs An Overview of CUDA 4.x/5.0 & -Fermi /Kepler GK110 Source : NVIDIA, References given in the presentation C-DAC hyPACK-2013 An Overview of CUDA enabled NVIDIA GPUs 2 Part-1 CUDA enabled NVIDIS GPUs Source & Acknowledgements : NVIDIA, References C-DAC hyPACK-2013 An Overview of CUDA enabled NVIDIA GPUs 3 Computing - CPU/GPU Source & Acknowledgements : NVIDIA, References C-DAC hyPACK-2013 An Overview of CUDA enabled NVIDIA GPUs 4 Computing - CPU/GPU Floating-Point Operations per Second and Memory Bandwidth for the CPU and GPU Source & Acknowledgements : NVIDIA, References C-DAC hyPACK-2013 An Overview of CUDA enabled NVIDIA GPUs 5 Why Are GPUs So Fast? GPU originally specialized for math-intensive, highly parallel computation So, more transistors can be devoted to data processing rather than data caching and flow control AMD ALU ALU Control ALU ALU Cache DRAM DRAM CPU GPU NVIDIA Commodity industry: provides economies of scale Competitive industry: fuels innovation Source : NVIDIA, References C-DAC hyPACK-2013 An Overview of CUDA enabled NVIDIA GPUs 6 GPU Computing : Think in Parallel Some Design Goals Scale to 100’s of cores, 1000’s of parallel 0 1 2 3 4 5 6 7 threads …… Let programmers focus on parallel float x = input[threadID]; float y = func(x); algorithms & Re-writing the Code output[threadID] = y; … • Not on the mechanics of a parallel programming language Enable heterogeneous systems (i.e.
    [Show full text]
  • Improving Opencl Performance by Specializing Compiler Phase
    Improving OpenCL Performance by Specializing Compiler Phase Selection and Ordering Ricardo Nobre¬, Lu´ısReis, and Jo˜ao M. P. Cardoso Faculty of Engineering, University of Porto INESC TEC, Porto, Portugal [email protected], [email protected], [email protected] Abstract. Automatic compiler phase selection/ordering has tradition- ally been focused on CPUs and, to a lesser extent, FPGAs. We present experiments regarding compiler phase ordering specialization of OpenCL kernels targeting a GPU. We use iterative exploration to specialize LLVM phase orders on 15 OpenCL benchmarks to an NVIDIA GPU. We ana- lyze the generated NVIDIA PTX code for the various versions to identify the main causes of the most significant improvements and present results of a set of experiments that demonstrate the importance of using specific phase orders. Using specialized compiler phase orders, we were able to achieve geometric mean improvements of 1.54× (up to 5.48×) and 1.65× (up to 5.7×) over PTX generated by the NVIDIA CUDA compiler from CUDA versions of the same kernels, and over execution of the OpenCL kernels compiled from source with the NVIDIA OpenCL driver, respec- tively. We also evaluate the use of code-features in the OpenCL kernels. More specifically, we evaluate an approach that achieves geometric mean improvements of 1.49× and 1.56× over the same OpenCL baseline, by using the compiler sequences of the 1 or 3 most similar benchmarks, respectively. Keywords: GPU computing, phase ordering, OpenCL, optimization, parallel computing, LLVM. 1 Introduction arXiv:1810.10496v1 [cs.PF] 24 Oct 2018 High Performance Computing (HPC) is increasingly relying on more heterogene- ity, e.g., by combining Central Processing Units (CPUs) with accelerators in the form of Graphics Processing Units (GPUs) programmed with languages such as OpenCL [1] or CUDA [2].
    [Show full text]
  • A Compiler Optimization Framework for Directive-Based Gpu Computing
    A COMPILER OPTIMIZATION FRAMEWORK FOR DIRECTIVE-BASED GPU COMPUTING A Dissertation Presented to the Faculty of the Department of Computer Science University of Houston In Partial Fulfillment of the Requirements for the Degree Doctor of Philosophy By Xiaonan Tian August 2016 A COMPILER OPTIMIZATION FRAMEWORK FOR DIRECTIVE-BASED GPU COMPUTING Xiaonan Tian APPROVED: Dr. Barbara Chapman, Chairman Dept. of Computer Science Dr. Edgar Gabriel Dept. of Computer Science Dr. Jaspal Subhlok Dept. of Computer Science Dr. Weidong Shi Dept. of Computer Science Dr. Gregory Rodgers Advanced Micro Devices Research, Inc. Dean, College of Natural Sciences and Mathematics ii Acknowledgements Though this dissertation is under my name, a number of great people have con- tributed to its production. I would like to express here my sincere appreciation for all those who made this PhD work possible. My deepest gratitude is to my committee chair and advisor, Dr. Barbara Chap- man, offered and supported me from the beginning of my Ph.D program. I have been amazingly fortunate to have an advisor who gave me trust and freedom to explore on my own. She has been the most important people for my graduate research. Her patience and support helped me overcome many crisis siutations and finish this dissertation. It was an honor for me to be a member of Dr.Chapman's HPCTools group and work with a number of brilliant teammates. I also would like to thank my other committee members, Dr. Edgar Gabriel, Dr. Larry Shi, Dr. Jaspal Subhlok, and Dr. Gregory Rodgers, who all took the time to review my work and offer their valued feedback.
    [Show full text]
  • From CUDA to Openacc in Graph Processing Applications
    Bachelor Informatica From CUDA to OpenACC in Graph Processing Applications Wouter de Bruijn June 17, 2019 Informatica — Universiteit van Amsterdam Supervisor(s): Dr. Ana Lucia Varbanescu 2 Abstract Most GPU-accelerated programs are written using the NVIDIA proprietary API CUDA. CUDA has an extensive collection of users and libraries, but functions only on NVIDIA GPUs and is completely proprietary. This thesis proposes standard ways to convert CUDA to the higher level programming model OpenACC, examines the difficulty of this process, and analyzes the performance of the final converted program. We have applied our porting methodology to two different graph processing algorithms. We chose Breadth First Search for its relative simplicity and large amount of memory opera- tions, and PageRank for its combination of memory operations and computational sections. The results show that OpenACC was significantly faster than CUDA for PageRank, and was more or less tied with CUDA in Breadth First Search. In the end, the performance of OpenACC was close enough to CUDA for most cases, and actually faster than CUDA in one case. OpenACC did lack in performance and consistency on multi-core CPUs when compared to OpenMP. Our systematic process of porting CUDA to OpenACC was therefore successful for the two different graph processing algorithms. The OpenACC ecosystem does still suffer from a lack of user support and documentation, which makes the process of writing larger and more complicated OpenACC programs more difficult than it should be for (beginner) pro- grammers. 3 4 Contents 1 Introduction 7 1.1 Context ......................................... 7 1.2 Research Questions ................................... 7 1.3 Thesis structure ....................................
    [Show full text]
  • Automatically Exploiting the Memory Hierarchy of Gpus Through Just-In-Time Compilation
    The University of Manchester Research Automatically Exploiting the Memory Hierarchy of GPUs through Just-in-Time Compilation Document Version Accepted author manuscript Link to publication record in Manchester Research Explorer Citation for published version (APA): Papadimitriou, M., Fumero Alfonso, J., Stratikopoulos, A., & Kotselidis, C-E. (Accepted/In press). Automatically Exploiting the Memory Hierarchy of GPUs through Just-in-Time Compilation. 57-70. Paper presented at The 17th ACM SIGPLAN/SIGOPS International Conference on Virtual Execution Environments (VEE’21). Citing this paper Please note that where the full-text provided on Manchester Research Explorer is the Author Accepted Manuscript or Proof version this may differ from the final Published version. If citing, it is advised that you check and use the publisher's definitive version. General rights Copyright and moral rights for the publications made accessible in the Research Explorer are retained by the authors and/or other copyright owners and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights. Takedown policy If you believe that this document breaches copyright please refer to the University of Manchester’s Takedown Procedures [http://man.ac.uk/04Y6Bo] or contact [email protected] providing relevant details, so we can investigate your claim. Download date:06. Oct. 2021 Automatically Exploiting the Memory Hierarchy of GPUs through Just-in-Time Compilation Michail Papadimitriou Juan Fumero The University of Manchester The University of Manchester United Kingdom United Kingdom [email protected] [email protected] Athanasios Stratikopoulos Christos Kotselidis The University of Manchester The University of Manchester United Kingdom United Kingdom [email protected] [email protected] Abstract CCS Concepts: • Software and its engineering ! Just- Although Graphics Processing Units (GPUs) have become in-time compilers.
    [Show full text]
  • Effective Extensible Programming: Unleashing Julia on Gpus
    IEEE TRANSACTIONS ON PARALLEL AND DISTRIBUTED SYSTEMS 1 Effective Extensible Programming: Unleashing Julia on GPUs Tim Besard, Christophe Foket and Bjorn De Sutter, Member, IEEE Abstract—GPUs and other accelerators are popular devices for accelerating compute-intensive, parallelizable applications. However, programming these devices is a difficult task. Writing efficient device code is challenging, and is typically done in a low-level programming language. High-level languages are rarely supported, or do not integrate with the rest of the high-level language ecosystem. To overcome this, we propose compiler infrastructure to efficiently add support for new hardware or environments to an existing programming language. We evaluate our approach by adding support for NVIDIA GPUs to the Julia programming language. By integrating with the existing compiler, we significantly lower the cost to implement and maintain the new compiler, and facilitate reuse of existing application code. Moreover, use of the high-level Julia programming language enables new and dynamic approaches for GPU programming. This greatly improves programmer productivity, while maintaining application performance similar to that of the official NVIDIA CUDA toolkit. Index Terms—Graphics processors, very high-level languages, code generation F 1 INTRODUCTION the implementation but hinders long-term maintainability To satisfy ever higher computational demands, hardware when the host language gains features or changes semantics. vendors and software developers look at accelerators, spe- It also forces users to learn and deal with the inevitable cialized processors that are optimized for specific, typically divergence between individual language implementations. parallel workloads, and perform much better at them than This paper presents a vision in which the high-level general-purpose processors [1], [2], [3], [4], [5].
    [Show full text]
  • GPU-Accelerated Simulation of Massive Spatial Data Based on The
    Mathematical Geoscience manuscript No. (will be inserted by the editor) GPU-accelerated Simulation of Massive Spatial Data based on the Modified Planar Rotator Model Milan Zukoviˇcˇ · Michal Borovsk´y · Mat´uˇs Lach · Dionissios T. Hristopulos Received: date / Accepted: date Abstract A novel Gibbs Markov random field for spatial data on Cartesian grids based on the modified planar rotator (MPR) model of statistical physics has been recently introduced for efficient and automatic interpolation of big data sets, such as satellite and radar images. The MPR model does not rely on Gaussian assump- tions. Spatial correlations are captured via nearest-neighbor interactions between Milan Zukoviˇcˇ Institute of Physics, Faculty of Science, P. J. Saf´arikˇ University, Park Angelinum 9, 041 54 Koˇsice, Slovakia Tel.: +421-552342544 E-mail: [email protected] Michal Borovsk´y Institute of Physics, Faculty of Science, P. J. Saf´arikˇ University, Park Angelinum 9, 041 54 Koˇsice, Slovakia Tel.: +421-552342544 E-mail: [email protected] Mat´uˇsLach Institute of Physics, Faculty of Science, P. J. Saf´arikˇ University, Park Angelinum 9, 041 54 Koˇsice, Slovakia Tel.: +421-552342565 E-mail: [email protected] Dionissios T. Hristopulos Geostatistics Laboratory, School of Mineral Resources Engineering, Technical University of Crete, Chania 73100, Greece Tel.: +30-28210-37688 arXiv:1811.01604v2 [physics.comp-ph] 18 Oct 2019 Fax: +30-28210-37853 E-mail: [email protected] 2 Milan Zukoviˇcetˇ al. transformed variables. This allows vectorization of the model which, along with an efficient hybrid Monte Carlo algorithm, leads to fast execution times that scale approximately linearly with system size.
    [Show full text]
  • Functional GPU Language Group DPW108F18 Christian Lundtofte Sørensen Henrik Djernes Thomsen
    FuGL Functional GPU Language Group DPW108F18 Christian Lundtofte Sørensen Henrik Djernes Thomsen Department of Computer Science Selma Lagerlöfs Vej 300 9220 Aalborg Ø Abstract: Developing software that utilizes the GPU often requires using low-level languages, and the de- veloper must be aware of the underlying archi- tecture and execution model, to fully utilize the available resources found on a GPU. This may require the developer to tweak and tune many Title: details in an implementation in order to gain full FuGL - Functional GPU Language performance, also requiring a lot of knowledge Theme: on the topic. Programming Technology In this project we introduce FuGL, a statically typed functional GPU programming language. Project period: FuGL features high level abstractions, requir- 01/02/2018 - ing only a few keywords to parallelize an imple- 08/06/2018 mentation. FuGL uses LLVM as backend, as it features architectural support for both CPUs and Project group: GPUs. The FuGL compiler is developed using .Net Core DPW902E17 with C#, to support both Windows, macOS and Linux. The compiler implements the LLVM C Members: API using LLVMSharp, to emit LLVM Assembly. Christian Lundtofte Sørensen FuGL features a simple syntax with only a few Henrik Djernes Thomsen constructs, as with Lisp. With only the keywords mutable and gpu, the developer is able to de- Supervisor: cide how and when data is allocated and copied Lone Leth Thomsen to the GPU, to remove unwanted memory copy- ing. Kernels are specified using only the gpu No. of Pages: 95 keyword. No. of Appendix Pages: 11 FuGL has been tested on three developers to de- Total no.
    [Show full text]
  • Exploiting Remote Memory Access for Automatic Multi-GPU Parallelization Javier Cabezas ∗§ Lluís Vilanova ∗§ Isaac Gelado Φ Thomas B
    Exploiting Remote Memory Access for Automatic Multi-GPU Parallelization Javier Cabezas ∗§ Lluís Vilanova ∗§ Isaac Gelado f Thomas B. Jablin ‡ Nacho Navarro ∗§ Wen-mei Hwu ‡ Barcelona Supercomputing Center∗ UPC§ NVIDIA Researchf UIUC‡ {name.lastname}@bsc.es {jcabezas,vilanova,nacho}@upc.edu [email protected] {jablin,w-hwu}@illinois.edu Abstract data structures. Consequently, prior work must conservatively replicate portions of the arrays that are never accessed. For In this paper we present AMGE, a programming framework example, consider a kernel that performs n-dimensional tiling and runtime system that transparently decomposes GPU ker- (a pattern often found in dense GPU computations [33, 37, 8]) nels and executes them on multiple GPUs in parallel. AMGE where computation partitions access different non-contiguous exploits the remote memory access capability in modern GPUs array regions. In such a case, Kim et al. transfer the whole to ensure that data can be accessed regardless of its physical memory ranges accessed by each computation partition, which location, thus allowing our runtime to safely decompose and may include large portions of the array that are never used, distribute arrays across GPU memories. It also implements a while Lee et al. replicate the whole data structure in all GPUs. compiler analysis that detects array access patterns in GPU This increases the memory usage, limiting the size of the prob- kernels. Using this information, the runtime chooses the best lems that can be handled, and imposes performance overheads computation and data distribution configuration. Results show due to larger data transfers. (2) Data coherence overhead: 1.98× and 3.89× execution speedups for 2 and 4 GPUs for a replicated output memory regions need to be merged in the wide range of dense computations compared to the original host memory after each kernel call.
    [Show full text]