*spin-off* idTech Related Discussion

or how about :
"oh, well the Cell is not worth the cost and resources to learn to optimize for and maximize its potential, when having to use it to make up for an inferior memory and graphics card design"

What does that lead to?

Are you implying that developers should just drop using any SPU´s on the PS3 and go with whatever they can get from the "cpu" and the RSX?

The point is that the Cell does make up for what ever inferior performance the RSX may have. And it´s a very flexible solution, the games that uses this power shows it.

The developers that doesn´t design or plan their game engine with this in mind gets sub par performance and should be punished with bad reviews and sales.
 
What does that lead to?

Are you implying that developers should just drop using any SPU´s on the PS3 and go with whatever they can get from the "cpu" and the RSX?

The point is that the Cell does make up for what ever inferior performance the RSX may have. And it´s a very flexible solution, the games that uses this power shows it.

The developers that doesn´t design or plan their game engine with this in mind gets sub par performance and should be punished with bad reviews and sales.

I think his implication is rather more that Sony should not have put in a powerful but exotic CPU tied to a comparatively weak GPU, but rather, a powerful GPU paired to a similarly matched CPU. As far as I know there's nothing that benefited Sony in putting in Cell and a 7600-derivative GPU rather than a a more conventional, say, triple-core IBM PPC and a more powerful, say, 8600-derivative GPU, but the Cell + RSX combo is comparatively much more difficult to work with than my theoretical PS3 would have been.

Unloading GPU tasks to the CPU, in order to keep up with or overtake the 360, is not really an advantage to PS3 development, when the alternative was putting in a more powerful GPU to do those tasks anyway.

As for 'being punished' with bad sales and reviews - nonsense. If anyone should be 'punished', it's Sony for using such an over-complicated architecture in the first place. Giving Sony a green light for proprietary, exotic architectures that slow development down just to keep up with the Joneses while complaining at developers who don't want to/can't afford to put in that time and money is little more than a double standard.
 
On Sony's adoption of exotic architectures......didn't Sony go with the Emotion Engine solution in the PS2 not only because it was powerful at the time but because it was complicated? I remember hearing they wanted to force developers into parallel processing since they knew future systems would need it and as far as the PS3 goes, even if the PS3 doesn't get much love from the developers this time around, if Sony does go with a future Cell derivative in the PS4 (Quad Cell as on the IBM roadmap?), at least developers will be familiar with it, the only problem is pairing a proper GPU with it.
 
Eh, the RSX would've been fine if it was also the main chipset for the design (xbox 360 GPU) and controlled access to a unified memory pool (and had a 256bit memory interface to make up for the lack of e-dram)... the RSX isn't as much of the problem as the whole "256MB of GDDR for GPU and 256MB Rambus memory for Cell... you guys figure out how to share it..." Someone should have looked at that mess and said "Why don't we scrap the Rambus memory, it's slower anyway..."
 
Again, the main problem with the Rage engine specificaly is that virtual texturing is heavy on fragment processing, according to id. It's probably because they also have to do their own filtering calculations in the shaders. So it is actually an exceptionaly heavy workload, an extreme case - that happens to be what the Xenos is good at, thanks to its unified shaders.

But it does not mean that other games would pose a similar challenge for the RSX, maybe Brink with its own virtual texturing implementation is such a case but most of the regular engines are just fine with what the PS3 can offer. So let's not extrapolate too much from this.
 
But I still have a disconnect here... Most current Dev's share GPU workloads between the SPU's and the RSX to achieve parity with Xbox360's shared memory structure... Is JC going to have to setup 2 different Mega-Texture routines (one running on the RSX, the other the SPU's) so that the 2 "GPU"'s can effectively share data?

Not really sure about how it goes with other games but I'd like to emphasize again that each game's workloads and bottlenecks are different. But it's not like the SPUs are acting as fully featured GPUs, it's a very different case... For example SPUs can take over some of the first stages of the graphics pipeline like tesselation or skinning or vertex prepocessing; or they can be used to reduce the actual workload of the RSX, and so on.

Also, without knowing the specifics of id's tech5 or being a 3D engine coder myself, I can only guess - but I don't think Rage would be a different case. So again, SPUs won't act like a second RSX, it isn't effective to force them to do so anyway.

Don't other Console Dev's have to perform something akin to "Mega-Vertex" to trick the RSX into accepting Geometry that has been processed by the SPU's? Isn't the whole core of PS3 development oriented around using the hardware in unusual ways, especially texture memory addressing (See Ratchet & Clank's exotic texture scheme)?

You'll need a gprahics programmer to answer does questions, but I'd say your understanding is a bit wrong here, it doesn't work like that.
 
Eh, the RSX would've been fine if it was also the main chipset for the design (xbox 360 GPU) and controlled access to a unified memory pool (and had a 256bit memory interface to make up for the lack of e-dram)... the RSX isn't as much of the problem as the whole "256MB of GDDR for GPU and 256MB Rambus memory for Cell... you guys figure out how to share it..."

Set this thing clear for once now...

1. According to id, Rage requires a lot of fragment processing power for its implementation of virtual texturing.

2. RSX has separate and fixed capabilities (numbers of shader units) for vertex and for fragment processing, which is enough for most games but problematic for Rage.

3. Xenos has unified shaders which can all be used for fragment processing if there's a need, so it can cope with the workload in Rage a lot better.

That's it, so let's not try to invent other explanations until we know more about the engine.
 
On Sony's adoption of exotic architectures......didn't Sony go with the Emotion Engine solution in the PS2 not only because it was powerful at the time but because it was complicated? I remember hearing they wanted to force developers into parallel processing since they knew future systems would need it and as far as the PS3 goes, even if the PS3 doesn't get much love from the developers this time around, if Sony does go with a future Cell derivative in the PS4 (Quad Cell as on the IBM roadmap?), at least developers will be familiar with it, the only problem is pairing a proper GPU with it.

Sounds to me rather like sacrificing the today on the altar of tomorrow.
 
Yikes... Filtering... Kudos to Id if they can get this to work as stated... At the very least I expect the PS3 version to have a more aggressive LOD system with regard to AF... maybe some really heavy use of DOF to blur the blur...
 
Set this thing clear for once now...

1. According to id, Rage requires a lot of fragment processing power for its implementation of virtual texturing.

2. RSX has separate and fixed capabilities (numbers of shader units) for vertex and for fragment processing, which is enough for most games but problematic for Rage.

3. Xenos has unified shaders which can all be used for fragment processing if there's a need, so it can cope with the workload in Rage a lot better.

That's it, so let's not try to invent other explanations until we know more about the engine.

Sorry, I made that statement in response to some of the other OT stuff floating around here... but for Rage obviously the problem lies in shader processing...
 
Sorry, I made that statement in response to some of the other OT stuff floating around here... but for Rage obviously the problem lies in shader processing...

Though to be fair, Carmack's mentioned in the past that the memory split has been an issue for them since MegaTexture uses a lot less video memory and they would've liked to have had the left over memory available for non-graphics. But in regard to the framerate comments that doesn't seem to be the issue.
 
I think his implication is rather more that Sony should not have put in a powerful but exotic CPU tied to a comparatively weak GPU, but rather, a powerful GPU paired to a similarly matched CPU. As far as I know there's nothing that benefited Sony in putting in Cell and a 7600-derivative GPU rather than a a more conventional, say, triple-core IBM PPC and a more powerful, say, 8600-derivative GPU.
Excellent 1080p h264 decoding is one benefit. Probably the processing power for image interpretation via camera instead of additional expensive hardware could be another. The benefits to game developers of flexibility are probably less of a gain than the complexities are a loss, but I wouldn't say Cell_RSX is utterly without merit.
Set this thing clear for once now...
1. According to id, Rage requires a lot of fragment processing power for its implementation of virtual texturing.
2. RSX has separate and fixed capabilities (numbers of shader units) for vertex and for fragment processing, which is enough for most games but problematic for Rage.
3. Xenos has unified shaders which can all be used for fragment processing if there's a need, so it can cope with the workload in Rage a lot better.
Indeed. RSX and G70 just aren't particularly up to the task asked by megatexturing. Xenos is, whether by luck, a side effect of the US approach, or by judgement with ATi specifically thinking about how to support megatexturing and other open approaches to utilising the graphics hardware.
 
Indeed. RSX and G70 just aren't particularly up to the task asked by megatexturing. Xenos is.

Have I missed something here? Because if not, we don't know that and that either way from the article do we? The visible flicking of textures from LOD to LOD isn't what I'd call up to the task either, but then it's common is it to dismiss RSX without looking at the failings Xenos may or may not have?

The whole conversation is strange, because as far as I know we have no real context to the comments made. Neither why PS3 is or is not flickering, why Xenos is flickering yet running faster, where both engine implementations are, etc. etc. etc.
 
The "Xenos better for Rage then RSX" info is straigth from an id programmer.

Flickering may be caused by disc read issues instead...
 
The visible flicking of textures from LOD to LOD isn't what I'd call up to the task either, but then it's common is it to dismiss RSX without looking at the failings Xenos may or may not have?

Flickering lod's probably have nothing to do with xenos. The dvd drive might be seeking all over the place trying to feed pixel data, and possible falling behind in some situations currently. Installing the game to hdd would solve that, but they still have to make it work on the $199 hdd-less model.
 
Don't other Console Dev's have to perform something akin to "Mega-Vertex" to trick the RSX into accepting Geometry that has been processed by the SPU's? Isn't the whole core of PS3 development oriented around using the hardware in unusual ways
yes its possible + is often done on the SPUs, in fact back in the old days this was how it was practically always done. ( btw IIRC one of the id guys mentioned a single SPU can fully transform ~50million vertices a second)

though its not just vertex + geometry work that you can do on SPUs also fragment work, eg SSAO or a nice blur for DOF or bloom etc, or helping with shadowmap creation etc
 
Set this thing clear for once now...

1. According to id, Rage requires a lot of fragment processing power for its implementation of virtual texturing.

2. RSX has separate and fixed capabilities (numbers of shader units) for vertex and for fragment processing, which is enough for most games but problematic for Rage.

3. Xenos has unified shaders which can all be used for fragment processing if there's a need, so it can cope with the workload in Rage a lot better.

That's it, so let's not try to invent other explanations until we know more about the engine.

Point number 1 is agreed, but a question about Xenos and RSX fragment shading capabilities:

Doesn't RSX have equal (or even slightly better) "brute force" fragment shading capabilities?

Xenos has 48 unified shaders, each capable of issuing 2 instructions per clock cycle, but RSX has 24 fragment shaders, each capable of issuing 5 instructions per clock cycle.

That said, I know that Xenos has considerably finer granularity in its branching abilities, so does megatexturing make use of this finer granularity to make more efficient use of Xenos's fragment shaders?
 
As far as I know there's nothing that benefited Sony in putting in Cell and a 7600-derivative GPU rather than a a more conventional, say, triple-core IBM PPC and a more powerful, say, 8600-derivative GPU, but the Cell + RSX combo is comparatively much more difficult to work with than my theoretical PS3 would have been.

Since the RSX has double the number of fragment shaders of a 7600, as well as more vertex shaders, and other enhancements, I think it's a bit misleading to call it "a 7600-derivative". In fact, I'd be surprised if the 8600 was as fast as RSX. (The 8600 is certainly slower than most 7900's, which are arguably most similar to RSX.) Of course, the 8600 didn't launch until months after the PS3, and probably years after the first prototypes of the PS3 were made available to developers, so it's a moot point...
 
Xenos has 48 unified shaders, each capable of issuing 2 instructions per clock cycle, but RSX has 24 fragment shaders, each capable of issuing 5 instructions per clock cycle.

IIRC....
G70:
Fragment/Pixel Shader ALU dual-issue vec4, (so it's essentially equivalent to 48 single-issue Vec4)
Vertex Shader ALU co-issue is Vec4 + Scalar
5 instructions per pixel


Xenos: Vec4 + Scalar
apparently "6 ALU instructions per pixel" according to Wavey's document.

It may be worth noting that Xenos' thread scheduling should eliminate texture lookup stalls... something that'd be an issue for RSX (bye-bye half of fragment shading?).


That said, I know that Xenos has considerably finer granularity in its branching abilities, so does megatexturing make use of this finer granularity to make more efficient use of Xenos's fragment shaders?
IIRC, 64 pixels vs 1024 pixels.

edit: G70 might be lower than 1024... fuzzy memory is fuzzy. :oops:
 
John Carmack himself gave a good example on what might be an Xenos advantage:

"Embedded dram should be a driving force. It is possible to put several
megs of extremely high bandwidth dram on a chip or die with a video
controller, but won’t be possible (for a while) to cram a 64 meg
geforce in."

But again, the supposed higher Shader performance and the EDRAM advantage is all known factors and it´s been like this for a long time. That hasn´t stopped other developers from getting the same performance.

The real question is if id i able to get the Cell to do it´s part.
 
Back
Top