As a guy who has done nothing but audio coding my whole career I can agree that being able to move everything off of DSPs and on to the high performance main CPUs that came along is a great thing, at least for us writing audio code. Auxiliary processors can box you in and are generally just a PITA to deal with. They are also often closed off, only presenting some high level API to interact with.
It's nice to have someone from the industry give their insights.
I might be cautious in saying the PS4 has a "DSP". It is not targeted for general purpose audio processing, the main CPU is what does all that. The "DSP" mostly deals with encoding and decoding. Is that a DSP, or is it just another auxiliary processor that is cost effective at that task? There might be some other DSPs on the machine I am unaware of, there are a number of them that perform various tasks, but none that synthesize the game audio like some might think.
Yes, the lines are blurred between what is and isn't a DSP processor. FPGAs can be programmed to handle repetitive little data processing tasks or an FPGA DSP processor can be used but stripped of any functionality it doesn't need (before the development FPGA become a hard chip). Specialized and customized processors are very efficient and much easier to create today.
I'm also not sure if you'd say the Cell is super DSP-like. Its instruction set is quite general purpose, but designed for modern SIMD computing (lean and mean). Its memory architecture is not at all general purpose, and more DSP like, I guess. It's interesting, to say the least.
The SPEs are probably more like modern GPU shading units (which have also become more general purpose) while they are all data stream processors. I wonder if the Cell SPEs could have been supported with OpenCL and an OS library for OpenCL. Sometimes how the hardware is offered and supported makes all the difference. An FPGA can also be configured as parallel OpenCL units and an opencl.library could support available GPU shading units, FPGA parallel processing units and/or the main CPU/FPU/SIMD for parallel tasks.
Relating this back to the Amiga I wouldn't actually mind if someone came out with a new sound card for it that had a bitchin' DSP-like processor on it. Given the Amiga tops out at 68060 you kind of need it if you want to do lots of crazy stuff. Either that or some of these new accelerators that could move us way past 060 performance, that would be even better.
A DSP on a sound card still makes some sense as the CPU can vary and is far away across a shared bus introducing the possibilities of unacceptable latencies. Fast modern buses and large buffers probably help but most customers aren't going to tolerate a sound card which glitches and pauses.
Too bad A-Eon didn't realize there was an audio and DSP expert on their forum. The Prisma Megamix could have become a real sound card
.
Gunnar was playing with an SIMD unit for the Apollo 68k FPGA core. It is Altivec like but with some simple CISC 68k style addressing modes added and some memory alignment restrictions dropped which would make it much easier to use while remaining mostly compatible with Altivec at the instruction level. Integer support is fairly cheap to implement in an SIMD but floating point is expensive. My advise was to support the 68k FPU (like 68060 FPU but with a few enhancements) for compatibility and forget about trying to add an SIMD unit until there is room (and probably single precision FP support as well). As I have thought about it more recently though, I would like to explore adding 2x 16 bit operations in a 32 bit register to the 68k integer units. Encoding space is limited so I would leave out 4x 8 bit operations. RGBA type byte color component operations could still be done in 1 cycle with superscalar instruction interleaving and there was already support for a PERM instruction which could load bytes into registers in any byte order wanted. It would have been helpful to have someone with industry experience in audio processing as part of our group. Maybe Gunnar would have even listened to you but probably not. He creates these nice "teams" which work to pull in ideas and build a consensus and then he ignores the consensus and does everything his own way with little explanation. The technology is real though and 68060 performance is being surpassed in an affordable FPGA. Perhaps up to double the performance of the 68060 is possible in the next few years in an affordable FPGA but "way past 060 performance" would probably require an ASIC. An ASIC would probably be required to fit a good SIMD unit with single precision FP also.
