This document discusses building OpenGL on ARM devices without a GPU. It proposes using an STM32 microcontroller and linear algebra library to perform 3D graphics operations via the CPU. Key steps include using meshes to define 3D objects as triangles, applying model-view-projection matrices to transform vertices, and implementing a depth buffer in SDRAM to solve visibility since the CPU lacks hardware acceleration. Benchmarks show a maximum frame rate of 139.82 FPS when clearing only the framebuffer between draws. The goal is to port OpenGL's syntax to run basic 3D graphics without a GPU.

1. How to build your own OpenGL on ARM devices
without GPU
Danylo Ulianych
RingLabs

2. STM32 are not designed for 3D graphics
3D games Orientation,
navigation
Motion capture

3. Why OpenGL? Analogs.
https://github.com/fabio914/arduinogl
Pros:
★ OpenGL syntax
gluLookAt(10, 8, -10, 0, 0, 0, 0, 1, 0);
★ Ported on Arduino (!)
Cons:
Not able to fill polygons (it draws only edges)
No depth buffer (rear objects should not be
drawn)
No color buffer ⇒ no color gradient

4. Why OpenGL? Analogs.
https://github.com/floppes/stm32doom
The basic rendering concept -- horizontal and
vertical lines of constant Z. Binary Space
Partitioning (BSP) constructs a balanced tree of
polygons per vertical column to draw a wall.
Pros:
★ Real-time performance on STM32 Disco
★ IO layer, responsible for handling user
events, is built into graphics engine ⇒
low latency
Cons:
Only 2 degrees of freedom: camera
cannot look up and down
You have to be John Carmack (the
creator of Doom engine) to understand it

5. Why OpenGL? Motivation.
OpenGL is meant to be cross-platform API. But it requires
GPU. I didn’t find OpenGL v1.0+ sources for running on
CPU only - without GPU, platform specific window context.

6. 3D graphics is not 2D graphics!
2D graphics works with widgets.
It’s much simpler than 3D
graphics, because:
● Most LCD manufacturers
(even low-cost LCD)
provide rules for fast
drawing of horizontal and
vertical lines, rectangles -
instead of pixel by pixel.
● Redraw only when a new
event is occurred.

7. 3D graphics is not 2D graphics!
Complexity (lower bound):
● time: width x height x (objects in the scene)
● space: width x height
Crysis uses ~ 3 millions polygons per frame

8. Our plan
1. Choose a programming board.
2. Choose software tools (linear algebra, HAL).
3. Mesh.
4. Model, view and projection matrices.
5. Visibility problem. Depth buffer.
6. Plugging it all together.
7. Benchmarks.

9. What you’re gonna need. Hardware.
STM32
Discovery

10. What you’re gonna need. Software.
Hardware abstraction layer to
“speak” with peripherals
(optional) Board support package to draw
on LCD
Linear algebra library (affine
transformations) ← ???

11. Linear algebra library
https://github.com/datenwolf/linmath.h
246 stars, under “DO WHAT THE F**K YOU WANT TO PUBLIC LICENSE”

12. Linear algebra library
https://github.com/datenwolf/linmath.h
246 stars, under “DO WHAT THE F**K YOU WANT TO PUBLIC LICENSE”

13. Our plan
✓ Choose a programming board.
✓ Choose software tools (linear algebra, HAL).
➢ Mesh.
● Model, view and projection matrices.
● Visibility problem. Depth buffer.
● Plugging it all together.
● Benchmarks.

14. Mesh Each 3D object can be
decomposed into a series
of polygons (triangles),
called mesh. To construct
a mesh, you need to
specify position and color
for each vertex in a mesh.
Then any intermediate
point inside a triangle
can be interpolated as the
average of its vertices
colors.

15. Affine matrix representation
Rotate by
degrees around
vertical Z-axis
Here is where
we’re gonna
use our linear
algebra library
a lot!

16. ModelView matrix
● Model matrix defines
position and orientation
of the duck
● View matrix defines
position and orientation
of the camera
If we place the camera into
the origin of our coordinate
system, then
View == I4x4
ModelView == Model
ModelView4x4
≝ View4x4
✕ Model4x4

17. Projection matrix
“Eye” and “camera”
are used
interchangeably - it
defines the point of
view or how we will
see a 3D scene.

18. Total MVP matrix
MVP4x4
≝ Projection4x4
✕ View4x4
✕ Model4x4
MVP defines what you see on your smartphone screen.
It squashes 3D space into 2D screen.

19. Our plan
✓ Choose a programming board.
✓ Choose software tools (linear algebra, HAL).
✓ Mesh.
✓ Model, view and projection matrices.
➢ Visibility problem. Depth buffer.
● Plugging it all together.
● Benchmarks.

20. Visibility problem. Depth Buffer.
We need to store the current depth and
color values for each pixel on the
screen.
For LCD 320ｘ240 it’s
320ｘ240ｘ8 (4 bytes for depth float and
4 bytes for RGB8888) == 614 Kb > 256
Kb (internal RAM), thus we need
SDRAM.

21. Direct memory access (DMA) trick

22. Direct memory access (DMA) trick

23. Plugging it all together
SDRAM

24. Plugging it all together

26. Benchmark
Benchmark is measured by FPS (frames per
second) on the scene with 3 cubes with
asserts turned off.
Optimization
flag
-O0 -Os -O1 -O2 -O3 -O3 FrameBuffer clearing
only (both depth and color)
[upper bound for FPS]
FPS 1.25 5.38 6.10 7.81 8.48 139.82

27. So close!
Reality…
https://github.com/dizcza/cOpenGLWhat you imagine...