The future of DSP?

I'm by no means a digital illiterate, but can somebody please translate into normal speak? Because all I get out of this is old chips bad, new chips better.
 
It sounds like this could tackle some problems, but not all of them. What about heavy causal algorithms?
Having multiple cores works for things that can be run independently, for example "simple" cryptographic functions such as mining or password cracking.

I suppose there are things that need to go through a "flow" or steps, in order. In those cases 1 core or 1000 does not make a difference.

Divide and conquer does not work for all problems, but can surely help in a fairly big amount of them :)
 
I'll save you all the long GPU architecture lecture and quickly summarize as follows:

GPUs are fundamentally predicated on long latency processing, because it allows them to spread that latency over a lot of different computations and hide the overheads of things like memory speed completely inside that latency. The article hand waves "techniques" to deal with latency as if that somehow fixes the problem. It does not, and the main technique for dealing with latency is slicing computations to submit more work to the GPU.

I mean it's cool in a general sense to have GPU DSP stuff and it's probably capable of a whole lot. But if you're thinking that it's going to be at all relevant to the kind of real time processing that powers an Axe Fx, prepare to be massively disappointed.

[EDIT] I thought an addendum would be appropriate - real world GPU latency is on the order of 20 ms, give or take. You could probably get that down to 10 with a system and busses designed to support low latency processing.

It sounds like this could tackle some problems, but not all of them. What about heavy causal algorithms?
Having multiple cores works for things that can be run independently, for example "simple" cryptographic functions such as mining or password cracking.
GPUs have, of course, massively changed the economics of passwords and the algorithms involved in hashing and decrypting them. And last year's insane GPU price bubble was driven by the rising price of Ethereum, which is a very GPU friendly cryptocoin.
 
Joel de Guzmann doesn't know wtf he is talking about. GPUs get all those FLOPS from being massively parallel. Parallelism is exactly what you DON'T want when processing audio. It's the assembly-line problem. You can't put the laces in the shoe until the shoe is fully assembled.
 
Joel de Guzmann doesn't know wtf he is talking about. GPUs get all those FLOPS from being massively parallel. Parallelism is exactly what you DON'T want when processing audio. It's the assembly-line problem. You can't put the laces in the shoe until the shoe is fully assembled.
Yes but he may be right when he says "there is no inherent limitation for it not to be assimilated by the CPU" ...
 
In our business we actually want fewer, faster cores. I'd much rather have one core running at 10 GHz than 100 cores running at 100 MHz.

Many slower cores increases latency proportionally to the number of cores. For example say our audio processing requires 10 tasks and each task requires 100 MFLOPs. If our processor has one core with 1 GFLOPs of performance then the processing latency is equal to the size of our audio frame, say 32 samples. If we have 10 cores with 100 MFLOPs of performance we can then spread the tasks out as one task per core. However each core is processing the PREVIOUS frame of audio from the previous task. So the latency is 10 times as great (320 samples). This is unacceptable for real-time audio.

Then you get the problem of how to apportion tasks among the cores. Some tasks require more FLOPs than others.

Parallelism is great for video and other applications where latency isn't an issue but for real-time audio, uh, no.
 
My background is in high performance trading software,we run significant processor farms (6500+ cores plus same again for backup)

GPUs have been touted for years for this use too, we have lots of parallelism and they’ve still not taken off at all.

I agree it’s a load of BS, you introduce more problems than you solve
 
In our business we actually want fewer, faster cores. I'd much rather have one core running at 10 GHz than 100 cores running at 100 MHz.

Many slower cores increases latency proportionally to the number of cores. For example say our audio processing requires 10 tasks and each task requires 100 MFLOPs. If our processor has one core with 1 GFLOPs of performance then the processing latency is equal to the size of our audio frame, say 32 samples. If we have 10 cores with 100 MFLOPs of performance we can then spread the tasks out as one task per core. However each core is processing the PREVIOUS frame of audio from the previous task. So the latency is 10 times as great (320 samples). This is unacceptable for real-time audio.

Then you get the problem of how to apportion tasks among the cores. Some tasks require more FLOPs than others.

Parallelism is great for video and other applications where latency isn't an issue but for real-time audio, uh, no.
I’m gonna go out on a limb and say you know what you’re talking about. ;)

I approve of this message.
 
Back
Top Bottom