Hardware rendering options

[GWustenstein]

Hi There!

It's been about a couple decades since I've used milkdrop on a windows machine with a little better than mediocre graphics hardware. Today, I'm looking at putting together a small rendering server to draw from analog inputs. Ideally, I'd like the server to run a linux distro, but the question of hardware complement comes up. A pi5 would be nice from a portability and power perspective (run into a small projector for visual fills at events, etc), but the built-in gpu is pretty minimal. There's a few snapdragon SBCs out there, but you run into cases where the distro is on a vendor-supported (heh, right...) branch and it makes the rest of the OS and apps difficult to support. There's the x86 + GPU approach, but things get real big real quick and the whole portability aspect goes out the window. In 20yrs, a lot has happened to hardware in this area...

So, the question is, if I were to build a dedicated machine for this, given reasonable performance, portability, etc., what would you do today given your prior experience with the library and various hardware options available?

[kblaschke]

That's a tough question to answer, as it really depends on many factors.

The library itself doesn't have really huge requirements for the GPU - OpenGL ES 3.1 must be supported on embedded devices, that's basically it. The CPU architecture isn't overly relevant, projectM runs fine on x86, x86_64, arm and arm64 platforms, and probably even others as well as we intentionally don't use any intrinsics or CPU-specific assembly code.

The performance side is probably the more interesting one. This mainly depends on how many shading units the GPU has, and what the pixel fill rate is, as projectM/Milkdrop are mainly limited by shader performance. It's also kinda fuzzy, as the actual rendering performance hugely depends on how each preset is made. Some presets don't use shaders at all (while projectM will always use shaders, the default shaders are really simple) and run pretty fast, while there are other presets using hugely complex shaders which perform raycasting and fractal rendering, which will even stress a modern desktop GPU to its limits.

Some presets have complex geometry, using many custom shapes or waveform lines to render nice images. These are solely CPU-based, but should generally run okay.

So independent of your actual hardware choice, there are a few things you can do:

• Reduce the rendering resolution. This is the best way to improve shader performance.
• Manually select presets which have simple shaders and run at a decent framerate.
• Reduce the per-pixel mesh resolution to a lower value (e.g. 32x24) to save some CPU time.
• Limit the framerate to 30 FPS. Doesn't look as smooth as 60 FPS, but will cut the CPU and GPU usage in half.

I've tested projectM on a Pi 5 and it works pretty well and stable at mostly 60 FPS when run at 720p and using a per-pixel mesh size of 48x32. There are some slowdowns with complex presets and during transitions though, as blending effectively doubles the load as two presets need to be rendered at once, plus the additional transition shader. You can disable smooth blending if that's too annoying, but hard cuts don't look as nice.

Currently, the SDL2 frontend can only render at the native window resolution, but once libprojectM 4.2 is released, we'll support an upscaling setting in the application to render the visuals at a fixed max resolution and scale it to the actual display size, while keeping the aspect ratio in sync of course.