shithub: gpufswip

Download patch

ref: a0260e238add3ca2bd1e37f31bdad3df9ee4296e
parent: d71350aeb45126043b62c70974d069389c05be03
author: sirjofri <sirjofri@sirjofri.de>
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