Pandora Potential?

[Exophase]

I always wonder about this. Yea the dsp allows us to offload the video decoding, so may get better battery life.
But how big a deal is that if the cpu can do the decoding. May get slightly less battery life but may not be hugely less, do we have any ballpark figures?

So better cpu may give, same level of decoding as dsp or maybe even better....

If your watching something you probably wont need to be doing anything else on the cpu, so it's not like your missing out all that much not having a dsp.

Although the DSP is clocked lower it's a lot better at some applications than the CPU is. It's a very computationally wide device that can stream and operate on a lot of data per clock cycle. It also has much more deterministic timing with respect to things like branches, and has a non-interlocking structure which means that well-scheduled code can be very fast, while on the Cortex-A8 some branch mispredictions will be impossible to avoid and will cause over a dozen cycles stalling. Cortex-A8 has NEON which is also pretty wide (not as wide as the DSP), but is not nearly as flexible. On the other hand, NEON can do FPU operations which the DSP can't.

The best scenario is if both the CPU and DSP are employed. For almost any task that can be well balanced across multiple threads the DSP can be used to significantly improve performance. But I think that it won't be popular to program for the DSP because it'll require a separate toolchain and it looks like it's going to be pretty cumbersome getting code loaded on it then communicating between the two. It's also going to require Linux kernel support which as far as I'm aware isn't in the current Pandora kernels (but has been on Beagleboard ones for over a year). To really make good use of the DSP code is going to have to be at least tweaked for it, with at the worst extreme intrinsics and assembly language employed. C64x is quite a bit harder to write raw assembly for than most CPUs, because of the lack of interlocks and several variable length pipelines.

 

[juniorm33]

I always wonder about this. Yea the dsp allows us to offload the video decoding, so may get better battery life.
But how big a deal is that if the cpu can do the decoding. May get slightly less battery life but may not be hugely less, do we have any ballpark figures?

So better cpu may give, same level of decoding as dsp or maybe even better....

If your watching something you probably wont need to be doing anything else on the cpu, so it's not like your missing out all that much not having a dsp.

Although the DSP is clocked lower it's a lot better at some applications than the CPU is. It's a very computationally wide device that can stream and operate on a lot of data per clock cycle. It also has much more deterministic timing with respect to things like branches, and has a non-interlocking structure which means that well-scheduled code can be very fast, while on the Cortex-A8 some branch mispredictions will be impossible to avoid and will cause over a dozen cycles stalling. Cortex-A8 has NEON which is also pretty wide (not as wide as the DSP), but is not nearly as flexible. On the other hand, NEON can do FPU operations which the DSP can't.

The best scenario is if both the CPU and DSP are employed. For almost any task that can be well balanced across multiple threads the DSP can be used to significantly improve performance. But I think that it won't be popular to program for the DSP because it'll require a separate toolchain and it looks like it's going to be pretty cumbersome getting code loaded on it then communicating between the two. It's also going to require Linux kernel support which as far as I'm aware isn't in the current Pandora kernels (but has been on Beagleboard ones for over a year). To really make good use of the DSP code is going to have to be at least tweaked for it, with at the worst extreme intrinsics and assembly language employed. C64x is quite a bit harder to write raw assembly for than most CPUs, because of the lack of interlocks and several variable length pipelines.

Thanks nice post as usual.

Then it comes down to how much it will be used, due to ease of use. Which was my fear, as from a couple other posts it didn't seem very accessible/easy for whatever reason. Which you've explained to me here.
When that's the case sometimes just better of with more brute force.

 

[ldesnogu]

To really make good use of the DSP code is going to have to be at least tweaked for it, with at the worst extreme intrinsics and assembly language employed. C64x is quite a bit harder to write raw assembly for than most CPUs, because of the lack of interlocks and several variable length pipelines.

Writing raw assembly would certainly be a pain. You'd better use the "optimizing" assembler to write assembly, it will take care of scheduling and other painful things. Of course as usual, getting the most out of that beast requires raw assembly, but this should be considered as extreme and probably not needed in most cases

 

[Exophase]

Writing raw assembly would certainly be a pain. You'd better use the "optimizing" assembler to write assembly, it will take care of scheduling and other painful things. Of course as usual, getting the most out of that beast requires raw assembly, but this should be considered as extreme and probably not needed in most cases

Real programmers are not afraid of C64x+ assembly ;D C67x is even worse since it's floating point and higher latency (but on the other hand, you don't have like 10000 different types of multiplication instructions to deal with)

I haven't used the optimizing assembler before. I imagine you'd want to use it for most of your code then maybe have a few inner loops hand done, maybe modified from the optimizing assembler's stab at it.

 

[ldesnogu]

I was just trying to make it less frightening to others than you do