Our talk at DevCom 2018 was about running your game entirely on the GPU. To achieve this we implemented an Entity Component System (ECS) on the GPU.
This blog entry will sum up why we selected the OpenCL API for implementation.
Question: Which API to use for making the GPU the main processor and implementing and Entity Component system running on the GPU. We need as much freedom and generic access to the GPU as possible.
Requirements
- Fast (close to the hardware)
- Full disclosure of the GPU
- Freedom (minimal restriction on architecture design)
- Platform independent (OS & hardware)
- Support on consumer systems (Desktop in particular)
- Interoperability with Rendering
Candidates
- Compute shaders
- Cuda
- OpenCL
Analysis
Compute shaders
Pros
- Common solution
- Stable support
Cons
- Heavily impaired by graphics centric assumptions
- No pointer arithmetic
- Reduced precision (not an option for a persistent simulation)
- Additional (memory alignment/addressing and other) restrictions due to graphics central assumptions of the mother API
- Convoluted API (OpenGL)
- Shares state with rendering (driver)
- Conflicts (performance) with driver assumptions which may differ between vendors (or driver versions!)
- It makes no sense to use a 2 seater sportscar to move your furniture. Even though it looks nice and you already have experience driving one.
Cuda
Pros
- Fast (Close to the hardware)
- Stable and reliable (NVidia has been taking GPGPU serious for years)
- Mature tooling and libraries
Cons
- Hardware locked. (Only on NVidia hardware)
OpenCL
Pros
- Fast (Close to the hardware)
- Clean API
- Hardware and OS independent with support for many platforms
Cons
- Not very mainstream on consumer platforms (although drivers are supported through display driver installs)
Conclusion
We need an API that disregards the “G” in GPU.
Just generic, low level access to a very fast processor: OpenCL
Notes
- Why it is important to select the right API for the job?
If your use-cases differ too much from the mainstream API intend/use, you will inevetably encounter problems. Especially with assumptions driver builders make.
So use A graphics API for grapics and a compute API for computing, and you will be close enough the those assumptions. - Vulkan vs OpenCL interop
There has been some mention of this here and there, but no serious efforts have been made. For sure nothing that warrants a consumer product integration will be available any time soon. - Compute shaders with Vulkan
Vulkan may be lower level than OpenGL, it is still a graphics API. Compute-shaders are still a side-dish to the graphics main-course. - Interop Cuda vs OpenGL
Yes it exists. We didn’t investigate it in depth because the vendor-lock already dismissed Cuda for us.
