Game Engines 2021W Lecture 7

Resources

• Beagle Bros quick reference poster (with Apple II memory map)
• SGI IRIS GL (predecessor to OpenGL)
• Jurassic Park and SGI
• Vulkan tutorial introduction and overview
• Thinking machines, maker of the CM-1, CM-2, and CM-5

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