Asynchronous Compute : what are the benefits?

[3dilettante]

The question is how many gamer PCs are there that draw ~100W, and how many years there have been since they were anywhere near that level.

That alone puts a serious cap in what can be expected for performance, since Cell and Xenon came to be right when power became the primary limiter, and PCs kept on going.
Laptops that aren't desktop replacements can be closer, and it is possible for efficiency to allow for the consoles to have an edge over many power-restricted configurations.

 

[Rangers]

The question is how many gamer PCs are there that draw ~100W, and how many years there have been since they were anywhere near that level.

Given the recent XBO power supply discussions, wouldn't it seem closer to 150-200 watts, pending more confirmation?

Still way less than a gamer PC.

 

[3dilettante]

That number should have a significant amount of guard-banding, which I think might be more conservative than many PCs would be.
Besides that, the SoC was supposedly targeting ~100W, which is the primary performance factor.

edit: That 100W was for Durango, but the target for Orbis is going to be in the same ballpark.

It doesn't take an exotic CPU and GPU combo to go above that. An Intel i5 or up CPU and an AMD card with a power connector can hit that.

 

[onQ]

Not to be sideline moderating but why are people talking about Xbox One power supply in this thread?

 

[3dilettante]

Most indications are that it's going to be the same ballpark for the PS4, with some claims it's closer to the PS3 slim than the orignal PS3.
The original PS3's PSU would put it nearer to more desktops, although I don't know what the average PC gamer's PC would have for a PSU.

 

[DrJay24]

The fat 60GB was around 200w, the PS4 won't be near that.

 

[patsu]

Asynchronous Compute seems to be the biggest customization Sony made to the PS4 GPU hardware, yet I haven't seen much talk about it.

What do you think will be the biggest benefits of having a asynchronous compute architecture in a console?

The elements they changed stack together to form a consistent run-time. It's not just larger number of ACEs.

If they want to run a SPUR like threading framework on the GPU, there should be some form of app-controlled scheduling kernel somewhere in the system.

Cerny mentioned that he doesn't expect the devs to use these extensions until year 3-4.

We may have to wait for more info from the developers themselves (or more leaks).

 

[psorcerer]

For things that do very well on the GPU, Orbis could in theory do very well. The high peak FLOPs tends to be severely underutilized outside of the GPU-preferred subset, so I'd want evidence that Sony's tweaks have actually done enough to make GPU compute that much better than current APUs for things that aren't already a GPU strong point.

Every time I hear this "GPU strong point" argument I want to shoot somebody.
There is no such thing. GPUs _are_ strong. It's your code that's bad.
If developers can ditch old thinking and write new code, that fits into "thousand threads" paradigm - they will rule the tomorrow's world.
Single-threaded performance will not increase anymore, at all. You won't go anywhere with x86, no, it won't happen.
Either you will learn how to program modern massively-multicore CPUs (GPUs) or you won't get any performance. We are talking about gamedev, where normal people write things from scratch for each game, no need to support legacy bs. Just write proper code already.

 

[function]

What are you top tips for rewriting single threaded code as massively parallel code psorcerer? Perhaps you could give us some coding examples?

There's actually a hell of a lot of legacy code in game engines, just like in any other massive and iterated software engineering project.

 

[psorcerer]

What are you top tips for rewriting single threaded code as massively parallel code psorcerer? Perhaps you could give us some coding examples?

It's simple: do not write any single-threaded code.

There's actually a hell of a lot of legacy code in game engines, just like in any other massive and iterated software engineering project.

No, not in good ones. The reason "game engines" exist is purely business one: it's very easy to get 100 engineers from management (everybody needs a good engine), than 90 artists and 10 engineers.

 

[BRiT]

It's simple: do not write any single-threaded code.

Thanks for speaking up and removing all doubts...

 

[psorcerer]

Thanks for speaking up and removing all doubts...

Answer is always hidden in the question itself.
Modern CPU tries to turn any single thread into multi-port execution by using OOO, prefetch, uop split and all other ducktape-engineering solutions Intel/AMD invented over past decade.
I don't understand why writing proper code from the get go is worse than relying on hardware to rewrite it for you...

 

[Billy Idol]

Thanks for speaking up and removing all doubts...

But isn't he somehow right? I follow the same line of thinking for HPC...

 

[BRiT]

Not all algorithms are able to be parallelized. Coming out and saying 'run everything in parallel' is not a technical detail. To simply wave off the difficulty of making things run in parallel (especially with any sort of efficiency) is exactly the sort of saying I'd expect to hear from those who have no understanding. Sometimes the overhead of running in coherent parallel fashion outweigh simply running sequentially. There are always other costs or bottlenecks which have to be accounted for. No amount of bad-management mantras and no understandings ("make it faster") can wave off those factors.

 

[steveOrino]

I don't understand why writing proper code from the get go is worse than relying on hardware to rewrite it for you...

Cost

 

[Betanumerical]

Not all algorithms are able to be parallelized. Coming out and saying 'run everything in parallel' is not a technical detail. To simply wave off the difficulty of making things run in parallel (especially with any sort of efficiency) is exactly the sort of saying I'd expect to hear from those who have no understanding. Sometimes the overhead of running in coherent parallel fashion outweigh simply running sequentially. There are always other costs or bottlenecks which have to be accounted for. No amount of bad-management mantras and no understandings ("make it faster") can wave off those factors.

Isn't another option (albeit limited still) to run different jobs in parallel to each other and not trying to parallelise a single job over a large number of units?.

 

[Billy Idol]

Not all algorithms are able to be parallelized. Coming out and saying 'run everything in parallel' is not a technical detail. To simply wave off the difficulty of making things run in parallel (especially with any sort of efficiency) is exactly the sort of saying I'd expect to hear from those who have no understanding. Sometimes the overhead of running in coherent parallel fashion outweigh simply running sequentially. There are always other costs or bottlenecks which have to be accounted for. No amount of bad-management mantras and no understandings ("make it faster") can wave off those factors.

Well that is what I do: if the algorithm is not parallel, or even if it is foreseeable that it will not scale well...I don't consider it and search for something else. I know, as a scientist I have the luxury of time and no pressure and complete freedom...so it might not be that fair to compare this to game development...

 

[BRiT]

What are you top tips for rewriting single threaded code as massively parallel code psorcerer?

It's simple: do not write any single-threaded code.

Isn't another option (albeit limited still) to run different jobs in parallel to each other and not trying to parallelise a single job over a large number of units?.

Beta, yes that is another option but that's entirely not what psorcerer is saying the solution is.

 

[almighty]

For those interested in current power draw of a decent PC I actually have a meter on mine.

Intel 2600k at 4.7Ghz
8Gb DDR3 at 1600Mhz
2x 7950's at 960Mhz each
3x Mechanical HDD's
1x SSD
1x All in One CPU cooler
6x 120mm fans

Most it's ever pulled from the wall was 566w which at 80 PSU Bronze efficiency is ~453w actual power use.

 

[BRiT]

Well that is what I do: if the algorithm is not parallel, or even if it is foreseeable that it will not scale well...I don't consider it and search for something else. I know, as a scientist I have the luxury of time and no pressure and complete freedom...so it might not be that fair to compare this to game development...

That is entirely true. You are aware of the costs and it's good to see at least one person realizing that there are always multiple aspects to consider.