Triangles Made With Manual Mathematics
The Raspberry Pi Pico 2 is capable of 3D graphics if you’re willing to write the software routines for them. However, I didn’t want to spend the time to get started, so instead, I decided to stitch together existing libraries and port it to the system. Along came Raylib 6.0, and with its new software rendering backend RLSW, I was able to rip it apart and hack it together into a working 3D renderer for this tiny chip.
Taken from https://gamefromscratch.com/raylib-new-software-renderer
An ESP32 Alternative
In comparison to the ESP32 we have a bit of a slowdown, but not outside the realm of usability, to a point. Whilst the ESP32-S3 can’t overclock very well, it has 128-bit Vector SIMD, which lets it process multiple floating point numbers much faster than the Pico 2, but the Pico 2 can make up for it with its big overclocking potential, able to match the clock of the ESP32-S3 but get double the instructions per clock.
Taken from ESP32 vs. Pico 2: Comparing ESP32 with Raspberry Pi’s RP2350
Below is a performance benchmark. The M33 is the Pico 2, and Xtensa LX6 is the ESP32.
Taken from Benchmarking Raspberry Pi Pico 2 – iCircuit
Maximum Performance Methods (For Technical Folk!)
In order to become inline with the ESP32 version of the Raylib ports, I decided to make a standard on how to flip frames. We flip frames so that the previous frame can have its data DMA-ed over the video transmission bus of the developer’s choice and use case whilst Raylib draws to the other buffer. This completely removed the transmission stage as overhead to drawing, allowing Raylib’s frame time to be purely how long it takes to draw what it’s told to.
As mentioned previously, Xtensa LX6 has 128-bit SIMD, but half the instructions per second of an overclocked RP2350. As it turns out, Raylib’s RLSW pixel drawing routines run at about the same speed on the Pi Pico 2 even when overclocked due to the missing 128-bit SIMD optimizations GCC can vectorize, but the branch optimization and instruction cache hits on pixel drawing itself is still fully utilizing that core clock flexibility. Bunnymark gets around 250 bunnies before reaching 5fps on both chips!
However, if PSRAM is being used, such as for 3D drawing; since vertex data takes a lot of memory on the 3D Maze example, the speed drops by another half, since the PSRAM bus on the Pico 2 is 4-bit wide instead of 8-bit on the ESP32-S3. In total, the Pi Pico 2 is not as capable as ESP32-S3, but it is still much better than the Pi Pico 1 ever could hope to achieve, and 12 fps in first person maze at 320×240 isn’t all that bad for an embedded chip without wide SIMD.
Here’s the pull request in question: [rlsw] First batch of embedded optimizations and compiler requirements Pico 2 by NighthowlerStudios · Pull Request #5994 · raysan5/raylib
See It In Action
The Recommended Kit
If you’d like to try out this library yourself and get started on some very very tiny-power 3D graphics, I recommend the following kits, with some links to their store pages for your convenience. Everything else is in software.
Leave a Reply