Resources
Notes
Show & Tell
https://shalinlathigra.itch.io/paul-cop-mall-blart
https://github.com/ShalinLathigra/GlobalGameJam2021
Timing issues
https://github.com/godotengine/godot/issues/38981
GPUs and graphics
Where did it all start?
Early systems had memory-mapped graphics
- range of RAM that was mapped directly to the screen
- change bits in this memory, screen would update
- maybe have 2 ranges you could flip between
- update one while changing the other
(double buffering)
- this meant that the CPU was involved in all graphics operations
- all the math
Apple II's had this sort of architecture, but other 8-bit CPUs were more capable
Atari 400/800
- had display lists: commands to tell what would be on the screen
- had hardware sprites (player/missle graphics)
Other early systems were simpler
- old Mac's just had a "blitter" (fast memory copying)
2D accelerated graphics cards
- fixed functions: draw shapes, basic textures, text
- often had its own separate memory
3D graphics changed everything
- need to create a model that the graphics card "renders"
- 2D projection of 3D models
- started with fixed function, but then evolved to be more general purpose
This evolution in graphics has influenced graphics APIs
OpenGL
- open version of GL, which was developed by Silicon Graphics
- hello world in OpenGL is relatively short, 5-10 lines to set up then
you give your drawing commands
Newer APIs are not this way, e.g. Vulkan
- it takes A LOT of code to get anything working in Vulkan
WHY?!
With OpenGL, the driver manages the graphics card
- you give commands on what to do, the driver figures out how to do it
But with modern APIs like Vulkan, the application manages the card
- well, manages a virtualization of it, so it can be shared between apps
Big motivation is PARALLELISM
- can't make sequential tasks faster simply by running on parallel hardware
- instead, have to refactor to get benefit
- different organizations will be efficient depending on the task
- so, have to put in developer's hands
With OpenGL, you have a sequential execution model
- one thread/process talking to the GPU giving commands
With Vulkan, parallel execution model
- many threads talking to GPU at once, each giving their own commands
But this means the app has to manage GPU cores and memory directly
- driver just gives a basic abstraction for managing resources
In other words, your app has to contain a GPU OS
This is why you want to use a game engine to develop your games!
- let it deal with the GPU for you
Godot currently supports OpenGL in 3.x, but 4.x supports Vulkan
- you can run it now, it just isn't stable or optimized
Weird thing is GPUs got so powerful that people wanted to start running arbitrary code on them
- GPGPU
- i.e., do AI/ML or crypto mining on GPUs
GPUs offer general functionality
- but also have lots of graphics-specific bits
I think eventually GPUs will just become parallel computation systems, and
graphics part will be separated out
- would allow for cleaner architectures
- and more load sharing with CPU