ATI - PS3 is Unrefined

[expletive]

Qualia projectors (30K) and teh derivative "ruby" have 1920X1080 matrices and can input/output real 1080p. However you need 10K minumum and a dark room to get started.... 1080p and a dark room might be too tempting for some of you guys to resist....

The ruby can input/output 1080p but i dont think the qualia004 can, only 1080i in/1080p out.

That aside, these are still 1/4 the resolution of a 4k projector which currently requires a 10x10 room (just for the PJ) to operate in.

 

[London Geezer]

What I'm still wondering is - well, OK, does this have any appreciable significance?
There are well honed tools for the architecture, that's a plus.
It may not utilize limitations in rendering resolutions, but at 1920x1080 how large would the gains have been, and at what cost? I honestly don't know.
It may not project forward much in terms of feature set, but what features whould you like to see included? Would the transistor reallocation from the existing design be preferable overall? I don't know about this either.
It does introduce an independent 35GB/s communication link with the Cell processor, and probably not without reason. So what are the reasons, more specifically? Somebody has to have some pretty solid idea.

These are a few non-trivial questions that could actually shed some light on the reasons for, and consequences of the decision to with the RSX.

We'll not get real answers from that any time soon, but it's obvious that the i-expect-relatively-expensive 35GB/s direct bus from Cell to RSX is there for a very good reason, and lots of people seem to regard PS3 as this PC-like machine with a Cell chip in place of a CPU. That 35GB/s link is the real whopper in my opinion. I mean, "game data" doesn't need 35GBs and it's obvious Cell will help RSX in many ways. It's all to be seen how developers decide to use that.

 

[Laa-Yosh]

Precomputed does not necesserily mean static.

Well, you can precompute several different solutions for the various expressions and blend between them, but the size of the dataset is probably quite big, and the possible combinations of facial expressions are quite many...

Look, I'm sure there'll be pretty good looking fake SSS solutions, UE3 has a nice skin shader already. But the one the Molina head demo was using looks just too good to be completely realtime, IMHO. Disagree?

 

[ROG27]

You must be one of the people that believe the silly notion that the RSX was designed from conception to fabrication JUST for the PS3. I believe that the RSX is based on G70 family of GPUs.

Leave it to the delusional to believe that a "suped-up" G70 is a piece of crap not worthy of the PS3's greatness. But don't let me spoil your grandiose dreams of a multi-core, SPU-powered, mega GPU that runs at 32C in a $300 console the size of a PS2.

I think, in simple terms, they had this in mind for their respecitive consoles:

Sony's PS3:
Peer-to-Peer relationship between CPU and GPU (sharing much of the work back and forth...thus the syntax, or the relationship between the processors, not the processors themselves on a certain level, was what was highly customized in this system...the chips themselves were developed outside the realm of the PS3, but with the PS3 in mind, as well)

MS's XBOX360:
Master-to-Slave relationship between GPU and CPU (GPU being the bread and butter here-highly customized and some would say risque...and the CPU being a more generic, but powerful, part)

I don't know in particular which system will pan out to have better quality content from a technical standpoint (only time will tell)...but I certainly don't understand how Microsoft gets off saying there system is "more balanced".

 

[expletive]

We'll not get real answers from that any time soon, but it's obvious that the i-expect-relatively-expensive 35GB/s direct bus from Cell to RSX is there for a very good reason, and lots of people seem to regard PS3 as this PC-like machine with a Cell chip in place of a CPU. That 35GB/s link is the real whopper in my opinion. I mean, "game data" doesn't need 35GBs and it's obvious Cell will help RSX in many ways. It's all to be seen how developers decide to use that.

Doesnt it need that to be able to share the 2 memory pools?

 

[London Geezer]

Doesnt it need that to be able to share the 2 memory pools?

What do u mean?

 

[expletive]

What do u mean?

I probably dont even know what i mean but doesnt the bandwidth between Cell and RSX also get utilized if RSX wants to use any of the 256MB of main memory?

 

[Titanio]

I probably dont even know what i mean but doesnt the bandwidth between Cell and RSX also get utilized if RSX wants to use any of the 256MB of main memory?

Of course, but it doesn't need to use all of it..

 

[Laa-Yosh]

but I certainly don't understand how Microsoft gets off saying there system is "more balanced".

One of the reasons might be that there are less datapaths to manage; GPU - RAM, CPU - GPU, CPU - RAM perhaps but it goes through the GPU; and maybe we can count the GPU - EDRAM as well because it needs considerable manual management when tiling.
The PS3 on the other hand is quite a lot more complicated: CPU - RAM, GPU - VRAM, CPU - GPU, CPU - VRAM, GPU - RAM, and 7 times SPE local memory - RAM.

Knowing that console software performance is heavily dependent on the proper utilization of all these datapaths, we could say that the Xbox is a lot more balanced in terms of how much manual work and testing is required to get a certain amount of efficiency and performance out of the system...

 

[Lysander]

MS's XBOX360:
Master-to-Slave relationship between GPU and CPU (GPU being the bread and butter here-highly customized and some would say risque...and the CPU being a more generic, but powerful, part)

Dreamcast used same gpu-cpu relation:

 

[j^aws]

One of the reasons might be that there are less datapaths to manage; GPU - RAM, CPU - GPU, CPU - RAM perhaps but it goes through the GPU; and maybe we can count the GPU - EDRAM as well because it needs considerable manual management when tiling.
The PS3 on the other hand is quite a lot more complicated: CPU - RAM, GPU - VRAM, CPU - GPU, CPU - VRAM, GPU - RAM, and 7 times SPE local memory - RAM.

Knowing that console software performance is heavily dependent on the proper utilization of all these datapaths, we could say that the Xbox is a lot more balanced in terms of how much manual work and testing is required to get a certain amount of efficiency and performance out of the system...

I guess elegance is in the eye of the beholder. The datapaths that you refer to above, I can visualise as a simple network.

X360 would be like a 'star' network, with Xenos memory controller at the hub. It would have links to daughter die, system RAM and XeCPU.

PS3 would be like a 'ring' network, with the EIB at the hub. It would have links from this 'ring' to RSX, SPUs, system RAM.

I see elegance in both, but in different ways...

 

[Laa-Yosh]

But it's not a question of engineering elegance, it's rather about the associated development time and costs, IMHO...

 

[ROG27]

One of the reasons might be that there are less datapaths to manage; GPU - RAM, CPU - GPU, CPU - RAM perhaps but it goes through the GPU; and maybe we can count the GPU - EDRAM as well because it needs considerable manual management when tiling.
The PS3 on the other hand is quite a lot more complicated: CPU - RAM, GPU - VRAM, CPU - GPU, CPU - VRAM, GPU - RAM, and 7 times SPE local memory - RAM.

Knowing that console software performance is heavily dependent on the proper utilization of all these datapaths, we could say that the Xbox is a lot more balanced in terms of how much manual work and testing is required to get a certain amount of efficiency and performance out of the system...

I agree that how the PS3 will access memory is more complicated...but there must be good reason for it. Perhaps flexibility of functionality as an appliance would be one reason. Or do you think it was just necessary due to the cost-saving measure of opting for 256 mb of less expensive Gddr3 vram for the RSX (assuming unlike ram types cannot be pooled together because of bandwidth/clockrate differences)?

 

[Fafalada]

But the one the Molina head demo was using looks just too good to be completely realtime, IMHO. Disagree?

That's kinda besides the point - even you guys still use precomputation on occasion when it saves a buttload of rendering time. Are we gonna argue that using PRT to supplement ambient term would somehow make a fully dynamic lighting model not completely realtime, but before when you used constant color as ambient, it was?

Anyway as for actual practical usage - without knowing the dataset sizes used for the demo it's difficult to call it one way or the other - we can only speculate.
The demonstration for "animatable reflectance fields" a year or so ago (which looked strikingly similar to Molina demo in many ways, but more realistic) was using pretty huge precomputed datasets for the task (IIRC it needed 256MB graphic card to run) but it was also not really using any interesting compression for the data either.
If data can be compressed reasonably well (researchers that know more about this then I do, seem to believe it can) it isn't out of the question to be used, at least for cutscenes and the likes.

 

[j^aws]

But it's not a question of engineering elegance, it's rather about the associated development time and costs, IMHO...

If keeping to the topic, that PS3 is unrefined, then Huddy is way off, IMHO...

But to answer your question, one can argue that if RSX is more conventional, then it would have more proven tools, compilers etc, hence better ROI...The same could be applied to CELL and XeCPU...

 

[Titanio]

I agree that how the PS3 will access memory is more complicated...but there must be good reason for it.

Yes, of course, but that reason may not be compatible with "easier development" - reducing dev time and costs - which I think was Laa-Yosh's point.

Both setups have advantages. That a unified pool is perhaps easier to deal with is one advantage for it. Although I don't think a non-unified pool is going to drastically increase dev complexity or cost - it may in fact be transparent to software (with the caveat that you may need to watch for latency with certain operations and tasks).

I guess one advantage of having two pools of memory is less contention on the busses. Some, possibly large, proportion of memory access will be to their own local pools via their own busses, whereas with a unified setup, all memory access is via the same bus. Of course, there's still some contention as each chip can access the other's pool of memory, it's just not the same as it would be with one unified pool and one bus.

 

[ROG27]

Yes, of course, but that reason may not be compatible with "easier development" - reducing dev time and costs - which I think was Laa-Yosh's point.

Both setups have advantages. That a unified pool is perhaps easier to deal with is one advantage for it. Although I don't think a non-unified pool is going to drastically increase dev complexity or cost - it may in fact be transparent to software (with the caveat that you may need to watch for latency with certain operations and tasks).

I guess one advantage of having two pools of memory is less contention on the busses. Some, possibly large, proportion of memory access will be to their own local pools via their own busses, whereas with a unified setup, all memory access is via the same bus. Of course, there's still some contention as each chip can access the other's pool of memory, it's just not the same as it would be with one unified pool and one bus.

So sony was trying a best-of-both-worlds-while-still-trying-to-cut-cost approach...which from both a business and engineering perspective is very good.

 

[Laa-Yosh]

I guess the reasons for dividing PS3's memory could be the following:
- double the bus bandwith; it's more economic than a single 512MB pool with twice the bus speed
- making use of existing Nvidia tech (G70 memory controller optimized for graphics) AND Rambus tech (more suited to Cell)
- memory IC cost; XDR is probably not cheap

The downside is that data arrangement isn't trivial; 256MB is far too big for the frame/backbuffer and rendertargets, but there isn't enough space remaining for all your textures. So you have to store and access textures residing in two different memory pools (with different latencies)... or if you keep all the textures in XDR, then what happens to the remaining 100-200MBs of VRAM? And if middleware is used to hide the tech details, then performance will suffer.
One can certainly call this setup flexible, but IMHO, it's rather complicated...

 

[ban25]

I guess the reasons for dividing PS3's memory could be the following:
- double the bus bandwith; it's more economic than a single 512MB pool with twice the bus speed
- making use of existing Nvidia tech (G70 memory controller optimized for graphics) AND Rambus tech (more suited to Cell)
- memory IC cost; XDR is probably not cheap

The downside is that data arrangement isn't trivial; 256MB is far too big for the frame/backbuffer and rendertargets, but there isn't enough space remaining for all your textures. So you have to store and access textures residing in two different memory pools (with different latencies)... or if you keep all the textures in XDR, then what happens to the remaining 100-200MBs of VRAM? And if middleware is used to hide the tech details, then performance will suffer.
One can certainly call this setup flexible, but IMHO, it's rather complicated...

Sounds a lot like developing on a PC with a 256 MB 7800...

 

[Laa-Yosh]

That's kinda besides the point - even you guys still use precomputation on occasion when it saves a buttload of rendering time.

You are right, but our case is quite different because it's not interactive. We can precalculate ambient/reflection occlusion, SSS, bent normals etc.*, even 'bake' all the deformations and cloth animation, and then only re-render lighting, shading, texturing changes very quickly - but only as long as the camera and the animation does not change. With a game, you don't have this advantage, except maybe the cinematics.
We also have the advantage of almost unlimited storage place, because we can store everything on disk, and only a single frame's data will have to fit into memory at any given time.

(*: we usually don't store the radiance data itself, but rather render out all the components into separate image sequences that can be combined and further manipulated in compositing; most apps are now capable to add image-based lighting as well, using an enviroment map and a 'surface normals' pass)

Are we gonna argue that using PRT to supplement ambient term would somehow make a fully dynamic lighting model not completely realtime, but before when you used constant color as ambient, it was?

No, I fully agree with you here...

Anyway as for actual practical usage - without knowing the dataset sizes used for the demo it's difficult to call it one way or the other - we can only speculate.

If data can be compressed reasonably well (researchers that know more about this then I do, seem to believe it can) it isn't out of the question to be used, at least for cutscenes and the likes.

I think that it's reasonable to assume that a fully animated character in an interactive enviroment would require an amount of data that would be far from practical. Even if you'd only store progressive changes in PRT, SSS or such kinds of data, the increasing expectations for character animation mean so many keyframes, that even a single character becomes too big to fit in memory. This is why I've pointed out that the SSS for the Molina head is probably cached out - it certainly looks amazing as a techdemo, but I don't think that it's even remotely practical for an interactive application. Any serious deformation would break the SSS effect, and preparing for each possible combination of facial expressions (ie. angry smile, happy smile, sad smile...) would increase the dataset drastically.

And if there would be a reasonably good looking alternative to the time consuming rendering of each frame with raytracing, then the VFX industry would probably jump on it as soon as possible I think that on this generation, skin shaders that look sufficiently different from metal and plastic would already be a great advancement; and physically 'correct' SSS will be great on PS4