ref: 4e0f00c0b6767751e3c209f6704f4380e5f3f20d
dir: /slides/notes.txt/
# INTRO About myself: - Game developer - I like realtime rendering, shaders - Miss hardware acceleration on Plan 9 # WHAT IS A GPU? Coprocessor like FPU Separate computer - more complex than just a small coprocessor - own memory, power management, cores, instruction set "Graphics" processing unit - first 2d, later 3d - can do much more than graphics - last years: indirect rendering and mixing - GPGPU, compute shaders SIMD - GPUs are best example, because graphics - image: thousands of pixels, same process - GPU: run program thousand times, different data, in parallel - different architectures, generations, ... technical details (ignore) - hidden behind API # APPLICATION ARCHITECTURE before we dive into this slide Application - Game - mining machine - offline renderer - ... pic: - Only Application and Filesystem are relevant - everything else is abstracted Resource Abstraction - filesystem interface remains the same across implementations - bind different gpufs 9P Performance - could be big overhead! - to explore in the future Scalability on the application level - gpufs doesn't know the use case - application must scale - draw less - smaller detail, ... - distance culling, ... - gamedev - but: non-gamedev tasks (simulation, scientific tasks)? - slower is sometimes fine # INSPIRED BY VULKAN Designed by Khronos - designed OpenGL Lowlevel API - compared to DirectX and OpenGL - OGL: 100 LOC, Vulkan: 1000LOC Abstract and cross-platform - shader language SPIR-V - Available on win, linux (incl. Android), mac Shaders and buffers as objects - transfers to filesystem hierarchy pic: - application manages shader and buffer at filesystem level - compilation, loading to GPU - execution on GPU # COMPILE - High level (edited) - Spir-V binary - Native - GPU SPIR-V binary is cross-platform: - not machine-specific - "description" of the program - cross compilers - fully working # FILESYSTEM INTERFACE everything work in progress no guarantees things can change drastically Simple to understand - easy to develop applications - can be handled by hand Generic enough to be portable - Plan 9 is cross platform Plug and Play - same interface for all implementations - bind GPGPU first - future: only compute shader pic: filesystem overview - one buffer, one shader - ctl files pic: creating buffer and shader loading data pic: descriptor table 1 pool, 2 sets. first set with 4 bindings shader -> pool buffer -> specific binding confusing, refer to shader # EXAMPLE SHADER PROGRAM glsl, because SPIR-V too long and confusing Spir-V = 55 LOC (glsl: 12 LOC) important: - layout buffer (set 0, binding 1) - layout local_size_x -> workgroup size - gl_GlobalInvocationID layout buffer: - set and binding layout local_size_xyz: - workgroup size (will explain) gl_GlobalInvocationID: - which invocation (determine which data to use) # WORKGROUPS Number of workgroups: - specified when shader is run - 3d vector Workgroup size: - seen in shader program - 3d vector Total number of invocations -> gl_GlobalInvocationID example: 1000 invocations - # 100 size 10 - # 10 size 100 - can be huge performance difference # IMPLEMENTATION Draft Implementation: - at the time of writing the paper - focus on filesystem - paused because drawterm Drawterm: - actual GPU, vulkan sdk - verify and refine filesystem interface - fix issues Possible others: - Future! - e. g. SSE/CPU, network, hardware, ... Sadly nothing to show, but hopefully next time