DOCSLIB.ORG

Hacking on Mesa 3D

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Hacking on Mesa 3D Hacking on Mesa 3D Eleni Maria Stea <[email protected]> Introduction to Mesa 3D/OpenGL The most widely used open source OpenGL/Vulkan implementation Eleni Maria Stea Hacking on Mesa 3D 2 / 26 Introduction to Mesa 3D/OpenGL Historical I It started as an open source (MIT license) software OpenGL implementation. • swrast: software rasterizer I Then some hardware drivers were added as backends. • Intel, AMD Radeon, Nouveau, VMware virtual GPU I More APIs, specifications were implemented. • Vulkan • OpenGL ES1, ES2 & ES3 • OpenCL, OpenVG, VDPAU, XVMC, EGL interface I More software drivers were written. • llvmpipe, softpipe Eleni Maria Stea Hacking on Mesa 3D 3 / 26 Introduction to Mesa 3D/OpenGL Mesa 3d is a big project :-) We are going to focus on the OpenGL development. Eleni Maria Stea Hacking on Mesa 3D 4 / 26 Introduction to Mesa 3D/OpenGL The OpenGL API as part of the Linux Graphics Stack Indirect Rendering GLX (OpenGL extension to the X window system) Direct Rendering DRI (Direct Rendering Infrastructure) DRM (Direct Rendering Manager) A combination of the two https://en.wikipedia.org/wiki/Mesa_(computer_graphics) GLX + AIGLX (Accelerated Indirect GLX) Eleni Maria Stea Hacking on Mesa 3D 5 / 26 Developing the OpenGL So, what’s our contribution to the OpenGL implementation? I we write extensions (16-bits etc) I we add new features for the extensions to work I testing and bug fixes I releases This means that we occasionally make changes to: I the mesa core I the glsl compiler I the hardware drivers I and anywhere else needed Eleni Maria Stea Hacking on Mesa 3D 6 / 26 Developing the OpenGL OpenGL Extensions 1/4 : The concept behind I OpenGL is extensible by design. I Any hardware manufacturer who wishes to add a new feature that was missing from OpenGL can write an extension to provide it. I Any user wishing to use the feature can then use the extension through the extension mechanism. I Khronos group (that releases the OpenGL spec) decides which extensions will become part of the next OpenGL core version. I The manufacturers that write their own OpenGL implementations (Nvidia, Apple, Intel/Mesa, AMD/Mesa etc) and wish to release that new version must implement all the extensions that have been decided to be part of the core. Eleni Maria Stea Hacking on Mesa 3D 7 / 26 Developing the OpenGL OpenGL Extensions 2/4: Τhe specs OpenGL Registry git clone https://github.com/KhronosGroup/OpenGL-Registry.git Extensions Specifications I overview, contributors etc I dependencies I errors I detailed descriptions Eleni Maria Stea Hacking on Mesa 3D 8 / 26 Developing the OpenGL OpenGL Extensions 3/4: Required changes Adding a new extension requires changes in the API, the hardware drivers code (see i965), to the GLSL compiler and elsewhere. $ ack-grep -i -l ARB_shader_storage_buffer_object mesa include/GL/glcorearb.h mesa/src/mapi/glapi/registry/gl.xml include/GL/glext.h mesa/src/mapi/glapi/gen/meson.build src/mapi/glapi/registry/gl.xml mesa/src/mapi/glapi/gen/Makefile.am src/mapi/glapi/gen/Makefile.am mesa/src/mapi/glapi/gen/Makefile src/mapi/glapi/gen/gl_API.xml src/mesa/drivers/dri/i965/intel_extensions.c mesa/src/mapi/glapi/gen/Makefile.in src/mesa/main/extensions_table.h mesa/src/mapi/glapi/gen/gl_API.xml src/mesa/main/context.c mesa/src/mesa/drivers/dri/i965/intel_extensions.c src/mesa/main/mtypes.h mesa/src/mesa/main/extensions_table.h mesa/src/mesa/main/context.c src/mesa/main/bufferobj.c src/mesa/main/get.c mesa/src/mesa/main/mtypes.h src/mesa/main/version.c mesa/src/mesa/main/bufferobj.c src/mesa/main/get_hash_params.py mesa/src/mesa/main/get.c mesa/src/mesa/main/version.c src/mesa/main/uniforms.c mesa/src/mesa/main/get_hash_params.py src/mesa/state_tracker/st_extensions.c src/compiler/glsl/glsl_lexer.ll mesa/src/mesa/main/uniforms.c src/compiler/glsl/ir.h mesa/src/mesa/state_tracker/st_extensions.c mesa/src/compiler/glsl/glsl_lexer.ll src/compiler/glsl/ast_function.cpp mesa/src/compiler/glsl/ir.h src/compiler/glsl/glsl_parser_extras.cpp src/compiler/glsl/glsl_parser_extras.h mesa/src/compiler/glsl/ast_function.cpp mesa/include/GL/glcorearb.h mesa/src/compiler/glsl/glsl_parser_extras.cpp mesa/include/GL/glext.h mesa/src/compiler/glsl/glsl_parser_extras.h Eleni Maria Stea Hacking on Mesa 3D 9 / 26 Developing the OpenGL GLSL/GLSL Compiler In the previous slide we mentioned a ... GLSL compiler What’s the purpose of using a compiler into a graphics API? Eleni Maria Stea Hacking on Mesa 3D 10 / 26 Developing the OpenGL Rendering με το OpenGL : how we use the API Remember that every OpenGL object is made by primitives! Eleni Maria Stea Hacking on Mesa 3D 11 / 26 Developing the OpenGL The OpenGL Pipeline : Fully Programmable using the GLSL http://chamilo2.grenet.fr/inp/courses/ENSIMAG4MMG3D/document/instructions/practical_01.html Eleni Maria Stea Hacking on Mesa 3D 12 / 26 Developing the OpenGL GLSL->GLSL IR->NIR->ASM From OpenGL Shading Language to Assembly I GLSL I GLSL IR I NIR : SSA (Single Static Assignment) + non SSA I Native Code Eleni Maria Stea Hacking on Mesa 3D 13 / 26 Developing the OpenGL GLSL->GLSL IR->NIR->ASM 1/4 Let us examine a very simple OpenGL program: GLSL attribute vec4 vertex; void main() { gl_Position = vertex; } GLSL IR ( (declare (location=0 shader_out ) vec4 gl_Position) (declare (location=17 shader_in ) vec4 vertex) ( function main (signature void (parameters ) ( (assign (xyzw) (var_ref gl_Position) (var_ref vertex) ) )) ) ) Eleni Maria Stea Hacking on Mesa 3D 14 / 26 Developing the OpenGL GLSL->GLSL IR->NIR->ASM 2/4 NIR (ssa form) decl_var shader_in INTERP_MODE_NONE vec4 vertex (VERT_ATTRIB_GENERIC0, 17, 0) decl_var shader_out INTERP_MODE_NONE vec4 gl_Position (VARYING_SLOT_POS, 0, 0) decl_function main returning void impl main { block block_0: /* preds: */ vec1 32 ssa_0 = load_const (0x00000000 /* 0.000000 */) vec4 32 ssa_1 = intrinsic load_input (ssa_0) () (0, 0) /* base=0 */ /* component=0 */ intrinsic store_output (ssa_1, ssa_0) () (0, 15, 0) /* base=0 */ /* wrmask=xyzw */ /* component=0 */ /* gl_Position */ /* succs: block_0 */ block block_0: } Eleni Maria Stea Hacking on Mesa 3D 15 / 26 Developing the OpenGL GLSL->GLSL IR->NIR->ASM 3/4 NIR (final form) decl_var shader_in INTERP_MODE_NONE vec4 vertex (VERT_ATTRIB_GENERIC0, 17, 0) decl_var shader_out INTERP_MODE_NONE vec4 gl_Position (VARYING_SLOT_POS, 0, 0) decl_function main returning void impl main { block block_0: /* preds: */ vec1 32 ssa_0 = load_const (0x00000000 /* 0.000000 */) vec4 32 ssa_1 = intrinsic load_input (ssa_0) () (0, 0) /* base=0 */ /* component=0 */ intrinsic store_output (ssa_1, ssa_0) () (0, 15, 0) /* base=0 */ /* wrmask=xyzw */ /* component=0 */ /* gl_Position */ /* succs: block_0 */ block block_0: } Eleni Maria Stea Hacking on Mesa 3D 16 / 26 Developing the OpenGL GLSL->GLSL IR->NIR->ASM 4/4 Native Code START B0 (26 cycles) mov(8) g123<1>UD g1<8,8,1>UD { align1 WE_all 1Q compacted }; mov(8) g124<1>F g2<8,8,1>F { align1 1Q compacted }; mov(8) g125<1>F g3<8,8,1>F { align1 1Q compacted }; mov(8) g126<1>F g4<8,8,1>F { align1 1Q compacted }; mov(8) g127<1>F g5<8,8,1>F { align1 1Q compacted }; send(8) null<1>F g123<8,8,1>F urb 1 SIMD8 write mlen 5 rlen 0 { align1 1Q EOT }; nop ; END B0 Eleni Maria Stea Hacking on Mesa 3D 17 / 26 Debugging Tools GLSL->GLSL IR->NIR->ASM Debugging We can test the intermediate representations using some Mesa environment variables for the drivers $ export INTEL_DEBUG=vs $ export INTEL_DEBUG=fs $ export INTEL_DEBUG=vs,fs, ... Like in the following example ;-) Eleni Maria Stea Hacking on Mesa 3D 18 / 26 Debugging Tools OpenGL Extensions 4/4: Testing & Debugging And since we mentioned Debugging... There’s a process through which we can test our OpenGL extensions implementations. I For every new core feature that is added to OpenGL, developers (usually from Khronos group) write a test that tests the feature. I This test performs the same operation using software rendering and shaders and compares the output of each. I VK-GL-CTS: https://github.com/KhronosGroup/VK-GL-CTS I Every manufacturer can run the tests on its own implementation of an OpenGL version to make sure that the features of that version work fine. I When a test fails and the bug is not in the test, we know that probably our driver has a problem. I We also check for regressions from version to version or for cases where a feature might break another one (a test that used to run without errors doesn’t do that anymore). Eleni Maria Stea Hacking on Mesa 3D 19 / 26 Debugging Tools Other Debugging Tools Some useful tools for when a problem is detected. I GDB I MESA environment variables: https://www.mesa3d.org/envvars.html • We can dump and replace information (asm, IR, GLSL code) • We can switch between GL versions • We can test different code paths We can test driver specific operations • only get a look at the website :) I Some safe environments to run our experiments: chroot, jhbuild shell Eleni Maria Stea Hacking on Mesa 3D 20 / 26 Debugging Tools Debuging mesa, debugging open source graphics apps, debugging anything! We can debug any graphics app!! Mesa provides debugging tools for: I mesa itself I other open source graphics applications I even for proprietary software! Eleni Maria Stea Hacking on Mesa 3D 21 / 26 Debugging Tools Replacing the shaders’ code Limbo Showcase: No matter if we have a program’s source code, we can test but also modify its shaders while it’s running. I $ export MESA_SHADER_DUMP_PATH=‘pwd‘/dump_sdr/ I $ export MESA_SHADER_READ_PATH=‘pwd‘/read_sdr/ Eleni Maria Stea Hacking on Mesa 3D 22 / 26 Contributions How could someone
Load more

Recommended publications
  • Reverse Engineering Power Management on NVIDIA Gpus - Anatomy of an Autonomic-Ready System Martin Peres
    Reverse Engineering Power Management on NVIDIA GPUs - Anatomy of an Autonomic-ready System Martin Peres To cite this version: Martin Peres. Reverse Engineering Power Management on NVIDIA GPUs - Anatomy of an Autonomic-ready System. ECRTS, Operating Systems Platforms for Embedded Real-Time appli- cations 2013, Jul 2013, Paris, France. hal-00853849 HAL Id: hal-00853849 https://hal.archives-ouvertes.fr/hal-00853849 Submitted on 23 Aug 2013 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. Reverse engineering power management on NVIDIA GPUs - Anatomy of an autonomic-ready system Martin Peres Ph.D. student at LaBRI University of Bordeaux Hobbyist Linux/Nouveau Developer Email: [email protected] Abstract—Research in power management is currently limited supported nor documented by NVIDIA. As GPUs are leading by the fact that companies do not release enough documentation the market in terms of performance-per-Watt [3], they are or interfaces to fully exploit the potential found in modern a good candidate for a reverse engineering effort of their processors. This problem is even more present in GPUs despite power management features. The choice of reverse engineering having the highest performance-per-Watt ratio found in today’s NVIDIA’s power management features makes sense as they processors.
    [Show full text]
  • High Speed Visualization in the Jetos Aviation Operating System Using Hardware Acceleration*
    High Speed Visualization in the JetOS Aviation Operating System Using Hardware Acceleration* Boris Barladian[0000-0002-2391-2067], Nikolay Deryabin[0000-0003-1248-6047], Alexey Voloboy[0000-0003-1252-8294], Vladimir Galaktionov[0000-0001-6460-7539], and Lev Shapiro[0000-0002-6350-851X] The Keldysh Institute of the Applied Mathematics of RAS, Moscow, Russia [email protected],{voloboy, vlgal, pls}@gin.keldysh.ru Abstract. The paper discusses details of the pilot display visualization that uses the hardware acceleration capabilities of the Vivante graphics processor in the JetOS aviation operating system. Previously the OpenGL Safety Critical library was implemented without hardware acceleration. This was done in such a way because software library is easier to certify in accordance with the avionics re- quirements. But usage of the software OpenGL does not provide acceptable visualization speed for modern Flight Display and 3D relief applications. So more complex visualization approach utilized the GPU acceleration capabilities was elaborated. Although the OpenGL library was implemented for a specific GPU and took into account its specificity, the described approach to adapt the MESA open source library can be used for other GPUs. An effective algorithm for multi-window visualization using the implemented library with hardware acceleration is present. The described approach allows you to achieve the visu- alization speed acceptable for the pilot display of the aircraft. Keywords: Pilot Display, Embedded Systems, Real-time Operating System, OpenGL Safety Critical, Multi-windowing. 1 Introduction In [1] requirements were formulated for a real-time operating system (RTOS) de- signed to work with integrated modular avionics. In particular, the RTOS should comply with the ARINC 653 standard [2].
    [Show full text]
  • Porting Tizen-IVI 3.0 to an ARM Based Soc Platform
    Porting Tizen-IVI 3.0 to an ARM based SoC Platform Damian Hobson-Garcia Automotive Linux Summit July 1-2, 2014 Tokyo, Japan Tizen IVI support Until recently… Intel architecture (x86) system – Tizen IVI 2.0alpha, Tizen IVI 3.0 ARM architecture based system – Tizen IVI 2.0alpha (ivi-panda) Need to port Tizen IVI 3.0 to ARM ourselves Current State of Affairs Intel architecture (x86) system – Tizen IVI 2.0alpha, Tizen IVI 3.0 – Tizen Common NEW ARM architecture based system – Tizen IVI 2.0alpha (ivi-panda) – Tizen Common NEW Tizen IVI now based on Tizen Common – Lots of reuse Target Platform Renesas R-Car Gen2 series platform R-Car M2 – ARM Cortex A15 x2 R-Car H2 – ARM Cortex A15 x4, + ARM Cortex A7 x4 (option) 3D Graphics System – Imagination Technologies PowerVR series On board IP blocks – H/W video decode/encode – image processing Agenda Objective Methodology Porting Tasks – Weston/Wayland Integration – WebKit Integration – GStreamer Integration Objective Tizen IVI 3.0 on R-Car M2/H2 1. Standard Native Applications – Terminal program – Open GL/ES applications 2. Web – Browser and web applications 3. Multimedia – Video playback (1080p @ 30fps) Local Build Methodology Tizen IVI 3.0 milestone releases we used: – M2-Sep (released Oct 11, 2013) – M2-EOY (released Jan 15, 2014) – M2-March2014 (released April 11, 2014) Non-hardware dependant packages – Rebuild for ARM instruction set Hardware dependant packages – Replace/update with R-Car M2/H2 support Tizen Common/IVI Rebase Methodology Reuse Tizen Common ARM support for Tizen
    [Show full text]
  • SUSE® Linux Enterprise Desktop 12 and the Workstation Extension: What's New ?
    SUSE® Linux Enterprise Desktop 12 and the Workstation Extension: What's New ? Frédéric Crozat <[email protected]> Enterprise Desktop Release Manager Scott Reeves <[email protected]> Enterprise Desktop Development Manager Agenda • Design Criteria • Desktop Environment in SUSE Linux Enterprise 12 • GNOME Shell • Desktop Features and Applications 2 Design Criteria SUSE Linux Enterprise Desktop Interoperability Ease of Use Security Ease of Management Lower Costs 4 SUSE Linux Enterprise Desktop 12 • Focus on technical workstation ‒ Developers and System administrators • One tool for the job • Main desktop applications will be shipped: ‒ Mail client, Office Suite, Graphical Editors, ... • SUSE Linux Enterprise Workstation Extension ‒ Extend SUSE Linux Enterprise Server with packages only available on SUSE Linux Enterprise Desktop. (x86-64 only) 5 Desktop in SUSE Linux Enterprise 12 As Part of the Common Code Base SUSE Linux Enterprise 12 Desktop Environment • SUSE Linux Enterprise 12 contains one primary desktop environment • Additional light-weight environment for special use-cases: ‒ Integrated Systems • Desktop environment is shared between the server and desktop products 7 SUSE Linux Enterprise 12 Desktop Environment • GNOME 3 is the main desktop environment ‒ SLE Classic mode by default ‒ GNOME 3 Classic Mode and GNOME 3 Shell Mode also available • SUSE Linux Enterprise 12 ships also lightweight IceWM ‒ Targeted at Integrated Systems • QT fully supported: ‒ QT5 supported for entire SLE12 lifecycle ‒ QT4 supported, will be removed in future
    [Show full text]
  • The Linux Graphics Stack Attributions
    I - Hardware : Anatomy of a GPU II - Host : The Linux graphics stack Attributions Introduction to GPUs and to the Linux Graphics Stack Martin Peres CC By-SA 3.0 Nouveau developer Ph.D. student at LaBRI November 26, 2012 1 / 36 I - Hardware : Anatomy of a GPU II - Host : The Linux graphics stack Attributions General overview Outline 1 I - Hardware : Anatomy of a GPU General overview Driving screens Host < − > GPU communication 2 II - Host : The Linux graphics stack General overview DRM and libdrm Mesa X11 Wayland X11 vs Wayland 3 Attributions Attributions 2 / 36 I - Hardware : Anatomy of a GPU II - Host : The Linux graphics stack Attributions General overview General overview of a modern GPU's functions Display content on a screen Accelerate 2D operations Accelerate 3D operations Decode videos Accelerate scientific calculations 3 / 36 I - Hardware : Anatomy of a GPU II - Host : The Linux graphics stack Attributions General overview CPU Clock Front-side Graphics Generator bus card slot Chipset Memory Slots High-speed graphics bus (AGP or PCI Northbridge Memory Express) bus (memory controller hub) Internal Bus PCI Bus Onboard Southbridge graphics PCI (I/O controller controller Bus hub) IDE SATA USB Cables and Ethernet ports leading Audio Codec CMOS Memory off-board PCI Slots LPC Bus Super I/O Serial Port Parallel Port Flash ROM Floppy Disk Keyboard (BIOS) Mouse 4 / 36 I - Hardware : Anatomy of a GPU II - Host : The Linux graphics stack Attributions General overview Hardware architecture GPU: Where all the calculations are made VRAM: Stores
    [Show full text]
  • Release Notes for Xfree86® 4.8.0 the Xfree86 Project, Inc December 2008
    Release Notes for XFree86® 4.8.0 The XFree86 Project, Inc December 2008 Abstract This document contains information about the various features and their current sta- tus in the XFree86 4.8.0 release. 1. Introduction to the 4.x Release Series XFree86 4.0 was the first official release of the XFree86 4 series. The current release (4.8.0) is the latest in that series. The XFree86 4.x series represents a significant redesign of the XFree86 X server,with a strong focus on modularity and configurability. 2. Configuration: aQuickSynopsis Automatic configuration was introduced with XFree86 4.4.0 which makes it possible to start XFree86 without first creating a configuration file. This has been further improved in subsequent releases. If you experienced any problems with automatic configuration in a previous release, it is worth trying it again with this release. While the initial automatic configuration support was originally targeted just for Linux and the FreeBSD variants, as of 4.5.0 it also includes Solaris, NetBSD and OpenBSD support. Full support for automatic configuration is planned for other platforms in futurereleases. If you arerunning Linux, FreeBSD, NetBSD, OpenBSD, or Solaris, try Auto Configuration by run- ning: XFree86 -autoconfig If you want to customise some things afterwards, you can cut and paste the automatically gener- ated configuration from the /var/log/XFree86.0.log file into an XF86Config file and make your customisations there. If you need to customise some parts of the configuration while leav- ing others to be automatically detected, you can combine a partial static configuration with the automatically detected one by running: XFree86 -appendauto If you areusing a platform that is not currently supported, then you must try one of the older methods for getting started like "xf86cfg", which is our graphical configuration tool.
    [Show full text]
  • Integration of the Chromium Browser in the GENIVI Platform
    static void _f_do_barnacle_install_properties(GObjectClass *gobject_class) { GParamSpec *pspec; Integration of the Chromium /* Party code attribute */ pspec = g_param_spec_uint64 (F_DO_BARNACLE_CODE, Browser in the GENIVI Platform "Barnacle code.", "Barnacle code", 0, G_MAXUINT64, G_MAXUINT64 /* default value */, G_PARAM_READABLE | G_PARAM_WRITABLE | G_PARAM_PRIVATE); Jacobo Aragunde Pérez g_object_class_install_property (gobject_class, blogs.igalia.com/jaragunde F_DO_BARNACLE_PROP_CODE, ● Open Source experts and consultants ● 15 years of experience ● Important contributions to: ● Client-side web technologies: WebKit, Blink/Chromium, Servo ● Graphics & Multimedia: Mesa, GStreamer ● Compilers: V8, JavaScriptCore, SpiderMonkey, Guile ● Software-defined networking: Snabb ● ... Introduction Goals of the project ● Integrate full-featured Chromium browser in GDP ● Use Intel’s Ozone-Wayland project, most complete implementation of Wayland so far ● Get latest possible version of the browser working ● Analyze and fix multi-seat implementation, if required ● Funding: GENIVI challenge grant and Igalia contributions Elements and versions ● Chromium: latest stable release was 54 at that point ● Ozone-Wayland: latest branch supports Chromium 53 ● Meta-browser: supporting Chromium 48 ● GENIVI BSPs Rebase & integrate Chromium browser Work on meta-browser ● Simplify configuration ● Obsolete CHROMIUM_ENABLE_WAYLAND detection ● Build chromium+wayland version 53 ● Recipe was pointing to version 48 ● Required patch backport ● Fix specific build scenarios
    [Show full text]
  • Instability Thresholds and Dynamics of Mesa Patterns in Reaction-Diffusion Systems
    Instability thresholds and dynamics of mesa patterns in reaction-diffusion systems Rebecca McKay and Theodore Kolokolnikov Department of Mathematics and Statistics, Dalhousie University, Canada Abstract We consider a class of one-dimensional reaction-diffusion systems, u = ε2u + f(u, w) t xx . 0= Dw + g(u, w) xx Under some generic conditions on the nonlinearities f,g, in the singular limit ε 0, and for a fixed D independent of ε, such a system exhibits a steady state consisting→ of sharp back-to-back interfaces which is stable in time. On the other hand, it is also known that in the so-called shadow limit D = , the periodic pattern having more than one interface is unstable. In this paper, we analyse∞ in detail the transition between the stable patterns when D = O(1) and the shadow system when D = . We show that this transition occurs when D is exponentially large in ε and we derive instability∞ thresholds D D D . such 1 2 3 that a periodic pattern with 2K interfaces is stable if D<DK and is unstable when D>DK . We also study the dynamics of the interfaces when D is exponentially large; this allows us to describe in detail the mechanism leading to the instability. Direct numerical computations of stability and dynamics are performed; excellent agreement with the asymptotic results is observed. 1 Introduction One of the most prevalent phenomena observed in reaction-diffusion systems is the formation of mesa patterns. Such patterns consist of a sequence of highly localized interfaces (or kinks) that are separated in space by regions where the solution is nearly constant.
    [Show full text]
  • Mechdyne-TGX-2.1-Installation-Guide
    TGX Install Guide Version 2.1.3 Mechdyne Corporation March 2021 TGX INSTALL GUIDE VERSION 2.1.3 Copyright© 2021 Mechdyne Corporation All Rights Reserved. Purchasers of TGX licenses are given limited permission to reproduce this manual, provided the copies are for their use only and are not sold or distributed to third parties. All such copies must contain the title page and this notice page in their entirety. The TGX software program and accompanying documentation described herein are sold under license agreement. Their use, duplication, and disclosure are subject to the restrictions stated in the license agreement. Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor's standard commercial license. This publication is provided “as is” without warranty of any kind, either express or implied, including, but not limited to, the implied warranties of merchantability, fitness for a particular purpose, or non- infringement. Any Mechdyne Corporation publication may include inaccuracies or typographical errors. Changes are periodically made to these publications, and changes may be incorporated in new editions. Mechdyne may improve or change its products described in any publication at any time without notice. Mechdyne assumes no responsibility for and disclaims all liability for any errors or omissions in this publication. Some jurisdictions do not allow the exclusion of implied warranties, so the above exclusion may not apply. TGX is a trademark of Mechdyne Corporation. Windows® is registered trademarks of Microsoft Corporation. Linux® is registered trademark of Linus Torvalds.
    [Show full text]
  • Panfrost: Liberating ARM Gpus
    Panfrost: Liberating ARM GPUs Robert Foss @memcpy_io http://memcpy.io $ whoami Robert Foss - Based in Berlin - Work in Open Source - Specialize in Linux Graphics $ whoami Robert Foss - Based in Berlin - Work in Open Source - Specialize in Linux Graphics $ whoami Robert Foss - Based in Berlin - Work in Open Source - Specialize in Linux Graphics ARM GPUs Mali 2/3/4XX - Codenamed Utgard - Supported by Lima driver - Supports OpenGL ES <= 2.0 - Acquired with Phalanx Mali T-XXX - Codenamed Midgard - Supported by Panfrost driver - Supports OpenGL ES <= 3.1 - Supports Vulkan <= 1.0 - Design targeted OpenCL heavily Mali G-XX - Codenamed Bifrost - Supported by Panfrost driver - Supports OpenGL ES <= 3.2 - Supports Vulkan <= 1.1 - Partial re-design of Midgard Mali G-YY - Codenamed Valhall - Supports OpenGL ES <= 3.2 - Supports Vulkan <= 1.1 - New ISA & Compute core Driver History Driver History 7 1 0 2 Reverse EngineeringPanfrost Shader Loader Panfrost Prototype Panfrost Wayland 0 2 0 2 Driver History 7 1 0 2 Kernel and Mesa Panfrost committed Mali T820 Mali T720 0 2 0 2 Panfrost Today Panfrost Today - Deployed on Mali T720, T820 & T860 Panfrost Today - Deployed on Mali T720, T820 & T860 - Runs normal Desktop Environments Panfrost Today - Deployed on Mali T720, T820 & T860 - Runs normal Desktop Environments - Supports OpenGL ES <= 2.0 Panfrost Today - Deployed on Mali T720, T820 & T860 - Runs normal Desktop Environments - Supports OpenGL ES <= 2.0 - OpenGL ES 3.0 soon, with 3.1 & 3.2 coming Panfrost Today - Deployed on Mali T720, T820 & T860 - Runs
    [Show full text]
  • TG-Gallium Driver Stack Softpipe, Cell and Beyond
    TG-Gallium Driver Stack Softpipe, Cell and Beyond Keith Whitwell [email protected] DRI Driver Model drm App Mesa DRI Driver DRI ● Leaky interface between Mesa and driver. ● Drivers getting bigger, more complex. ● API, OS dependencies encoded in driver. Keith Whitwell [email protected] Impose new interfaces drm App Mesa DRI Driver DRI ● Isolate interactions with API, OS, HW. ● Identify new interfaces. ● Split the driver. Keith Whitwell [email protected] A New Model drm Gallium State OS, App Mesa HW tracker Winsys Driver DRI ● New components: – State tracker, HW driver, Winsys. ● The TG-Gallium driver stack. Keith Whitwell [email protected] Gallium Driver Model ● Driver interface inspired by GL3, NV_GPU4, i965 hardware, etc. ● Constant state objects. ● Simple drawing interface. ● Unified shading language, as bytecode. ● Private buffers as render targets. ● Ability to re-target HW drivers to new APIs (eg. GL3, GLES, ???). ● Ability to re-target HW drivers to new window systems, OS's. Keith Whitwell [email protected] Gallium Driver Model ● Driver interface inspired by GL3, NV_GPU4, i965 hardware, etc. ● Constant state objects. ● Simple drawing interface. – DrawArrays, DrawElements ● Unified shading language, as bytecode. ● Private buffers as render targets. ● Fullscreen clears. ● Other blits?? Maybe subject to strict restrictions. Keith Whitwell [email protected] Gallium HW Driver ● Significantly simpler than a DRI driver. ● Interface: – Create/Bind/Delete state objects – Draw – one or two entrypoints. – Buffer management and fencing. – Flush ● Each Gallium driver defines its own OS- level (current name: winsys) interface. ● Re-target driver by re-implementing the winsys layer, eg. miniglx, EGL, etc. Keith Whitwell [email protected] Mesa State Tracker ● Implements current Mesa driver model.
    [Show full text]
  • HOW to VISUALIZE YOUR GPU-ACCELERATED SIMULATION RESULTS Peter Messmer, NVIDIA
    HOW TO VISUALIZE YOUR GPU-ACCELERATED SIMULATION RESULTS Peter Messmer, NVIDIA RANGE OF ANALYSIS AND VIZ TASKS . Analysis: Focus quantitative . Visualization: Focus qualitative . Monitoring, Steering TRADITIONAL HPC WORKFLOW Workstation Analysis, Setup Visualization Supercomputer Viz Cluster Dump, Checkpointing Visualization, Analysis File System TRADITIONAL WORKFLOW: CHALLENGES Lack of interactivity prevents “intuition” Workstation High-end viz Analysis, neglected due Setup Visualization to workflow complexity Supercomputer Viz Cluster Viz resources need I/O becomes main to scale with simulation Dump, simulation bottleneck Checkpointing Visualization, Analysis File System OUTLINE . Visualization applications . CUDA/OpenGL interop . Remote viz . Parallel viz . In-Situ viz High-level overview. Some parts platform dependent. Check with your sysadmin. VISUALIZATION APPLICATIONS NON-REPRESENTATIVE VIZ TOOLS SURVEY OF 25 HPC SITES Surveyed sites: LLNL LLNL- ORNL- AFRL- NASA- NERSC -OCF SCF LANL CCS DOD-ORC DSCR AFRL ARL ERDC NAVY MHPCC ORS CCAC NAS NASA-NCCS TACC CHPC RZG HLRN Julich CSCS CSC Hector Curie NON-REPRESENTATIVE VIZ TOOLS SURVEY OF 25 HPC SITES Surveyed sites: LLNL LLNL- ORNL- AFRL- NASA- NERSC -OCF SCF LANL CCS DOD-ORC DSCR AFRL ARL ERDC NAVY MHPCC ORS CCAC NAS NASA-NCCS TACC CHPC RZG HLRN Julich CSCS CSC Hector Curie VISIT . Scalar, vector and tensor field data features — Plots: contour, curve, mesh, pseudo-color, volume,.. — Operators: slice, iso-surface, threshold, binning,.. Quantitative and qualitative analysis/vis — Derived fields, dimension reduction, line-outs — Pick & query . Scalable architecture . Open source http://wci.llnl.gov/codes/visit/ VISIT . Cross-platform — Linux/Unix, OSX, Windows . Wide range of data formats — .vtk, .netcdf, .hdf5,.. Extensible — Plugin architecture . Embeddable . Python scriptable VISIT’S SCALABLE ARCHITECTURE .
    [Show full text]