- Joined
- Dec 8, 2005
- Messages
- 6,603
- Age
- 40
- Location
- UK
- Website
- pokeparadox.itch.io
- WEBSITE
- https://github.com/pokeparadox
- YOUTUBE
- pokeparadox
Awww you're no fun - I might do it anyway! XD
[announce] c64_tools (DSP loader and IPC)
- Thread starter bsp
- Start date
sebt3
homebrew player (P. & C.)
Audacious play music without a problem at 125Mhz on the pandora already (with filters off) I dont think that can be beaten. you'll need the CPU to control the DSP anyway, so mp3 playing isn't a good target for that chip.
DSP might be usefull to offload the CPU when it's completly overloaded. It might make a point to push the audio engine in nxengine to the DSP as the CPU is already at 100% (I'm realy cheating with the scheduler to make it playable). and think like that. Exo suggested that the GPU could be offloaded to the DSP in drastic (though I doubt he will do so as not all the android device have a DSP, far from that).
Magic Sam
Forever Homebrew
ptitSeb
Serial Porter
I see 3 useage, in my point of view, and with increasing difficulty of implementation, for the DSP:
1. Code an audio Plugin for mupen64plus v2. The audio is not a big workload, but if it can be offloaded from main CPU, it will certainly be good. Also, the modular side of mupen64 make it a good canditate to have a DSP Plugin to test, while maintaining compatibility with "not DSP-able system".
2. Export the PPSSPP sound codeto DSP. It's a bit more complicated, and it should be done without Atrac+ at first, and than with it on a second time.
3. Port most of the sound transformation of OPenAL-Soft to DSP. OPneAL can be quite CPU intensive in some game (take JK2 ou 3, and test with OpenAL or without to see what I mean). This is clearly more complicated to port, but the benefit can be very important, OpenAL can consume more than 10%~15% of CPU on some scene (quick "TOP" unrelialble benchmark).
1. Code an audio Plugin for mupen64plus v2. The audio is not a big workload, but if it can be offloaded from main CPU, it will certainly be good. Also, the modular side of mupen64 make it a good canditate to have a DSP Plugin to test, while maintaining compatibility with "not DSP-able system".
2. Export the PPSSPP sound codeto DSP. It's a bit more complicated, and it should be done without Atrac+ at first, and than with it on a second time.
3. Port most of the sound transformation of OPenAL-Soft to DSP. OPneAL can be quite CPU intensive in some game (take JK2 ou 3, and test with OpenAL or without to see what I mean). This is clearly more complicated to port, but the benefit can be very important, OpenAL can consume more than 10%~15% of CPU on some scene (quick "TOP" unrelialble benchmark).
Linux-SWAT
Forum Addict!
- Joined
- Feb 13, 2010
- Messages
- 9,188
Cannonball isn't a good candidate to experiment ? I mean you know it well and it's borderline, CPU greed speaking .
Last edited by a moderator:
bsp
Very Active Member
- Joined
- Dec 2, 2006
- Messages
- 314
@Linux-SWAT: I'm from germany (so pls excuse my funny english 
)
@Exophase: Sure it's still not fast enough for emulating single FPU instructions but it's now fast enough for the DSP to be usable for e.g. transforming a view vertices (instead of ten-thousands). I also did not say I did "scientific testing" in regards to power consumption. I was merely stating, from a user point of view, that having the DSP running in the background (doing nothing except waiting for RPC requests) did not have a noticable impact on battery life. Besides, when the "c64.ko" kernel module is unloaded, it shuts off the entire IVA2 (DSP) subsystem. A system service could probably handle that (in case it's worth the effort) (during my tests the module was loaded all the time, of course).
@notaz: Thanks, I'll take a look at the new kernel and your test module! Would be great if we could get rid of the mandatory 4 MB memory gap. Heh, and regarding your demo suggestion/request: I was indeed planning to write a small demo/effect that showcases a ) the additional processing power gained by using the DSP and b ) the tightly coupled interaction between ARM and C64 that's possible with the c64_tools. You do not have to send me a base app, I was planning on learning the specifics of your optimized Pandora SDL, anyway. Learning-by-doing is usually the best way to do so. Thank's for the offer, anyway!
@milkshake: "So what is the best use scenario for our dsp?" -> In general, high-performance applications like
- emulators (in case they do not already run fast enough on ARM-only (w/o overclocking and on 600 Mhz Pandoras). this heavily depends on the emulator design and the hardware being emulated, though). also what sebt3 said.
- games (depending on the game. if the game is RAM bandwidth-limited, using the DSP will not have an advantage. if, on the other hand, the game uses e.g. a lot of math/physics calculations, the performance can be increased considerably)
- any kind of application/algorithm that can be parallelized effectively (for example, I have a music application in the works where offloading synth and FX processing to the DSP would improve the overall performance). just be creative here.
@_wb_: I cannot say whether the DSP will be faster at JPEG decoding than the ARM. I think TI has some optimized code/libs available for that, you would have to check them out. Although, this type of application sounds like the bottleneck might be the SD access ?!
Generally speaking, the C64 DSP is not some magical thing that will automatically make everything go faster. It shares the RAM with the ARM although TI has put a single-cycle access (i.e. very fast) SRAM into the DSP that can be shared with the ARM. If developers put frequently accessed (shared) data structures in there, there is no need for explicit cache writeback/invalidate calls. The drawback is that it is "just" 48 KBytes. Personally I do think that this is plenty. (there's another 256 KBytes SRAM area (the L2 cache) that I have not tested, yet. It's not single-cycle, though, from what I read).
@Crionic: IMHO, there are several reasons why the DSP has not been used (at all or to its full capabilities):
1) With DspLink/DspBridge, getting into DSP coding is harder than it needs to be. You have to spend a considerable amount of time setting up the dev environment, compiling the libs/modules.
2) On some of the previous pages I mentioned that there seems to be a hardware issue with the Pandora (at least the one I have) that prevents DspLink/Bridge from working in the first place.
3) Developing for it on the Pandora is a lot more difficult than writing ARM-side code because the only way to debug it is to examine a few debug memory locations (a printf() could be added, though)
4) The DSP internals are quite different from the ARM. To get the best out of it, you have to spend time in order to learn about that. However, as I've already said, the DSP "C" compiler is quite good and even if you ignore the DSP specifics, you can get quite a lot of out of it. If you are interested in C64 development, you should check out the (highly-optimized) libraries TI has already available. For example, if, for some reason, you need floating point math, check out TI's "iqmath" library (this DSP does not have an FPU so fixed point math is usually your friend)
5) Developers are lazy (take this with a grain of salt, this includes me, too): Using the DSP means parallelizing your algorithms. This is also more difficult than just using one CPU. This is not a Pandora/DSP specific problem, e.g. on PCs there are many applications that could benefit from multithreading, yet they still use only one core, even if the machine has 8 of them.
)@Exophase: Sure it's still not fast enough for emulating single FPU instructions but it's now fast enough for the DSP to be usable for e.g. transforming a view vertices (instead of ten-thousands). I also did not say I did "scientific testing" in regards to power consumption. I was merely stating, from a user point of view, that having the DSP running in the background (doing nothing except waiting for RPC requests) did not have a noticable impact on battery life. Besides, when the "c64.ko" kernel module is unloaded, it shuts off the entire IVA2 (DSP) subsystem. A system service could probably handle that (in case it's worth the effort) (during my tests the module was loaded all the time, of course).
@notaz: Thanks, I'll take a look at the new kernel and your test module! Would be great if we could get rid of the mandatory 4 MB memory gap. Heh, and regarding your demo suggestion/request: I was indeed planning to write a small demo/effect that showcases a ) the additional processing power gained by using the DSP and b ) the tightly coupled interaction between ARM and C64 that's possible with the c64_tools. You do not have to send me a base app, I was planning on learning the specifics of your optimized Pandora SDL, anyway. Learning-by-doing is usually the best way to do so. Thank's for the offer, anyway!
@milkshake: "So what is the best use scenario for our dsp?" -> In general, high-performance applications like
- emulators (in case they do not already run fast enough on ARM-only (w/o overclocking and on 600 Mhz Pandoras). this heavily depends on the emulator design and the hardware being emulated, though). also what sebt3 said.
- games (depending on the game. if the game is RAM bandwidth-limited, using the DSP will not have an advantage. if, on the other hand, the game uses e.g. a lot of math/physics calculations, the performance can be increased considerably)
- any kind of application/algorithm that can be parallelized effectively (for example, I have a music application in the works where offloading synth and FX processing to the DSP would improve the overall performance). just be creative here.
@_wb_: I cannot say whether the DSP will be faster at JPEG decoding than the ARM. I think TI has some optimized code/libs available for that, you would have to check them out. Although, this type of application sounds like the bottleneck might be the SD access ?!
Generally speaking, the C64 DSP is not some magical thing that will automatically make everything go faster. It shares the RAM with the ARM although TI has put a single-cycle access (i.e. very fast) SRAM into the DSP that can be shared with the ARM. If developers put frequently accessed (shared) data structures in there, there is no need for explicit cache writeback/invalidate calls. The drawback is that it is "just" 48 KBytes. Personally I do think that this is plenty. (there's another 256 KBytes SRAM area (the L2 cache) that I have not tested, yet. It's not single-cycle, though, from what I read).
@Crionic: IMHO, there are several reasons why the DSP has not been used (at all or to its full capabilities):
1) With DspLink/DspBridge, getting into DSP coding is harder than it needs to be. You have to spend a considerable amount of time setting up the dev environment, compiling the libs/modules.
2) On some of the previous pages I mentioned that there seems to be a hardware issue with the Pandora (at least the one I have) that prevents DspLink/Bridge from working in the first place.
3) Developing for it on the Pandora is a lot more difficult than writing ARM-side code because the only way to debug it is to examine a few debug memory locations (a printf() could be added, though)
4) The DSP internals are quite different from the ARM. To get the best out of it, you have to spend time in order to learn about that. However, as I've already said, the DSP "C" compiler is quite good and even if you ignore the DSP specifics, you can get quite a lot of out of it. If you are interested in C64 development, you should check out the (highly-optimized) libraries TI has already available. For example, if, for some reason, you need floating point math, check out TI's "iqmath" library (this DSP does not have an FPU so fixed point math is usually your friend)
5) Developers are lazy (take this with a grain of salt, this includes me, too): Using the DSP means parallelizing your algorithms. This is also more difficult than just using one CPU. This is not a Pandora/DSP specific problem, e.g. on PCs there are many applications that could benefit from multithreading, yet they still use only one core, even if the machine has 8 of them.
Last edited by a moderator:
ptitSeb
Serial Porter
Yes, I know it well and it's cpu intensive, but the logic as to be change for the DSP to work. It's a second processor, so I will have to add some "multithreading" logic for the DSP to be feeled positively. But sure, some graphic processing (all the sprite engine) is probably a good candidate, but some threading/sync has to be added also.
On the other hand, mupen64plus (which I'm beggining to know now), is probably an easier candidate (with a less spectacular improvement probably).
That's too true
. I tried to get into dsp development some time ago. But all the trouble to get the environment working (download tons of packages from TI, recompiling tools and libs (not to mention I hate it, to register with my real name to download something)) wasn't finally worth the effort for me. Nvidia did this in a much better way (regarding cuda).
Last edited by a moderator:
Linux-SWAT
Forum Addict!
- Joined
- Feb 13, 2010
- Messages
- 9,188
@ptitSeb, yeah anyway N64 emu isn't making any progress since a long time so i'm sure plenty of ppl will be happy with some new stuff ^^.
rohezal
Advanced Member
- Joined
- Oct 18, 2009
- Messages
- 1,712
sorry for the offtopic question but how much cpu time % is used in sound processing in mupen? 5%, 10%?
do you think 16 floating point operations are enough to be worth to be done by the dsp? vert4 * mat4 is the most common gpu command done on the cpu, getting it faster would be great. if lunixbochs can load custom libs he offload the matrix mul to the gpu. maybe even some black magic can be used to find in the binary stuff like this:
const int maxVertices = 4096;
struct Vertex Vertices[maxVertices];
void transformVertices(int numberOfVertices, struct Matrix worldViewMatrix)
{
int i;
for(i =0; i < numberOfVertices; i++)
{
Vertices = matrixMultiply(Vertices , worldViewMatrix);
}
}
and catch the function call of transformVertices(). Then use some other code path to save matrixMultiply arguments and execute a few hundreds of them in paralell.
do you think 16 floating point operations are enough to be worth to be done by the dsp? vert4 * mat4 is the most common gpu command done on the cpu, getting it faster would be great. if lunixbochs can load custom libs he offload the matrix mul to the gpu. maybe even some black magic can be used to find in the binary stuff like this:
const int maxVertices = 4096;
struct Vertex Vertices[maxVertices];
void transformVertices(int numberOfVertices, struct Matrix worldViewMatrix)
{
int i;
for(i =0; i < numberOfVertices; i++)
{
Vertices = matrixMultiply(Vertices , worldViewMatrix);
}
}
and catch the function call of transformVertices(). Then use some other code path to save matrixMultiply arguments and execute a few hundreds of them in paralell.
Last edited by a moderator:
You should wait for a video within the next few days from me, before saying that.
Internal beta testing has shown A LOT of progress during the last weeks with N64.
I'm playing Super Mario 64 with HiRes texture packs, for example
Linux-SWAT
Forum Addict!
- Joined
- Feb 13, 2010
- Messages
- 9,188
Huh !?! Askarus is gonna have a stroke !
Exophase
Nothing good will ever come of Exophase.
I keep trying to tell you, the CPU has a vector FPU, the DSP has no floating point at all - you do NOT want to offload floating point operations to it!
bsp is also trying to point out, the DSP is for parallel programming - generally it's useful when it can do work while the main CPU can also do work at the same time. While it can at least take the messaging overhead of doing hundreds of thousands of roundtrip operations per second that means the CPU sitting there and waiting for them to complete - you probably aren't going to be getting any real work done on the CPU at the same time. There are some cases where the DSP may be faster than the CPU at a task, in which case it could be worth using it even if the CPU is busy waiting for it to complete, but these cases aren't that common vs using NEON on the CPU.
bsp
Very Active Member
- Joined
- Dec 2, 2006
- Messages
- 314
@notaz: Just tried your new kernel and your test module -- works fine! good job! I'll now update the c64_tools to make use of this new feature.
EDIT: I have not taken a look at the new kernel sources, yet but is my assumption correct that you check whether the allocation size is 4mbytes and in that case return the DSP image area ?
EDIT: I have not taken a look at the new kernel sources, yet but is my assumption correct that you check whether the allocation size is 4mbytes and in that case return the DSP image area ?
Last edited by a moderator:
Linux-SWAT
Forum Addict!
- Joined
- Feb 13, 2010
- Messages
- 9,188
You have 10mn.
milkshake
Advanced Member
well I certainly cant wait! does this beta version take any of the improvements paul did when he made the ooya version?You should wait for a video within the next few days from me, before saying that.
Internal beta testing has shown A LOT of progress during the last weeks with N64.
I'm playing Super Mario 64 with HiRes texture packs, for example
rohezal
Advanced Member
- Joined
- Oct 18, 2009
- Messages
- 1,712
exophase:
Thank you for your explanation.I hope I don't waste your or other peoples time here. As far as I understood is it not possible using qemu to convert x86 floating point operations into in arm floating point operations, let alone neon code. qemu uses some wierd integer code over 300 lines to ensure bit accuared floating point operations.
my question was to use the qemu code, load it into the dsp and catch some matrix * vertex operations (if this is possible), and let the dsp do the integer operations needed to perform the x86 floating point operation. the main cpu can do other during this time if possible (like audio procssing).
Thank you for your explanation.I hope I don't waste your or other peoples time here. As far as I understood is it not possible using qemu to convert x86 floating point operations into in arm floating point operations, let alone neon code. qemu uses some wierd integer code over 300 lines to ensure bit accuared floating point operations.
my question was to use the qemu code, load it into the dsp and catch some matrix * vertex operations (if this is possible), and let the dsp do the integer operations needed to perform the x86 floating point operation. the main cpu can do other during this time if possible (like audio procssing).
notaz
Certified Guru
Unfortunately emulators are quite difficult to parallelize, unless you want to sacrifice compatibility. There are some specific cases where it can be done, like display lists in DS and PSX, but we currently have NEON code for that which might be hard to beat for DSP.
At least on mupen64plus v1 audio plugin was only responsible for sending audio to hardware and nothing else, has that changed in v2?
notaz
Certified Guru
It can't, because it's all done by the emulated program, and you can't parallelize it if it's not parallel to begin with.
WizardStan
Mega GP Mania
- Joined
- May 24, 2008
- Messages
- 16,731
I've actually wanted to try to learn DSP for a while, my stumbling block is that there didn't seem to be any simple interface that made sense to me. Everything I've read about DSPLink and Bridge assumed that you already had some idea of what you were doing. I want a library and tutorial that assumes the user is an idiot.
