DOCSLIB.ORG

Opencl Based Digital Image Projection Acceleration

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

OPENCL BASED DIGITAL IMAGE PROJECTION ACCELERATION Thesis Submitted to The School of Engineering of the UNIVERSITY OF DAYTON In Partial Fulfillment of the Requirements for The Degree of Master of Science in Electrical Engineering By Bryan Michael Badalamenti UNIVERSITY OF DAYTON Dayton, Ohio August, 2015 OPENCL BASED DIGITAL IMAGE PROJECTION ACCELERATION Name: Badalamenti, Bryan Michael APPROVED BY: Eric Balster, Ph.D. Frank Scarpino, Ph.D. Advisor Committee Chairman Committee Member Associate Professor, Department of Professor Emeritus, Department of Electrical and Computer Engineering Electrical and Computer Engineering Vijayan Asari, Ph.D. Committee Member Professor, Department of Electrical and Computer Engineering John G. Weber, Ph.D. Eddy M. Rojas, Ph.D., M.A., P.E. Associate Dean Dean School of Engineering School of Engineering ii c Copyright by Bryan Michael Badalamenti All rights reserved 2015 ABSTRACT OPENCL BASED DIGITAL IMAGE PROJECTION ACCELERATION Name: Badalamenti, Bryan Michael University of Dayton Advisor: Dr. Eric Balster In this thesis, several implementations of an image back projection algorithm using Open Com- puting Language (OpenCL) for different types of processors are developed. Image back projection is a method to take aerial imagery and create a map-like image that contains real-world dimensions and to remove the perspective angle from the camera. The processors that ran the back projection algorithm include a Central Processing Unit (CPU), a Many Integrated Core (MIC), two Graphic Processing Units (GPUs), and two Field-Programmable Gate Array (FPGA) devices all have differ- ent architectures are require different programming styles. OpenCL is a new programming standard that provides a common programming language between the different types of devices using a widely used programming environment. OpenCL follows the C99 Standard and provides support for devices with parallel computing capabilities to help create an optimized solution. Different ver- sions of the back projection algorithm are presented here to examine the flexibility of the OpenCL standard and to create the most optimal solution among the different devices. Timing measure- ments are compiled for each version of the algorithm for each device and compared against one another and a C++ single threaded host CPU implementation used as a baseline. The fastest imple- mentation for each device is then compared in terms of execution time, throughput, and maximum iii total dissipated energy (TDE). The presented OpenCL back projection solution provides a 90 times speedup (62.2 ms) on the CPU when compared to the baseline implementation (5680.7 ms) of the algorithm. The throughput for this CPU implementation is 1302.25 megabytes per second (MB/s) and the maximum TDE is 7.2 J per frame. iv To my entire family, especially my parents, for all of their love, support, and encouragement. v ACKNOWLEDGMENTS I would like to thank the following people for their support in making all of this possible and getting me to this point. • Dr. Eric Balster: For giving me this opportunity in graduate school and for providing the means and the push needed for me to complete this in a professional manner. • Kerry Hill: For funding and supporting my research. • Al Scarpelli: For funding and supporting my research. • Bill Turri: For supporting my research. • Andrew Kordik: For contributing his knowledge and insight in image projection and provid- ing me guidance along the way. • Jonathan Skeans: For providing help and knowledge in OpenCL and providing me guidance along the way. • David Mundy: It was rewarding to work alongside you in the lab. • Daniel Shaffer: For providing help with image projection. • David Fan: For his support in all things programming that allowed me to more quickly use the lab equipment and create testing scripts. vi • Dr. Frank Scarpino: For his knowledge in back projection and being on my defense com- mittee. • Dr. Vijayan Asari: For bearing through my thesis defense. • AFRL/UDRI/ADDA: For providing a great work environment and creating the framework and systems I used to finish my research and work. • Frank & Kathleen Badalamenti: I would like to thank my parents for all the love and sup- port they have provided me throughout my life. You are the best parents a son can ask for. • Adam Badalamenti: I would like to thank my brother for always being there for me. • Helena Badalamenti: I would like to thank my grandma for her support and reminders that I am getting old. • Buddy, Kiba, & Lotus: My dogs who are always there when I get home providing me with emotional support and helping to clear my mind of all the stress. vii TABLE OF CONTENTS ABSTRACT........................................... iii DEDICATION.........................................v ACKNOWLEDGMENTS.................................... vi LIST OF FIGURES.......................................x LIST OF TABLES....................................... xii I. INTRODUCTION....................................1 1.1 Objectives in Research...............................2 1.2 Significance of Research..............................2 1.2.1 Previous Optimization Attempts......................3 1.3 Thesis Organization................................3 II. OPENCL OVERVIEW..................................5 2.1 History of OpenCL.................................5 2.2 Programming in OpenCL.............................7 2.2.1 Host Programming.............................7 2.2.2 Kernel Programming............................ 12 III. BACK PROJECTION OVERVIEW........................... 14 3.1 Projection Background............................... 14 3.1.1 Image Projection.............................. 15 3.1.2 Back Projection.............................. 16 3.1.2.1 Collinearity Equations....................... 19 3.1.2.2 Digital Elevation Maps (DEMs).................. 20 viii IV. TEST PROCEDURE................................... 22 4.1 Test Hardware................................... 22 4.1.1 Intel Xeon E5-2670 v2 CPU........................ 23 4.1.2 Intel Xeon Phi 5110P........................... 24 4.1.3 Nvidia K10 GPU.............................. 24 4.1.4 Nvidia K40 GPU.............................. 25 4.1.5 Altera GSD5 FPGA............................ 26 4.1.6 Altera GSD8 FPGA............................ 27 4.2 Test Description.................................. 28 V. BACK PROJECTION ALGORITHM VERSIONS................... 32 5.1 Single Work Item.................................. 32 5.2 Single Threaded Work Group........................... 34 5.3 Row Wise Threaded................................ 36 5.4 Column Wise Threaded.............................. 38 VI. RESULTS......................................... 41 6.1 Timing Measurements............................... 41 6.1.1 Single Work Item Results......................... 42 6.1.2 Single Threaded Work Group Results................... 45 6.1.3 Row Wise Threaded Results........................ 48 6.1.4 Column Wise Threaded Results...................... 52 6.2 Comparison..................................... 55 6.2.1 Throughput................................. 57 6.2.2 Power Measurements........................... 58 VII. FINAL THOUGHTS................................... 60 7.1 Conclusion..................................... 60 7.2 Future Research.................................. 62 7.2.1 Examine Additional Memory Access Patterns.............. 62 7.2.2 Examine Additional Devices....................... 63 7.2.3 Channels.................................. 64 7.2.4 Integer Arithmetic............................. 64 BIBLIOGRAPHY........................................ 66 ix LIST OF FIGURES 2.1 Flow chart of OpenCL programming and execution.................7 2.2 The OpenCL framework................................8 2.3 Model of an OpenCL device regarding processing distribution............ 11 3.1 Back projection processing chain........................... 15 3.2 Back projection diagram................................ 16 3.3 The input aerial image provides little context of the image to the region....... 17 3.4 Back projected aerial image provides additional information to a viewer...... 18 3.5 Information about the region presented in the input image.............. 20 3.6 Sample 3x3 DEM grid................................. 21 4.1 Intel Xeon E5-2670 v2 CPU.............................. 23 4.2 Intel Xeon Phi 5110P................................. 24 4.3 Nvidia K10 GPU.................................... 25 4.4 Nvidia K40 GPU.................................... 26 4.5 BittWare board with an Altera GSD5 FPGA..................... 27 4.6 Nallatech board with an Altera GSD8 FPGA..................... 28 5.1 Single Work Item Diagram.............................. 33 x 5.2 Single Threaded Work Group Diagram........................ 35 5.3 Row Wise Threaded Diagram............................. 37 5.4 Column Wise Threaded Diagram........................... 39 6.1 Single Work Item Run Times............................. 42 6.2 Single Work Item FPGA Optimization Run Times.................. 43 6.3 Single Work Item FPGA Optimization Logic Utilization............... 44 6.4 Single Threaded Work Group Item Run Times.................... 46 6.5 Single Threaded Work Group FPGA Optimization Run Times............ 47 6.6 Single Threaded Work Group FPGA Logic Utilization................ 48 6.7 Row Wise Threaded Run Times............................ 49 6.8 Row Wise Threaded FPGA Optimization Run Times................. 50 6.9 Row Wise Threaded FPGA Optimization Logic Utilization............. 51
Recommended publications
  • Threads Chapter 4

    Threads Chapter 4

    Threads Chapter 4 Reading: 4.1,4.4, 4.5 1 Process Characteristics ● Unit of resource ownership - process is allocated: ■ a virtual address space to hold the process image ■ control of some resources (files, I/O devices...) ● Unit of dispatching - process is an execution path through one or more programs ■ execution may be interleaved with other process ■ the process has an execution state and a dispatching priority 2 Process Characteristics ● These two characteristics are treated independently by some recent OS ● The unit of dispatching is usually referred to a thread or a lightweight process ● The unit of resource ownership is usually referred to as a process or task 3 Multithreading vs. Single threading ● Multithreading: when the OS supports multiple threads of execution within a single process ● Single threading: when the OS does not recognize the concept of thread ● MS-DOS support a single user process and a single thread ● UNIX supports multiple user processes but only supports one thread per process ● Solaris /NT supports multiple threads 4 Threads and Processes 5 Processes Vs Threads ● Have a virtual address space which holds the process image ■ Process: an address space, an execution context ■ Protected access to processors, other processes, files, and I/O Class threadex{ resources Public static void main(String arg[]){ ■ Context switch between Int x=0; processes expensive My_thread t1= new my_thread(x); t1.start(); ● Threads of a process execute in Thr_wait(); a single address space System.out.println(x) ■ Global variables are
  • Lecture 10: Introduction to Openmp (Part 2)

    Lecture 10: Introduction to Openmp (Part 2)

    Lecture 10: Introduction to OpenMP (Part 2) 1 Performance Issues I • C/C++ stores matrices in row-major fashion. • Loop interchanges may increase cache locality { … #pragma omp parallel for for(i=0;i< N; i++) { for(j=0;j< M; j++) { A[i][j] =B[i][j] + C[i][j]; } } } • Parallelize outer-most loop 2 Performance Issues II • Move synchronization points outwards. The inner loop is parallelized. • In each iteration step of the outer loop, a parallel region is created. This causes parallelization overhead. { … for(i=0;i< N; i++) { #pragma omp parallel for for(j=0;j< M; j++) { A[i][j] =B[i][j] + C[i][j]; } } } 3 Performance Issues III • Avoid parallel overhead at low iteration counts { … #pragma omp parallel for if(M > 800) for(j=0;j< M; j++) { aa[j] =alpha*bb[j] + cc[j]; } } 4 C++: Random Access Iterators Loops • Parallelization of random access iterator loops is supported void iterator_example(){ std::vector vec(23); std::vector::iterator it; #pragma omp parallel for default(none) shared(vec) for(it=vec.begin(); it< vec.end(); it++) { // do work with it // } } 5 Conditional Compilation • Keep sequential and parallel programs as a single source code #if def _OPENMP #include “omp.h” #endif Main() { #ifdef _OPENMP omp_set_num_threads(3); #endif for(i=0;i< N; i++) { #pragma omp parallel for for(j=0;j< M; j++) { A[i][j] =B[i][j] + C[i][j]; } } } 6 Be Careful with Data Dependences • Whenever a statement in a program reads or writes a memory location and another statement reads or writes the same memory location, and at least one of the two statements writes the location, then there is a data dependence on that memory location between the two statements.
  • The Problem with Threads

    The Problem with Threads

    The Problem with Threads Edward A. Lee Electrical Engineering and Computer Sciences University of California at Berkeley Technical Report No. UCB/EECS-2006-1 http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.html January 10, 2006 Copyright © 2006, by the author(s). All rights reserved. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission. Acknowledgement This work was supported in part by the Center for Hybrid and Embedded Software Systems (CHESS) at UC Berkeley, which receives support from the National Science Foundation (NSF award No. CCR-0225610), the State of California Micro Program, and the following companies: Agilent, DGIST, General Motors, Hewlett Packard, Infineon, Microsoft, and Toyota. The Problem with Threads Edward A. Lee Professor, Chair of EE, Associate Chair of EECS EECS Department University of California at Berkeley Berkeley, CA 94720, U.S.A. [email protected] January 10, 2006 Abstract Threads are a seemingly straightforward adaptation of the dominant sequential model of computation to concurrent systems. Languages require little or no syntactic changes to sup- port threads, and operating systems and architectures have evolved to efficiently support them. Many technologists are pushing for increased use of multithreading in software in order to take advantage of the predicted increases in parallelism in computer architectures.
  • Enabling Hardware Accelerated Video Decode on Intel® Atom™ Processor D2000 and N2000 Series Under Fedora 16

    Enabling Hardware Accelerated Video Decode on Intel® Atom™ Processor D2000 and N2000 Series Under Fedora 16

    Enabling Hardware Accelerated Video Decode on Intel® Atom™ Processor D2000 and N2000 Series under Fedora 16 Application Note October 2012 Order Number: 509577-003US INFORMATIONLegal Lines and Disclaimers IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH INTEL PRODUCTS. NO LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL PROPERTY RIGHTS IS GRANTED BY THIS DOCUMENT. EXCEPT AS PROVIDED IN INTEL'S TERMS AND CONDITIONS OF SALE FOR SUCH PRODUCTS, INTEL ASSUMES NO LIABILITY WHATSOEVER AND INTEL DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY, RELATING TO SALE AND/OR USE OF INTEL PRODUCTS INCLUDING LIABILITY OR WARRANTIES RELATING TO FITNESS FOR A PARTICULAR PURPOSE, MERCHANTABILITY, OR INFRINGEMENT OF ANY PATENT, COPYRIGHT OR OTHER INTELLECTUAL PROPERTY RIGHT. A “Mission Critical Application” is any application in which failure of the Intel Product could result, directly or indirectly, in personal injury or death. SHOULD YOU PURCHASE OR USE INTEL'S PRODUCTS FOR ANY SUCH MISSION CRITICAL APPLICATION, YOU SHALL INDEMNIFY AND HOLD INTEL AND ITS SUBSIDIARIES, SUBCONTRACTORS AND AFFILIATES, AND THE DIRECTORS, OFFICERS, AND EMPLOYEES OF EACH, HARMLESS AGAINST ALL CLAIMS COSTS, DAMAGES, AND EXPENSES AND REASONABLE ATTORNEYS' FEES ARISING OUT OF, DIRECTLY OR INDIRECTLY, ANY CLAIM OF PRODUCT LIABILITY, PERSONAL INJURY, OR DEATH ARISING IN ANY WAY OUT OF SUCH MISSION CRITICAL APPLICATION, WHETHER OR NOT INTEL OR ITS SUBCONTRACTOR WAS NEGLIGENT IN THE DESIGN, MANUFACTURE, OR WARNING OF THE INTEL PRODUCT OR ANY OF ITS PARTS. Intel may make changes to specifications and product descriptions at any time, without notice. Designers must not rely on the absence or characteristics of any features or instructions marked “reserved” or “undefined”.
  • Moore's Law Motivation

    Moore's Law Motivation

    Motivation: Moore’s Law • Every two years: – Double the number of transistors CprE 488 – Embedded Systems Design – Build higher performance general-purpose processors Lecture 8 – Hardware Acceleration • Make the transistors available to the masses • Increase performance (1.8×↑) Joseph Zambreno • Lower the cost of computing (1.8×↓) Electrical and Computer Engineering Iowa State University • Sounds great, what’s the catch? www.ece.iastate.edu/~zambreno rcl.ece.iastate.edu Gordon Moore First, solve the problem. Then, write the code. – John Johnson Zambreno, Spring 2017 © ISU CprE 488 (Hardware Acceleration) Lect-08.2 Motivation: Moore’s Law (cont.) Motivation: Dennard Scaling • The “catch” – powering the transistors without • As transistors get smaller their power density stays melting the chip! constant 10,000,000,000 2,200,000,000 Transistor: 2D Voltage-Controlled Switch 1,000,000,000 Chip Transistor Dimensions 100,000,000 Count Voltage 10,000,000 ×0.7 1,000,000 Doping Concentrations 100,000 Robert Dennard 10,000 2300 Area 0.5×↓ 1,000 130W 100 Capacitance 0.7×↓ 10 0.5W 1 Frequency 1.4×↑ 0 Power = Capacitance × Frequency × Voltage2 1970 1975 1980 1985 1990 1995 2000 2005 2010 2015 Power 0.5×↓ Zambreno, Spring 2017 © ISU CprE 488 (Hardware Acceleration) Lect-08.3 Zambreno, Spring 2017 © ISU CprE 488 (Hardware Acceleration) Lect-08.4 Motivation Dennard Scaling (cont.) Motivation: Dark Silicon • In mid 2000s, Dennard scaling “broke” • Dark silicon – the fraction of transistors that need to be powered off at all times (due to power + thermal
  • Use of Hardware Acceleration on PC As of March, 2020

    Use of Hardware Acceleration on PC As of March, 2020

    Use of hardware acceleration on PC As of March, 2020 When displaying images of the camera using hardware acceleration of the PC, required the specifications of PC as folow. "The PC is equipped with specific hardware (CPU*1, GPU, etc.), and device drivers corresponding to those hardware are installed properly." ® *1: The CPU of the PC must support QSV(Intel Quick Sync Video). This information provides test results conducted under our environment and does not guarantee under all conditions. Please note that we used Internet Explorer for downloading at the following description and its procedures may differ if you use another browser software. Images may not be displayed, may be delayed or some of the images may be corrupted as follow, depends on usage conditions, performance and network environment of the PC. - When multiple windows are opened and operated on the PC - When sufficient bandwidth cannot be secured in your network environment - When the network driver of your computer is old (the latest version is recommended) *When the image is not displayed or the image is distorted, it may be improved by refreshing the browser. Applicable models: i-PRO EXTREME series models*2 (H.265/H.264 compatible models and H.265 compatible models) , i-PRO SmartHD series models*2 (H.264 compatible models) *2: You can find if it supports hardware acceleration by existence a setting item of [Drawing method] and [Decoding Options] in [Viewer software (nwcv4Ssetup.exe/ nwcv5Ssetup.exe)] of the setting menu of the camera. Items of the function that utilize PC hardware acceleration (Click the items as follow to go to each setting procedures.) 1.About checking if it supports "QSV" 2.
  • NVIDIA Ampere GA102 GPU Architecture Whitepaper

    NVIDIA Ampere GA102 GPU Architecture Whitepaper

    NVIDIA AMPERE GA102 GPU ARCHITECTURE Second-Generation RTX Updated with NVIDIA RTX A6000 and NVIDIA A40 Information V2.0 Table of Contents Introduction 5 GA102 Key Features 7 2x FP32 Processing 7 Second-Generation RT Core 7 Third-Generation Tensor Cores 8 GDDR6X and GDDR6 Memory 8 Third-Generation NVLink® 8 PCIe Gen 4 9 Ampere GPU Architecture In-Depth 10 GPC, TPC, and SM High-Level Architecture 10 ROP Optimizations 11 GA10x SM Architecture 11 2x FP32 Throughput 12 Larger and Faster Unified Shared Memory and L1 Data Cache 13 Performance Per Watt 16 Second-Generation Ray Tracing Engine in GA10x GPUs 17 Ampere Architecture RTX Processors in Action 19 GA10x GPU Hardware Acceleration for Ray-Traced Motion Blur 20 Third-Generation Tensor Cores in GA10x GPUs 24 Comparison of Turing vs GA10x GPU Tensor Cores 24 NVIDIA Ampere Architecture Tensor Cores Support New DL Data Types 26 Fine-Grained Structured Sparsity 26 NVIDIA DLSS 8K 28 GDDR6X Memory 30 RTX IO 32 Introducing NVIDIA RTX IO 33 How NVIDIA RTX IO Works 34 Display and Video Engine 38 DisplayPort 1.4a with DSC 1.2a 38 HDMI 2.1 with DSC 1.2a 38 Fifth Generation NVDEC - Hardware-Accelerated Video Decoding 39 AV1 Hardware Decode 40 Seventh Generation NVENC - Hardware-Accelerated Video Encoding 40 NVIDIA Ampere GA102 GPU Architecture ii Conclusion 42 Appendix A - Additional GeForce GA10x GPU Specifications 44 GeForce RTX 3090 44 GeForce RTX 3070 46 Appendix B - New Memory Error Detection and Replay (EDR) Technology 49 Appendix C - RTX A6000 GPU Perf ormance 50 List of Figures Figure 1.
  • Modifiable Array Data Structures for Mesh Topology

    Modifiable Array Data Structures for Mesh Topology

    Modifiable Array Data Structures for Mesh Topology Dan Ibanez Mark S Shephard February 27, 2016 Abstract Topological data structures are useful in many areas, including the various mesh data structures used in finite element applications. Based on the graph-theoretic foundation for these data structures, we begin with a generic modifiable graph data structure and apply successive optimiza- tions leading to a family of mesh data structures. The results are compact array-based mesh structures that can be modified in constant time. Spe- cific implementations for finite elements and graphics are studied in detail and compared to the current state of the art. 1 Introduction An unstructured mesh simulation code relies heavily on multiple core capabili- ties to deal with the mesh itself, and the range of features available at this level constrain the capabilities of the simulation as a whole. As such, the long-term goal towards which this paper contributes is the development of a mesh data structure with the following capabilities: 1. The flexibility to deal with evolving meshes 2. A highly scalable implementation for distributed memory computers 3. The ability to represent any of the conforming meshes typically used by Finite Element (FE) and Finite Volume (FV) methods 4. Minimize memory use 5. Maximize locality of storage 6. The ability to parallelize work inside supercomputer nodes with hybrid architecture such as accelerators This paper focuses on the first five goals; the sixth will be the subject of a future publication. In particular, we present a derivation for a family of structures with these properties: 1 1.
  • Research Into Computer Hardware Acceleration of Data Reduction and SVMS

    Research Into Computer Hardware Acceleration of Data Reduction and SVMS

    University of Rhode Island DigitalCommons@URI Open Access Dissertations 2016 Research Into Computer Hardware Acceleration of Data Reduction and SVMS Jason Kane University of Rhode Island, [email protected] Follow this and additional works at: https://digitalcommons.uri.edu/oa_diss Recommended Citation Kane, Jason, "Research Into Computer Hardware Acceleration of Data Reduction and SVMS" (2016). Open Access Dissertations. Paper 428. https://digitalcommons.uri.edu/oa_diss/428 This Dissertation is brought to you for free and open access by DigitalCommons@URI. It has been accepted for inclusion in Open Access Dissertations by an authorized administrator of DigitalCommons@URI. For more information, please contact [email protected]. RESEARCH INTO COMPUTER HARDWARE ACCELERATION OF DATA REDUCTION AND SVMS BY JASON KANE A DISSERTATION SUBMITTED IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF DOCTOR OF PHILOSOPHY IN COMPUTER ENGINEERING UNIVERSITY OF RHODE ISLAND 2016 DOCTOR OF PHILOSOPHY DISSERTATION OF JASON KANE APPROVED: Dissertation Committee: Major Professor Qing Yang Haibo He Joan Peckham Nasser H. Zawia DEAN OF THE GRADUATE SCHOOL UNIVERSITY OF RHODE ISLAND 2016 ABSTRACT Yearly increases in computer performance have diminished as of late, mostly due to the inability of transistors, the building blocks of computers, to deliver the same rate of performance seen in the 1980’s and 90’s. Shifting away from traditional CPU design, accelerator architectures have been shown to offer a potentially untapped solution. These architectures implement unique, custom hardware to increase the speed of certain tasking, such as graphics processing. The studies undertaken for this dissertation examine the ability of unique accelerator hardware to provide improved power and speed performance over traditional means, with an emphasis on classification tasking.
  • CUDA Binary Utilities

    CUDA Binary Utilities

    CUDA Binary Utilities Application Note DA-06762-001_v11.4 | September 2021 Table of Contents Chapter 1. Overview..............................................................................................................1 1.1. What is a CUDA Binary?...........................................................................................................1 1.2. Differences between cuobjdump and nvdisasm......................................................................1 Chapter 2. cuobjdump.......................................................................................................... 3 2.1. Usage......................................................................................................................................... 3 2.2. Command-line Options.............................................................................................................5 Chapter 3. nvdisasm.............................................................................................................8 3.1. Usage......................................................................................................................................... 8 3.2. Command-line Options...........................................................................................................14 Chapter 4. Instruction Set Reference................................................................................ 17 4.1. Kepler Instruction Set.............................................................................................................17
  • Lithe: Enabling Efficient Composition of Parallel Libraries

    Lithe: Enabling Efficient Composition of Parallel Libraries

    BERKELEY PAR LAB Lithe: Enabling Efficient Composition of Parallel Libraries Heidi Pan, Benjamin Hindman, Krste Asanović [email protected] {benh, krste}@eecs.berkeley.edu Massachusetts Institute of Technology UC Berkeley HotPar Berkeley, CA March 31, 2009 1 How to Build Parallel Apps? BERKELEY PAR LAB Functionality: or or or App Resource Management: OS Hardware Core 0 Core 1 Core 2 Core 3 Core 4 Core 5 Core 6 Core 7 Need both programmer productivity and performance! 2 Composability is Key to Productivity BERKELEY PAR LAB App 1 App 2 App sort sort bubble quick sort sort code reuse modularity same library implementation, different apps same app, different library implementations Functional Composability 3 Composability is Key to Productivity BERKELEY PAR LAB fast + fast fast fast + faster fast(er) Performance Composability 4 Talk Roadmap BERKELEY PAR LAB Problem: Efficient parallel composability is hard! Solution: . Harts . Lithe Evaluation 5 Motivational Example BERKELEY PAR LAB Sparse QR Factorization (Tim Davis, Univ of Florida) Column Elimination SPQR Tree Frontal Matrix Factorization MKL TBB OpenMP OS Hardware System Stack Software Architecture 6 Out-of-the-Box Performance BERKELEY PAR LAB Performance of SPQR on 16-core Machine Out-of-the-Box sequential Time (sec) Time Input Matrix 7 Out-of-the-Box Libraries Oversubscribe the Resources BERKELEY PAR LAB TX TYTX TYTX TYTX A[0] TYTX A[0] TYTX A[0] TYTX A[0] TYTX TYA[0] A[0] A[0]A[0] +Z +Z +Z +Z +Z +Z +Z +ZA[1] A[1] A[1] A[1] A[1] A[1] A[1]A[1] A[2] A[2] A[2] A[2] A[2] A[2] A[2]A[2]
  • Thread Scheduling in Multi-Core Operating Systems Redha Gouicem

    Thread Scheduling in Multi-Core Operating Systems Redha Gouicem

    Thread Scheduling in Multi-core Operating Systems Redha Gouicem To cite this version: Redha Gouicem. Thread Scheduling in Multi-core Operating Systems. Computer Science [cs]. Sor- bonne Université, 2020. English. tel-02977242 HAL Id: tel-02977242 https://hal.archives-ouvertes.fr/tel-02977242 Submitted on 24 Oct 2020 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Ph.D thesis in Computer Science Thread Scheduling in Multi-core Operating Systems How to Understand, Improve and Fix your Scheduler Redha GOUICEM Sorbonne Université Laboratoire d’Informatique de Paris 6 Inria Whisper Team PH.D.DEFENSE: 23 October 2020, Paris, France JURYMEMBERS: Mr. Pascal Felber, Full Professor, Université de Neuchâtel Reviewer Mr. Vivien Quéma, Full Professor, Grenoble INP (ENSIMAG) Reviewer Mr. Rachid Guerraoui, Full Professor, École Polytechnique Fédérale de Lausanne Examiner Ms. Karine Heydemann, Associate Professor, Sorbonne Université Examiner Mr. Etienne Rivière, Full Professor, University of Louvain Examiner Mr. Gilles Muller, Senior Research Scientist, Inria Advisor Mr. Julien Sopena, Associate Professor, Sorbonne Université Advisor ABSTRACT In this thesis, we address the problem of schedulers for multi-core architectures from several perspectives: design (simplicity and correct- ness), performance improvement and the development of application- specific schedulers.