pouët.net

Afaik the recent intros from 0b5vr and Nusan have GPU synths, iirc shadertoy also supports generating audio from shader code by now.

In the context of intros, it's not about performance, but about code density: shader source code compresses very well, CPU machine code much less so.

Two words: clinkster precalc

aaaaaand it was actually Oidos in that intro, not Clinkster but hey, same deal regarding the precalc.

Audio is floating point samples with 44.1kHz sample rate. => 3 min of track contain 7938000 samples, which you could render on the GPU using a 2817x2817 texture target. I'd say that is the exact thing GPUs are made for - the only thing you need to keep in mind is that all filter based effects are always feedback effects and need a multipass setup to work properly while maintaining the parallelization benefits of the GPU.

My 5 cents: GPU synths = insane speed-up plus size coding advantage of being able to store shaders instead of binary with x87 instructions.

It's not completely straight-forward to implement tho. It has been done however.

On the subject of audio precalc, I wonder how those render-whole-song-for-each-instrument-separately precalcs actually compare to a full 4klang precalc - the reason that 4klang isn't so noticeable is that the intro can be started while the audio is still precalculating and I don't think that anyone who is using 4klang is ever waiting for it to finish first.

Anyway, similarly to what NR4 said, a simple synth with features basic enough to let the music easily be a pure function of time is embarrassingly parallel (filters can be done analytically for basic waveforms, or additive synthesis can be done with loops, atomics, or warp-reductions) and so would fit a GPU very easily. Filters and reverb can be implemented as convolutions anyway, and convolution is a very common use-case for a GPU. Though, procedurally generating an impulse response is another matter...

Sorry, but using my GPU for my calculations isn't as in, generally speaking, using an extra piece of hardware to accelerate/render my code? Isn't this hardware acceleration??? I believe that strictly speaking a software renderer is just that, code that renders graphics using the CPU chip set only (excluding the integrated GPU, as well).

I did it in my 2014 4k intro (Discovery). Admittedly, it's rather primitive (i was looking for a simple sound anyways), and the shader for it was done by hand, but it does have rudimentary low pass filtering (through a redundant, moving window convolution of samples). Interestingly, i also had to slice it into multiple draw calls (with viewport settings), because the driver would always panic out for the single call variation taking too long :)

Okay, never mind, people refer to compute shaders as 'software rendering on the gpu' (even though the GPU is still being used). An example of that can be found here.

Bru, using a computer is hardware acceleration...

if you have a specific task to efficiently offload to an external processor/processing unit then why not?

i think that's the all-encompassing simplest yet true answer to this question.

so: yes you can. try it if you want to learn something new, never wrong!

i'd involve my own projects in this conversation were it not that it was you who asked a question.

Obviously hw vs sw acceleration is a relic of the past dating back to 3dfx and fixed pipelines. Now it's all software rendering on dedicated hardware ;P

This was the first thing in the mind when I first learned about shaders, back then :)

I combined my old 3D engine with OpenGL fixed function pipeline back in previous millennnium. Just a quick hack. Already that time, I was eager to use just a part of the pipeline.

At least for me, it would be technically pointless endeavor. I just want to do it.
...
Back in the days (10 yr), a chief in tech had learned out that mobile gpu:s could be a sole platform for a software codec. So as asked, I implemented for example DCT8x8 in GLES2.

... as a vertex shader :)