New dev tools ? PlayStation 3 Edge

[Titanio]

Is that 800k polys per frame, or per second?

Also, they give some figures for performance improvement when using SPUs, but does the article say if that's comparing the SPUs alone to RSX, or SPUs with RSX versus RSX alone?

Thanks one

 

[nAo]

Is that 800k polys per frame, or per second?

per frame

Also, they give some figures for performance improvement when using SPUs, but does the article say if that's comparing the SPUs alone to RSX, or SPUs with RSX versus RSX alone?

Thanks one

The article contains a few innacuracies and the old RSX sucks at VS is plain wrong...

 

[Titanio]

per frame

Cool, thanks.

It also seems to say something about this figure also not being the maximum, that the SPU is also doing something else in that scenario that takes some performance away?

 

[rounin]

For one thing, no matter how good Getaway looks graphically, I will have zero hope for the game until it is released after the first two games.

 

[DJ12]

The first one was OK I thought, nothing special, but not horrendous.

Black Monday though was pretty bad in my opinion, couldn't get into it at all.

 

[almighty]

As a side note, the last paragraph of the article contains what Nishikawa heard from several developers, they say the vertex shader in RSX really sucks. If they try to port a 360 code to RSX without using SPU, the polygon budget has to be cut.

Well considering in theory Xenos can have 48 vertex processors why is this such a suprise?

What does RSX have? 8?

And i also dont see that in a world thats now ruled by normal maps polygons are still talked about.

 

[KOA]

So was the demo done with ALL 7 SPEs dedicated to VS? Or was it just a couple of SPEs? If it's the former, then I wonder if this is a real-world scenario rather than another idealized tech demo.

 

[Carl B]

So was the demo done with ALL 7 SPEs dedicated to VS? Or was it just a couple of SPEs? If it's the former, then I wonder if this is a real-world scenario rather than another idealized tech demo.

Well, 1.4 million divided by .8 million per SPE would leave you with about 2 SPEs dedicated to geometry work in that respect, as it applies to this demo.

 

[almighty]

According to the video the geometry is running on RSX with object culling done on the SPE's.

EDIT : It seems that all the culling is done on the SPEs before being sent to RSX, simular to the way LAIR use's the SPEs for the same thing?

 

[MrWibble]

So was the demo done with ALL 7 SPEs dedicated to VS? Or was it just a couple of SPEs? If it's the former, then I wonder if this is a real-world scenario rather than another idealized tech demo.

After the GDC presentation someone asked about the number of SPUs used in the demo, and they said it was using 5. Maybe one of the SCEE guys around here could clear that up though, as they also gave similar sounding performance figures for a single SPU during the talk. Might've been comparing apples and oranges (different amounts of processing going on), or it might've been a typo in the slides...

 

[one]

Isn't it on SPURS? It might be that the tasks/jobs were spread on 5 SPEs but not fully saturating them.

BTW a few weeks ago I saw this very detailed presentation webcast for developers in Japan by one of the developers of the Cell microprocessor at SCEI about Cell and SPURS usage and it suggests there's a big performance gap between titles that use SPURS and that doesn't.
http://www3.stream.co.jp/www11/jinzai/20070301/04/index.html

With SPURS middlewares can work together (below) but with a custom task switching system they can't and idle time gets longer (above)

 

[patsu]

Thanks for linking and translating.

Is Edge an officially supported platform ? (e.g., bug fixes, further optimization, specialization, ...).

And yes, a key question is whether all 5 SPUs are used 100% or you can still submit more jobs to them via SPURS.

I am also keen to know what other advantages the developers will have by "integrating" vertex work on the SPEs.

 

[KOA]

Isn't it on SPURS? It might be that the tasks/jobs were spread on 5 SPEs but not fully saturating them.

BTW a few weeks ago I saw this very detailed presentation webcast for developers in Japan by one of the developers of the Cell microprocessor at SCEI about Cell and SPURS usage and it suggests there's a big performance gap between titles that use SPURS and that doesn't.
http://www3.stream.co.jp/www11/jinzai/20070301/04/index.html

With SPURS middlewares can work together (below) but with a custom task switching system they can't and idle time gets longer (above)

Sweet. So the OS scheduler schedules out processes across multiple SPUs.

 

[Butta]

It makes me wonder if ports will fare a little better given these tools. The 2D crowds in Fight Night 3 were really hurting! Well if Spurs turns out to be as good as it sounds, perhaps Joker454 can stop bitching about PS3 being vertex limited... I wonder what happened to that guy, it seemed as if he had just begun working on a PS3 title. Wonder what his opinion is now given these new tools?

 

[Shifty Geezer]

And yes, a key question is whether all 5 SPUs are used 100% or you can still submit more jobs to them via SPURS.

The graph at the top in the movie shows CPU usage, but I don't know how to read it! Were the 5 darker threads 5 SPUs? Or are the lines each aspects of Edge distributed over Cell?

Can any devs comment on what advantages/disadvantages this is bringing to graphics? It's unclear how this compares to a standard GPU-centric solution. eg. Are those 1.4 million triangles all rendered, versus perhaps 2 million triangles per frame of which half are not seen on a conventional GPU?

 

[Carl B]

It makes me wonder if ports will fare a little better given these tools. The 2D crowds in Fight Night 3 were really hurting! Well if Spurs turns out to be as good as it sounds, perhaps Joker454 can stop bitching about PS3 being vertex limited... I wonder what happened to that guy, it seemed as if he had just begun working on a PS3 title. Wonder what his opinion is now given these new tools?

I think we can all retrospectively agree that Joker's poositions were one born of a newness to the industry and a lack of experience. His positions were fairly obliterated halfway into that thing. That was a good thread though, and I do wonder where he's gone to, as more developers is always nice to have around.

 

[joebloggs]

Isn't it on SPURS? It might be that the tasks/jobs were spread on 5 SPEs but not fully saturating them.

BTW a few weeks ago I saw this very detailed presentation webcast for developers in Japan by one of the developers of the Cell microprocessor at SCEI about Cell and SPURS usage and it suggests there's a big performance gap between titles that use SPURS and that doesn't.
http://www3.stream.co.jp/www11/jinzai/20070301/04/index.html

With SPURS middlewares can work together (below) but with a custom task switching system they can't and idle time gets longer (above)

Can games only use 5 SPE's? Has another one been reserved?

 

[one]

Sweet. So the OS scheduler schedules out processes across multiple SPUs.

SPURS (SPU Runtime System) is not the OS scheduler, it's a lock-free runtime system spread over SPEs.

SPURS allows 2 programming models, SPURS Task (process division + non-preemptive execution by dependency) and SPURS Job (data division + pipelined parallel execution)

 

[patsu]

Can games only use 5 SPE's? Has another one been reserved?

You can use more (e.g., for audio, AI, and handling I/O)

To one...

What does the slides say about the "SPURS handler" in PPU ?

I like how the system can handle both data-oriented and process-oriented work at the same time.

 

[one]

What does the slides say about the "SPURS handler" in PPU ?

I like how the systems can handle both data-oriented and process-oriented work at the same time.

Around 20:00 the slide is shown but he says nothing about it. I guess SPURS handler kicks the first SPURS execution in SPE. Also it's likely when SPURS has to call a PPU thread it does remote PPU call via SPURS handler.

SPURS kernels do integration, 16 workloads can be registered for processing and a kernel fetchs them. The scheduling is priority-based. Priorities and orders can be set per SPU. SPU does non-preemptive scheduling by yielding control to each other by cellSpursModuleExit without context load/store overhead.