Tms320c64x


Hmm, DSP stuff == cool. I might hook up a camera and do some image recognition with it. Those convolutions will be fast methinks.
 
atomicthumbs said:
Perhaps filters like HQ2X in emulators could be offloaded to the DSP?

Certainly, since that DSP can encode and decode H264 :)
Now it remains to be seen how efficient is the communication with the ARM and what the DSP bandwidth is.
 
Last edited by a moderator:
Laurent said:
Certainly, since that DSP can encode and decode H264 :)
Now it remains to be seen how efficient the communication with the ARM and what the DSP bandwidth is is.
This is the question!

:)

Both processors are the same, DSP have extra functionality instructions for decode audio and video if you want to be optimization with assembler. For other things like to help to process anything of a Cortex processor the question here is "the communication with the ARM and what the DSP bandwidth is." (Laurent)

I think here will be the performance in our engines. Why?

An Engine haves too many libraries, Core, Math, Sound, Effects, Objects, Scripts... etc. and Game library. After that, Viewer of the game. QT, GLUT... or native window system like X11.

If you have in your game flow good performance you will need, Effects (OpenGL), Objects, Script and Game library running in a Cortex thread.

Why Scripts? If you have Scripts process in DSP thread the scripts input executing at real-time (example: Monster A attack to PJ B -> [Script Event] onAttack ()) if this communication about DSP and Cortex is too low you will be some problems here.

So, I think we will to process audio library thread with OpenAL in DSP processor. Pandora haves 128 MB of memory and if you want many sound we will need to streaming and / or decompressing OGG files. This in DSP processor is so easy, and the communication with Cortex processor is not a problem, only playSound, playSound... stopSound... some times.

But... what happened if we want to help to Cortex process? We have for example RND (Random Number Generator) and other hardware implementation helping us. In which case we will want to help Cortex processor? mmm...

Easy, asynchronous process like weather changes or sub-process.

Sub-process: update geometry culling. Calculate LOD of players with distance information. All GUI process? Is not too important if you want to see your inventory and the GUI widget appear in 0.5 seconds.

No critical processing is the DSP tasks like this I think. Obviously play videos or cut scenes saved with engine between area transitions.
 
Last edited by a moderator:
I see a fair discussion about the DSP in this topic :D. It is a very interesting beast, no doubt about that.

It would be really nice to get a non-commercial C64x compiler sorted in time for the wide Pandora release that's for sure.

Anyway, on the subject of the DSP. The Linux DSPBRIDGE driver for the OMAP3 was released by TI a few days ago. For those that maybe interested here is the announcement from Hari Kanigeri to the main OMAP Linux mailing list.

Hari Kanigeri said:
We are pleased to announce the availability of DSP bridge driver for
OMAP3 platform. DSP Bridge driver provides features to control and communicate with DSP enabling parallel processing for multimedia acceleration. It enables the applications running on MCU to offload the processing to DSP.

Some of the key features of DSP Bridge are listed below.

- Messaging: Ability to exchange fixed size control messages with DSP.
- Dynamic memory management: Ability to dynamically map files to DSP address space.
- Dynamic loading: Ability to dynamically load new nodes on DSP at run time.
- Power Management: Static and dynamic power management for DSP.

The information on the following is available at http://www.openomap.org/pub/dspbridge/

- Driver source
- Documentation
- User side library for user side application is available at:
- Sample applications demonstrating the API usage are available at:

The proposed location for the driver in the kernel tree is drivers/dsp/dspbridge.

Thank you,
Best regards,
Hari Kanigeri
Texas Instruments
 
Last edited by a moderator:
DJWillis said:
It would be really nice to get a non-commercial C64x compiler sorted in time for the wide Pandora release that's for sure.

Well I gave a link above to version 5.0 of CGT running on Linux with no license checking :)
I'm quite surprised TI left that on their FTP site, and I was hoping Jason would comment but he did not.

Anyway I am thinking about writing a basic low-level toolchain (assembler and cycle accurate simulator) with no restriction on its use.
 
Last edited by a moderator:
Laurent said:
DJWillis said:
It would be really nice to get a non-commercial C64x compiler sorted in time for the wide Pandora release that's for sure.

Well I gave a link above to version 5.0 of CGT running on Linux with no license checking :)
I'm quite surprised TI left that on their FTP site, and I was hoping Jason would comment but he did not.

Anyway I am thinking about writing a basic low-level toolchain (assembler and cycle accurate simulator) with no restriction on its use.
I did notice that, I would still rather push TI for a non-commercial proper release anyway :D. Better to start without pissing TI off that much regardless of why it is there in the 1st place.

Doing an open assembler and simulator would be great no doubt about that.
 
Last edited by a moderator:
Laurent said:
Anyway I am thinking about writing a basic low-level toolchain (assembler and cycle accurate simulator) with no restriction on its use.
That would be great. I am just starting to learn about the c55x and have access to a OMAP2. It also has "DSP Gateway". I will see how far I get with that.
 
Last edited by a moderator:
Last edited by a moderator:
Back
Top