ref: a0260e238add3ca2bd1e37f31bdad3df9ee4296e
parent: d71350aeb45126043b62c70974d069389c05be03
author: sirjofri <[email protected]>
date: Fri Apr 12 15:31:24 EDT 2024
adds notes
--- a/slides/notes.txt
+++ b/slides/notes.txt
@@ -2,18 +2,23 @@
About myself:
- Game developer
-- I like shaders
+- 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
-- GPGPU
+ - last years: indirect rendering and mixing
+- GPGPU, compute shaders
SIMD
- GPUs are best example, because graphics
@@ -20,16 +25,30 @@
- 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
+- to explore in the future
Scalability on the application level
- gpufs doesn't know the use case
@@ -36,8 +55,10 @@
- application must scale
- draw less
- smaller detail, ...
+ - distance culling, ...
- gamedev
- - but: non-gamedev tasks (simulation, science)?
+ - but: non-gamedev tasks (simulation, scientific tasks)?
+ - slower is sometimes fine
INSPIRED BY VULKAN
@@ -61,6 +82,19 @@
- 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
@@ -82,15 +116,15 @@
- future: only compute shader
pic:
-creating buffer and shader
-loading data
-
-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
@@ -100,22 +134,13 @@
confusing, refer to shader
-COMPILE
-
-- High level (edited)
-- Spir-V binary
-- Native
-- GPU
-
-SPIR-V binary is cross-platform:
-- not machine-specific
-- "description" of the program
-- cross compilers
-
EXAMPLE SHADER PROGRAM
+glsl, because SPIR-V too long and confusing
+
important:
-- layout lines
+- layout buffer (set 0, binding 1)
+- layout local_size_x -> workgroup size
- gl_GlobalInvocationID
layout buffer:
@@ -125,7 +150,7 @@
- workgroup size (will explain)
gl_GlobalInvocationID:
-- which invocation (which data to use)
+- which invocation (determine which data to use)
WORKGROUPS
@@ -139,17 +164,26 @@
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
-- stalled
+- paused because drawterm
Drawterm:
-- actual GPU
+- 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