shithub: gpufswip

ref: 8c9e01339dbc166b4682d883b7fb8e3261b7f5b1
dir: /slides/notes.txt/

View raw version
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

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