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

[Deadmeat3]

....

All this R&D only for a game console?

Yap.

PS3 will be the troian horse for something bigger than a game console.

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

I can't see what Deadmeat is freaking out about

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...

But my favourite patent so far is the one about overlays - for APU programs - the first to actually get me excited too.
- Two of the highlights for the lazy
a) automatic management for APU program uploads(although it should still be possible to do manually if situation requires it)
b) greatly relaxes limitations on APU program length - in theory there aren't any.

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

 

[Farid]

No real evidence for this at all, in fact MS have made sure that this time developers will have access to all low-level infomation, which points to absolute control when needed.

Don't read too much into XNA...

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.

 

[fxtech]

Me is gonna kill Panajev

PLEASE..use english as board language, or use PM

Mais pourquoi veux-tu que l'on utilise l'anglais comme base commune, on ferait mieux de tous s’exprimer dans nos langues maternelles respectives, ce serait beaucoup plus simple à comprendre…

Ou peux être pas…

"El Pericoloso Sporgersi" since that's one of the only sentence i know in italian...let's try to keep the discussion in 'ye old fashionned english' eh eh

Usate il linguaggio che volete, sono Italiano e parlo francese e inglese

Utilisez quelconque langue, je suis italien et je parle francais et anglais


Use the language you want, I'm italian and I speak english and french

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

vabbuono ?

 

[pcostabel]

Re: ....

You now understand why Tim Sweeney said he couldn't possibly imagine how he could program for CELL....

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

 

[Farid]

Utilisez quelconque langue, je suis italien et je parle francais et anglais

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

Use the language you want, I'm italian and I speak english and french

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.

Usate il linguaggio che volete, sono Italiano e parlo francese e inglese

El Pericoloso Sporgersi

 

[Panajev2001a]

actually rather the opposite if I am to believe that "layer renderer" patent.

Why ? The Hardware described by that patent looked to me like it could be an abstraction of what we know as Visualizer in Suzuoki's patent: CPU = PU, memory = shared DRAM, Image memory = Image buffer, parallel rendering engine = APUs + Pixel Engine, DMAC = DMAC, etc...

Can you please expand on this point ?

 

[phed]

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.

 

[Fafalada]

That sample code described an interaction between a master and an APU;

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.

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

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

Can you please expand on this point ?

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?

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

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

 

[Megadrive1988]

Quote:
All this R&D only for a game console?

Yap.

hey, nobody's perfect

 

[Deadmeat3]

...

It's just a simple illustration of calling an APU subroutine.

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

Even with a single APU you wouldn't usually use it like that for graphic processing - APUs don't require master cpu

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.

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

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.

 

[Fafalada]

They do, did you notice any return call on the apulet code?

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

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.

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.

I don't get it.

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

 

[MfA]

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.)

 

[Vince]

Re: ...

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.

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

 

[passerby]

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.

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.

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.

 

[Panajev2001a]

Can you please expand on this point ?

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?

Can you say that the patent implied something that goes against software rasterization ?

I do not think we can say that as as you said most of the patent described scene subdivision ( tiled in non-overlapping bricks or subdivided in over-lapping bricks and then have each brick tiled, etc... ), network rendering, etc...

I guess it was the fact that what the patent talked about was just so perfect for someone who wanted a CELL ( ) based networkd renderfarm or that wanted to see distributed real-time rendering in some form, that some of us made the extra step .

 

[Deadmeat4]

...

What do you mean by CSP? The Communicating Sequantial Processes algebra has little to do with pipelines.

I am not talking about CSP algebra.

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.

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.

 

[I.S.T.]

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

 

[Almasy]

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.

 

[I.S.T.]

Didn't Guden start that joke?

 

[Almasy]

Didn't Guden start that joke?

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