What happened to the Coding Competitions?


Wouldn't it make sense to have a DSP coding competition now to keep te momentum?
Click to expand...
such a competition, like the graphics demo compo Steven Craft suggested, would be nice but I doubt that it will have many entries (then again I am new to the Pandora but my impression so far is that there are not many graphics/demo programmers around here. at least I have not seen any original Pandora demos, yet. There's a port of one (very old) MFX demo, though.)


Besides, IMHO, what's needed now is organization/pjt planning/management, i.e. identify what kind of tasks need to be done (e.g. accelerate video decoding, discuss who ports which decoder to the DSP, how integration in ARM players should looks like, ..).  The "DSP corner" subforum where ppl. can discuss tasks/ideas, post questions about DSP coding and/or share their findings, would be a good way to get things started.


Regarding the (general) Pandora coding compo: Since in the past there were no separate compos for apps that e.g. use the SGX and those that don't, I'd suggest to do the same for the DSP -- if an app, which does heavy calculations and therefore benefits from using an additional (and faster) processor, uses the DSP, it simply will have an advantage over an app that does a similar thing but only uses one processor.

bsp almost has a really usable toolchain that makes compiling new DSP binaries really easy.
Click to expand...
wait a sec :) what do you mean by "almost" ? anything vital missing ? doesn't it work ?
 
bsp said:
wait a sec :) what do you mean by "almost" ? anything vital missing ? doesn't it work ?
Click to expand...
Nothing vital, it works well, except it still needs to compile the entire thing, new modules with the old, and integrating one's own code into the existing stuff is (easy but) not trivial.Once the overlay is working perfectly (or is it already? I wasn't really paying attention to updates this weekend, just a second... ok, looks like you did get it working well a few days ago, good job, so everything I'm saying may be completely out of date right now :p ) a perfectly usable toolchain will let you write code with a sufficiently generic makefile that it just works, user filling in required environment variables for the libraries and binaries first, of course.
 
While thinking about a good DSP competition I had a more general idea - what about an optimization competition? The community votes on some small number of applications that it wants the most performance improvement with, and the entries are ranked by how fast they are. The testing would be done with some set of inputs agreed upon as representative of a real world load. Using the DSP and other Pandora-specific techniques would be encouraged. There'd be some minimum improvement cutoff so you don't win by default by being the only entrant for some app, who managed to make it 1% faster.

The downside of this sort of competition is there'd be a lot of overlap in work, but competing against people in a very specific thing can be a good motivator to get people to do things. And afterwards the techniques could be shared and maybe cross-incorporated to an extent.

Not sure if there'd be enough interest in such a thing, though.
 
@WizardStan:

:) ok, sounds like you missed last weekend's update.

although this does not really belong in this thread: I said that the "xdctools_3*" and "bios_5*" directories/packages (1 Gig installed!) are not required for building own components/overlays: Currently you need to comment out lines 18 and 19 of "pre.cmd" (-llnknone.a64P and -lrtdx64xplus.lib) or the build will fail. I'll post the file on my site in a second.

To recompile just the overlays, type "m overlays" in the dsp/ directory (or "m overlays_bin" to continue the build).

Anyways, back to the original topic!

@Exophase:

The downside of this sort of competition is there'd be a lot of overlap in work
Click to expand...
This and do you think that there are enough people here who would participate in that kind of competition ?

Last but not least, I guess practically all of us do this in our spare time and instead of ending up with e.g. 5 blitter engines, it might make more sense to coordinate the effort so that we end up with e.g. one blitter engine (that can later be optimized), and e.g. 4 optimized (different) video codecs.
 
Last edited by a moderator:
There's always someone who is going to say "why are there competing efforts, why don't you all just work together?", but I think they underestimate the effect competition has on people. There's always a balance between competition and cooperation, and there are always challenges in coordinating work with other people.

The biggest potential benefit I see here is that more people are motivated to learn how to optimize. On the other hand, if a bunch of people want to get together and work on something as a team then split the reward there's nothing stopping that. Are there enough people who would do this? I have no idea, but I'd ask that about people entering a DSP competition to begin with. If the community picks a few programs to optimize upfront then at least there'd be some direction, that helps a lot.
 
What I liked about the last competition was that even I with my minimal skills could participate. I knew I wouldn't win, but it gave me a deadline and a reason to start doing something and work on my own project. I think that is what makes a competition successful, also because you get a lot of different and sometimes unique new projects going.

I can see how this may be boring or not a big enough challenge for the experts here, but to be honest I don't even know if I would be thrilled as a user about an <add unknown abbreviation here>-competition aiming at optimizing the <add another unknown abbreviation>  ... I have no doubt that some mind-blowing stuff would result from such a competition in the end, but I am not sure if the community will be into it as much ...
 
That's why I suggested the DSP challenge like I did: it doesn't have to do anything useful, it doesn't need to be fast, it's just a means of encouraging people to learn to use this new tool we have at our disposal. :)
 
Like I said: if one has mastered the current tools already I'm sure this is an interesting new challenge. I would have enough new things to learn already even without having to learn about DSP on top of that. (Not even sure if it would be possible at all, since my game would be Python based)
 
Rule 1 of programming: if you've mastered a tool you're wrong. :p

As far as "learning" DSP, it's just an RPC messaging system to communicate. There are python implementations, but probably more challenging to make work than the respective C libraries. Point taken.
 
oh, nothing. just the second main processor in the Pandora that's been laying dormant for the last years but is faster and more power efficient than the main processor (when not idle). just pretend it does not exist :)
 
Digital Signal Processor actually. Very efficient at taking in a stream of data, doing math on it, and then spitting out different data. Useful for things like sound processing, video decoding, encryption, really anything that just needs to do a steady stream of the same math over and over. And even if it's not, it's also technically a general purpose processor, so even if you aren't using it for its strengths you can still do a little bit of multi-threaded work. It's much more difficult than a dual-core processor would be, but might still have some interesting uses.
 
bsp said:
oh, nothing. just the second main processor in the Pandora that's been laying dormant for the last years but is faster and more power efficient than the main processor (when not idle). just pretend it does not exist :)
Click to expand...
Could you please dial down the hype a little? Running a toy fractal benchmark that wasn't particularly well optimized for the CPU and using that to make blanket statements that the DSP is faster is way over the top. You're going to give people the wrong idea and create a lot of new pressure from newbs to start moving everything to the DSP.
 
If we're going for over-hype:

Ti C64XX DSP, makes everything lightning fast, can balance your bills, Will be your best friend, it can make you attractive to the opposite sex.
 
TrashyMG, Love the name of it, the commodore C64 sound processor could be used for generic things too. Shame the last part of your post almost exclusively only applies for females.

Could this TI C64XX DSP be made to do the more heavy digital to analog sound processing algoritms in alsa/pulseaudio? From my experience if you dont have support for it and you set it to heavy (there are many others to chose from) it uses quite a bit of cpu power on a x86_64 machine. And the more correct re/sampling is a nice feature, the audio stage on the pandora is very capable already.

Edit: which one is it, the link on the wiki was (dun dun) broken.

http://www.ti.com/lsds/ti/dsp/c6000_dsp/c64x/products.page  

http://processors.wiki.ti.com/index.php/C64x%2B_and_Davinci_codec_performance_tables

omap3525_30_chip.jpg


OMAP3525/30 Processors:

  • Combinations of the Cortex-A8 core, OpenGL® ES 2.0 compatible graphics engine, video accelerators and the TMS320C64x+ DSP core.  ?
 
Last edited by a moderator:
Can we hope to ever use gcc to have the DSP as a target? Or at least some open source compiler? I would love to try coding some stuff on the DSP, but I do all my coding on the Pandora itself, and I'm not going to do it in qemu to be able to use TI's x86 toolchain :)
 
You must log in or register to reply here.

Similar threads

Mr_Loon
Can we have a dedicated competitions section for the forum?
Replies
3
Views
1K
EvilDragon
EvilDragon
S
Coding Competitions
2
Replies
23
Views
3K
Sdw
S
foxblock
RIOT Tag-Team coding competition
10 11 12
Replies
227
Views
33K
THB
THB
_wb_
Another contest?
Replies
13
Views
2K
foxblock
foxblock
mjohansson
Community game developing culture and challenging competitions
2
Replies
36
Views
3K
mjohansson
mjohansson
Back
Top