New Cell patents from IBM's Gschwind: the software side :).

....

Yap.

That's Kutaragi's dream, but no other takers...

That sample code described an interaction between a master and an APU; now imagine the interaction between a master and eight APUs, possibly all running different code block, and you begin to see the horror of CELL programming...

??? Which one are you talking about???

 

Thanks for the information DeanoC, that's surprising, i heard that MS was planing to give the minimum low level info...
Interresting if they are doing the contrary, it could mean that Xna is not 100% ready for Xboxnext and since they want developers to develops as soon as possible they might gave them low level infos...

Or it could mean that this rumor of MS wanting their Xbox being Hardware independant as much as possible, was just Hot air.

 

this is not B3D , this is little italy! so i still here in italy , then forgive my english and try to understand me

vabbuono ?

 

Re: ....

We know he couldn't possible program CELL...

 

Ça tombe bien alors, on aura ainsi aucunes difficultés de compréhension!

I'll try to keep my posts in english (or more exactly, gibberish) , even if learning living languages when browsing thoses boards could be practical, i must admit.

El Pericoloso Sporgersi

 

The code mentioned looks to me like a nice API. If you can just upload to all APU's, have some kind of select loop or a better kind of reactor you could use an eventbased approach to coding. It looks like regular network coding,
So, the threads is not a tangible approach here. So, the "hard coding"-part doesn't seem like anything a lightweight framework could solve.

If one had a programming language supporting continuations it would be pretty smooth. Especially since each of the APUs runtime is easy to estimate, the idle time on each APU can be reduced by a fair amount.

But, there's one thing that annoys me. There's a lot of requirements for "static pointers", and that seems pretty backwards. Perhaps some kind of memorymanager could solve this problem.

 

It's just a simple illustration of calling an APU subroutine. Even with a single APU you wouldn't usually use it like that for graphic processing - APUs don't require master cpu to lead their hand for running and outputing results.

Method and apparatus for overlay management within an integrated executable for a heterogeneous architecture.

It would help if you explained what you're asking me. I said the imaging patent barely touched rasterization details, and what it did say, didn't imply software rasterizing.
I don't see how what you replied has anything to do with that?

Not sure, but what do you mean by 'requirement' for static pointers?

 

hey, nobody's perfect

 

...

Looks like an MPI-style call to me(It is).

They do, did you notice any return call on the apulet code? The apulet simply processes what is given to it then freezes its stack frame at the end of execution completion, it's up to the cpu to set up the APUlet stack and then collect the result after execution is compled.

If you can't have APUs return result by itself, this will actually increase, not decrease, the programming complexity, since the coder has to manually pass on the result to the next APUlet. The APU to APU piping capability would have enabled a coder to set up a chain of apulets in CSP style, with data flowing from top to bottom to achieve a parallel execution with minimal burden on the coder.

I state this; CSP, not MPI or multithreading, is the correct way of engineering a parallel software.

I don't get it. That patent filing was about keeping the dynamic record of memory map during an execution for debugging purpose, I didn't see any mentioning of dynamic auto apulet upload thing.

 

They don't, that's just how this example was set up to work.

APU pipelining is something I've always thought possible (and we've discussed it on this board before). It could be a good solution for certain specific problems, but Imo it's far from a good general approach.

For starters, you're still reading the wrong patent.

 

What do you mean by CSP? The Communicating Sequantial Processes algebra has little to do with pipelines. It is a formalization of parallel programs with synchronous message passing ... which can be used to prove things about parallel programs assuming they respect some constraints.

(Slightly simplified ... you need to use synchronous message passing and no shared memory, unless it isnt writeable. Both those restrictions dont need to be as painfull as they sound, bounded FIFOs can turn synchronous into semi-asynchronous message passing and you can still communicate through memory as long as only a single process has read capabilities at a time.)

 

Re: ...

Wait, Faf, the PU touches this? Why does my thinking keep going back to the DMAC and polling the APUs.

 

It sounds very messy in a software dev environment for games as opposed to transputer programming(correct term?) env. Optimizing for equal load seems tricky. The nightmare starts when code modifications/maintenance happens - have fun reorganizing code and workload across the x APUs.

 

...

I am not talking about CSP algebra.

Exactly. You could break down any engine into a set of APUlets, individually coded and tested, bound together by pipes. But this feature requires more capability than what APU's runtime environment provides, so....

In someways, the CELL approach to synchronization is a mixed blessing. Unlike the traditional SMT where many threads running on called functions manipulate calling function's stack, CELL employs the reverse; the called function on APU never touches the calling function's stack on CPU, it simply computes what's given to it then stops, letting the calling function take care of what to do with the completed result. This approach avoids synchronization problem associated with traditional SMT and allows somewhat simpler development than what I expected of CELL's magnitude.

However, this is also a double edged sword since it does also restricts the scalability of CELL applications within the scope of the performance of the CPU that they run on. In other word, CELL applications are not going to scale to the order of million processors. But I accept that as a perfect trade for a console processor.

 

Jesus H. Christ, Deadmeat. How many bannings will it take for you to realize the mods have decided you aren't allowed here anymore?

 

He´s a bug in the Internet, his personality has been coded and dissaminated across countless PCs around the world. That is the only way he found to be able to continue hating on Sony forever.

 

Didn't Guden start that joke?

 

I´m depressed now, not even my jokes are original.