PDA

View Full Version : RSX: Vertex input limited? *FKATCT


Pages : [1] 2

Hypx
26-Dec-2006, 22:37
http://www.avsforum.com/avs-vb/showthread.php?t=773344&page=2&pp=30
http://www.avsforum.com/avs-vb/showthread.php?t=774032&page=3&pp=30

There's this guy named joker454 who claims to be real dev who has experience at work with both the Xbox 360 and the PS3. He clearly knows something about the nature of these two systems as he's pretty competent about them and has not made any obvious errors. However, he also makes some dubious sweeping claims which may mark him as a fake. Unfortunately, my own knowledge of this subject is not nearly enough to judge him, so I'm hoping someone else can look at it themselves. Here are some statements of his that I've find interesting:

"I'm a programmer I assure you, been one for 12 years in the games industry. No, I can't say my employers name because my comments could be construed as representing their opinion, which would get me into trouble."

"That's fine, they probably have played games I've programmed on, especially if they are into sports games"

"There are *very* few instances where one would pick the PS3 gpu over the 360's because the PS3's gpu is weak compared to 360's. That's not just my opinion, ask other devs how they feel about it. Sony chose poorly when they chose the video hardware. Performance wise, the 360's video will out render the PS3's everytime if you feed it the same 3d scene. The only way to make the PS3 keep pace is to leverage its spu's to preprocess your 3d scene."

"I have a shader that needs 8 vertex inputs, Position, Normal, Color, and Texcoord1 thru Texcoord5. Assume all inputs are packed (ie, .x, .y, .z and .w are all used). Further, I need this shader to be applied to a mass of 100 enemies that are all close to the camera (and hence using their best lod) and are 5000 verticies each. Or if you prefer, imagine that it needs to be used on a 3d scene of 500,000 verts. These scenarios are quite common, and they *kill* RSX performance. If you don't believe me, just read the RSX docs, its right in there and it literally says "this kills RSX performance". The only way to accommodate these scenarios is to precull using the spu's. If you just rely on the RSX to do it for you, then you will never match the xenon's framerate, period. This isn't conjecture or opinion, its hardware design fact. Again, I encourage you to read the RSX docs as well as PS3 dev forums, I'm not the only one complaining about this."

"I'm a 360/PS3 programmer by trade, focusing on graphics and optimization. It's fairly rare that I post, but I just got off a long crunch and have been browsing the forums more than normal to unwind Incidentally most of that crunch was spent trying to get the PS3 to match the 360's frame rate. It falls short, but it hits 30fps so we're ok.

The Gran Turismo image posted above is a good shot, but its a testament to the talent of the dev crew, not just the hardware. Vertex/pixel shaders are written in HLSL and can be compiled to run on either PS3/360 although you can tweak them to suit the console. I guess my point here is that if you take that same vehicle 3d model and those same shaders that make it look all pretty, and compile/run them on the 360, it will look the same and run at a higher framerate than on the PS3. This is because the PS3's gpu isn't as good as the 360's."

"I'm assuming you also know that the PS3's vertex processing units are terrible, since each extra vertex shader input ads one cycle of delay. Likewise, you probably also know that the only way currently around this limitation on PS3 is to use the spu's to preprocess all geometry by backface culling them first on cell before feeding them to the gpu. But then you are still stuck with other PS3 gpu limitations, such as not being able to do anti aliasing with floating point render targets so you can't have MSAA and HDR simultaneously."

"The vertex pipeline doesn't matter when you have to waste one cycle per vertex input. In other words, the gpu stalls untill it can fetch all the data it needs before it can even start executing the vertex shader. Why is this important? Because next gen games needs lots of lookup maps to look nice, which means lots of u/v coordinates and other data that needs to be passed to the vertex shader, ie, lots of inputs. In RSX's case, that means gpu stalls. This is the RSX's well known achiles heel and is well documented. The only known work around at the moment is to use the cell spu's as another 'gpu', in this case a culling gpu, to limit the number of verts actually sent to the RSX. Whether or not RSX+SPU culling will help PS3 meet or exceed xenon's gpu performance isn't known at this point."

"You don't think no msaa with floating point buffers isn't a huge limitation? There are other color spaces, but they are useless to me. I don't need 8/8/8/8 int. I need 8/8/8/8 float. In RSX's case you have no choice but to use FP16 (16/16/16/16), compared to FP8 on xenon. So you are forced to move around twice the memory on RSX if you want a floating point buffer, which means less framerate. Just try it! I'll assume your a game dev. Switch your PS3 game from FP16 to an 8/8/8/8 int format and see your framerate jump. Of course, you'll have to forgo HDR on your shipping title, but you can then do msaa. Or, go back to FP16 since HDR looks so cool, but oh ya, you then have to turn off msaa. I just don't have these headaches on 360, but I have to deal with them PS3."

The only thing I can definitely say is wrong is the last quote, since we have a dev (Deano?) who's working on a game that gets around the problem. As for the others, I'm getting a few hints that it may be wrong or it doesn't add up, but I'm not knowledgable enough to definitely put my foot down.

Mod:
Just to make sure everyone sees this, there're as of now special rules in this thread to improve the S/N ratio. They can be found here (http://www.beyond3d.com/forum/showpost.php?p=899848&postcount=123)

ERP
27-Dec-2006, 06:50
I have no idea if he's a dev, but vertex setup is definitly an issue on RSX, anyone with a 7X00 can run benchmarks and verify the cost of additional attributes.
To my mind though RSX's bigger performance issue is the shader constant patching, it can be a real performance killer.
I know of teams using SPU's to try and alleviate the worst of both problems.

As for the performance comparison, I won't comment beyond the fact that I do know of teams who have found it challenging to get assets built for Xenos running well on PS3.

inefficient
27-Dec-2006, 07:34
Et tu Gabe Newell?

I would bet money that his 12 years in the gaming industry has been as a PC developer. This is very reminicent of when Valve complained about nvidia being hard to work with.

He is complaining about doing extra work to get performance to match what can be obtained on another vendors hardware. On the PC platform this sort of complaint is reasonable. Identical CPUs identical API, you want your hardware to perform very similarly without vendor specific optimizations. But in the console space... it's naive thinking.

Complaining about having to pre-cull geometry on the SPU before sending to the GPU... The fact that the Cell is good at that should be listed as a strength, but he cites it as a weakness because he does not want to spend the effort to tap that performance. I guess that is fair if you are working on a low budget project. But even he himself admit that this technique could result in performance that exceeds what is possible on Xenon.

nAo
27-Dec-2006, 07:52
Different platforms require different care, would not be surprised if ppl working on 360 and suddenly dropping their datasets onto RSX would not observe good numbers (and viceversa)
Now..I can't see how RSX, if used in the right way, should be so limited at vertex processing: in HS we easily render 2-2.5 MTriangles per frame at 30 fps without being VS limited and without making any use of CELL to speed up vertex shading and I know for sure that being more clever we could even go faster..(just using the GPU)

"Nerve-Damage"
27-Dec-2006, 07:55
Even if he or she is a developer, that doesn’t stop them from posting false and inaccurate information. Who’s to say he isn’t jaded by his own personal feeling about Sony or it’s hardware.

Acert93
27-Dec-2006, 07:57
I dunno if he is a developer but he is obviously fairly knowledgable, aware of some of the internal docs, and responds to insults with examples to "prove" his points. And to clarify his own point, which he keeps repeating:

Remember, I'm not knocking the PS3 as a whole, I was knocking its gpu.

And his comments are not all negative. He feels Sony's Playstation is still a dominant brand and will seel great. He also points out issues on the MS side, specifically the CPU:

Regarding cpu, yes its totally different arguments. The 360's is a very standard setup, a bunch of cores that can all see main memory. The advantage to this is that lots of thread coded written over the years can be ported to it easily. For example, Valve (the Half Life guys) are writing an entirely threaded engine for the PC. When it's done, porting it to the 360 will be easy. How about porting it to the PS3? Nope, won't work, it's a totally different setup. The PS3's main core is basically the same, but its spu's can't see main memory. Each one has 256k that it can work with, so you need to rewrite your code to pack things into 256k chunks, feed it to the spu's to process it, then copy it all back to main memory. In other words, you've gotta rewrite your code.

Now before I get jumped on here let me briefly mention the downsides. The 360's cpu setup is painfully easy to code for. But, they really aren't all that fast. Worse yet, all three cores use the same memory controller so the three cores are not three times the power of the one core on the PS3 due to some overhead. The PS3's spu's on the other hand are monstrously fast. You need to setup your data correctly to work with them, but once thats done then yes, the 360's cpu setup is crap compared to fully working spu's. I say fully working because most current games out there barely even touch on them, it will take time to re-write everything. I haven't done spu coding....yet. I will be though in 2007 which will be pretty cool.

His own summary seems to be

I think one of you early comments sums is up. "The two consoles trade blows fairly evenly". That's part of the problem. I was expecting PS3 to offer more (especially on the gpu side of things) because it came out a year later. Instead, you could argue that they are more or less equal because one wins on video, the other on cpu. That's dissapointing to me for a box that comes out a year later and costs more.

That and difficulty tuning his code seem to have him bitter. Now I am sure a number of developers here will disagree with him, especially PS3-specific devs. And he may be a crackpot just mimicking what he hears on places like B3D and is basing a lot of his comments based on benchmarking G70 as well as the widely circulated RSX docs (and maybe access to the PS3 developer forums).

Or he could be a young developer, junior programmer, etc There are tends of thousands of devs out there, and that one may speak out over the holiday break rushing to get a game out after a long crunch is not unfathomable. I guess it is really up to other multi-platform devs who have gone through what he has, porting an Xbox 360 codebase to the PS3, to really give us an indication if he is full of it and just parroting what Xbox fans think that they think they know or he could be legit -- or legit and biased. Some developers have a bias you know! They are human too. And the bias may be as simple as, "The PS3 makes me work hard... screw that!"

Interesting thread and his candid, yet calm tone, actually allowed for some real discussion. How accurate it is, I don't think we will known until the PS4/Xbox3 is out :P

Acert93
27-Dec-2006, 08:03
Different platforms require different care, would not be surprised if ppl working on 360 and suddenly dropping their datasets onto RSX would not observe good numbers (and viceversa)
Now..I can't see how RSX, if used in the right way, should be so limited at vertex processing: in HS we easily render 2-2.5 MTriangles per frame at 30 fps without being VS limited and without making any use of CELL to speed up vertex shading and I know for sure that being more clever we could even go faster..(just using the GPU)

Thanks Marco. I think your first statement is probably the best assessment. While not quite as radical, a developer moving SPE code to Xenon or an x86 chip would probably be in for a world of hurt, especially if it was something significantly parallel (e.g. 4 or 5 SPEs).

I will track down more info on him or her.

Are we sure we want to do that :???:

What, are we going to start hunting down ERP, nAo, DeanoC, Faf, Panajav, MrWibble, Fran, Cal, and so forth? So we want to stake out Dave B, geo, Vysex, Hupf, Uttar, and so forth and go through their email and such to make sure their connections are accurate?

If he is fake his own words will end up nailing him. If he is legit such an open search--just the stuff you brought up--could get him canned.

People complain all the time that we cannot get insider info--even if it is stressed out frustration--and yet when it disagrees with what we want to hear we try to ruin them. Good way to chase off the devs we have here.

Sorry, I think the cybersnooping comment should be deleted, but that is just me.

-tkf-
27-Dec-2006, 08:18
I guess my point here is that if you take that same vehicle 3d model and those same shaders that make it look all pretty, and compile/run them on the 360, it will look the same and run at a higher framerate than on the PS3. This is because the PS3's gpu isn't as good as the 360's."


Isn´t this impossible to do? I mean the two GPU´s are by nature radical different so anything made for one GPU would rarely benefit from the advantages of the others. Or is the RSX really so weak that "common" shader code would run like shit compare to the Xenos?

Carl B
27-Dec-2006, 08:23
I'm with Acert; do we judge the message or the messenger around here? Whether or not this poster is in the industry... and he certainly seems to be IMO... I think his points should just be deconstucted as any other posters points would be.

There seems to be this strange mythos on the Internet that if a 'developer' says something, it somehow takes on the force of natural law. But we have many a dev here, do we not? And they disagree on points all the time.

For me it's as simple as this: he makes a point in terms of the 360 GPU being 'ahead' of the PS3 GPU in several respects. Hey, I think we've had the discussion here enough times to know, yeah in many ways it is. But at the same time he treats the GPU as both the beggining and end of the graphics subsystem, where we know in PS3 the Cell is set to play an ever larger role as tme goes on. And in this regard, he admits to never having touched the SPEs, but acknowledging their power and looking forward to the opportunity.

Anyway... well I'm an AVS member myself but I've been too emotionally involved there of late to respond in that thread right now; I'm trying to scale back and detach myself from the BD/HD DVD war presently underway there, which is so much more over the top than even any gaming forum you've ever seen.

But maybe I'll link him to this thread here and he can acquit himself directly among a more appropriate grouping of individuals. Certainly I think some good conversation could arise from it, though again, probably not anything we haven't covered before. :cool:

@Nerve Damage: After update 3, you are seriously out of control.

Acert93
27-Dec-2006, 08:25
Isn´t this impossible to do? I mean the two GPU´s are by nature radical different so anything made for one GPU would rarely benefit from the advantages of the others. Or is the RSX really so weak that "common" shader code would run like shit compare to the Xenos?

He notes the use of HLSL and the specific issues he has had were vertex related and the use of floating point blending format performance and compatibility with MSAA (i.e. their engine was designed to do HDR with a floating point render target and using a colorspace solution like NOA32 was out of the question at that point in development).

As nAo and ERP noted, going from one to the other can pose some problems. An example, the assumption has been Xenos has better dynamic branching performance for pixel shaders (due to a smaller batch size), so game code built on the 360 ported over may need to rework this because it may not (or it may!) not run very well "as is" very well. There are examples on both sides of the fence.

RobertR1
27-Dec-2006, 08:27
Anyway... well I'm an AVS member myself but I've been too emotionally involved there of late to respond in that thread right now; I'm trying to scale back and detach myself from the BD/HD DVD war presently underway there, which is so much more over the top than even any gaming forum you've ever seen.


You got sucked in soooooo easily!!! Sucker!!! :razz:

RobertR1
27-Dec-2006, 08:33
:lol:

Anyhow, I found many post by this guy (with the same residing area and screen name) asking some of the simplest questions on how to hook up his tivo to his TV. Or what’s the difference between optical audio cables and coax digital audio cable. To me even a guy with his background can figure that out by himself.

Exact stuff I didn't know until about 6months ag. Everyone has to learn at somepoint. Not everyone is born "1337".........A/V is so damn confusing. Trust me, it'll have you hating life quickly......

Acert93
27-Dec-2006, 08:34
But maybe I'll link him to this thread here and he can acquit himself directly among a more appropriate grouping of individuals. Certainly I think some good conversation could arise from it, though again, probably not anything we haven't covered before. :cool:

We could always use some more devs here, and a multi-platform dev who is looking at issues from the porting process could be valuable representation of the market we don't get much from. We tend to look at things from the absolute extremes/best case scenarios, etc -- because lets be realistic, we all want the best games totally tapping the potential of a platform, and hence with the slew of titles we tend to get really worked up for the cream of the crop -- but the industry strongly relies on the guys doing the grunt work pushing out titles to appeal to a wide audiance. Many of us may loath EA (sorry devs!) but they are a huge part of the industry, and knowing how the next gen consoles impact their development processes is a valuable source of information.

Of course he could be making things up, in which case it would be a public service to show that, but he seems legit enough.

But I think a mod should really clean up the witch hunt and certain comments about where the same name has been found on the net. People can find all kinds of interesting things about me on other forums, but posting them here as a personal insult / hunt me down is waaay out of bounds. And if he is a developer he should be made to feel at home and welcome to share, discuss, and debate his point of view, even if it is wrong. :razz:

RobertR1
27-Dec-2006, 08:35
This is also another interesting thread on AVS with a lot of technical info which I'm sure you guys would love to argue for 10,000 posts about :)

http://www.avsforum.com/avs-vb/showthread.php?t=758390

"Nerve-Damage"
27-Dec-2006, 08:40
But I think a mod should really clean up the witch hunt and certain comments about where the same name has been found on the net. People can find all kinds of interesting things about me on other forums, but posting them here as a personal insult / hunt me down is waaay out of bounds. And if he is a developer he should be made to feel at home and welcome to share, discuss, and debate his point of view, even if it is wrong. :razz:

Done it already. :oops:

Acert93
27-Dec-2006, 08:43
Anyhow, I found many post by this guy (with the same residing area and screen name) asking some of the simplest questions on how to hook up his tivo to his TV. Or what’s the difference between optical audio cables and coax digital audio cable. To me even a guy with his background can figure that out by himself.

Hahaha I have some of the most stupid posts on the net. It is how you learn. If I don't know something I go somewhere and ask :smile: And I try not to presume to know anything because then people skip stuff you need to know. Heck, 2 years ago I changed the HSF on my NV40 and when I turned my PC on poooof! Big plume of smoke. Oh, and that was after like 4 hours of trying to figure out how to undo some little silly screws... and after cutting a wire I didn't need to cut. You would think I was a total newb, less the fact I have been doing upgrades and mods on PCs for nearly 20 years. And buying my first digital camera (2 years ago), LCD (last year), and MP3 (4 months ago) were experiences full of ignorance, yet most would consider me above average in techn savvy. As I should seeing as I spent 5 years in customer care and management in a small IT company and made almost all our technical purchasing decisions. Some skills and knowledge migrate well, others not so. Btw, I don't own a TV (all gaming is monitor based) so I couldn't tell you the difference between an optical and coax cable... but I could tell you a world of things about a DVI and VGA. I was say the joker guy shows some restraint and qualifies his experience (e.g. little experience in PS3 online and recent updates). Typically an online know it all tries to prove they know everything about anything and really don't know anything about everything!

zRifle1z
27-Dec-2006, 08:45
I'm with Acert; do we judge the message or the messenger around here? Whether or not this poster is in the industry... and he certainly seems to be IMO... I think his points should just be deconstucted as any other posters points would be.

............

@Nerve Damage: After update 3, you are seriously out of control.


I second that 100%

This is a new low for this forum IMHO, just a sad attack on some very good information.

nAo
27-Dec-2006, 08:46
This is also another interesting thread on AVS with a lot of technical info which I'm sure you guys would love to argue for 10,000 posts about :)

http://www.avsforum.com/avs-vb/showthread.php?t=758390
A lot of wrong techinfo, not worth reading.That guy has no idea of what he's talking about

inefficient
27-Dec-2006, 08:56
This is also another interesting thread on AVS with a lot of technical info which I'm sure you guys would love to argue for 10,000 posts about :)

http://www.avsforum.com/avs-vb/showthread.php?t=758390

Yikes! Misinformation ahoy! And I only got as far as the 3rd paragraph!

I don't know whether to laugh or cry...

Acert93
27-Dec-2006, 08:58
A lot of wrong techinfo, not worth reading.That guy has no idea of what he's talking about

Yeah, like the name of the other CPU he was comparing :P And he totally misses the boat by a mile wide and mide deep on backwards compatibility too. And I think that is just common sense IMO. Cell meet Cell2. Happy times. If anyone is going to have a problem it is MS. They had a hard enough time going from a Pentium3 to a PPC and all the associated differences (ISA, endian, general architecture) and that even with the frequency improvements it was/is a mess. Moving to an AMD chip (some sort of fusion? or a lot of K8Ls with some HTT3.0 buses to specialized chips) or to Intel (maybe something derived from their crazy 32 die/128 thread monster) would cause all kinds of issues. First is the threading of the tricore Xenon, but MS could end up in a situation where the CPU cores could be negligably faster, if not slower in some situations, than Xenon. If the "power race" is in many more cores, emulation could be a problem.

Conversely, the problems some may be having with Cell now will pay off with Cell2. People will have 5-6 years experience, robust librarys, and solid middleware to hit the ground running. For your parallelized code that performs nearly linear with additional SPEs you now could have an additional 20-50 SPEs to toss at the problem. Sony's strength may not be software, but they have created a bonafide platform with Cell. I expect 1st gen PS4 games to hit the road running, and running fast--as well as good BC to boot!

StefanS
27-Dec-2006, 09:21
Time for the friendly mod advise:

Seriously guys, don't track down somebody else. Knowing their place of residence doesn't in/decrease their credibility. An imposter is more likely to be uncovered by his false information than his personal details. Moreover, if the guys really working in the industry, he could get in all sorts of troubles.
We as mods are trying to protect everyone's privacy. You don't want anyone to hunt you down, either - And I certainly want anyone to go through my web browser's history :twisted:. To sum it all up, it's a big no-no. Although it's hardly necessary, I'll add it to forum FAQ for future reference later on.

"Nerve-Damage"
27-Dec-2006, 09:31
^^ I’m sorry for being a ass-hat… :sad:

A lot of wrong techinfo, not worth reading.That guy has no idea of what he's talking about

Thanks.

LunchBox
27-Dec-2006, 12:57
As the others have said, it's a fake.

liolio
27-Dec-2006, 14:34
I feel strange about the fact that this dev says that xenon is easy to code for.
Most of the power of the xenon comes from its three simd unit.
I guess it take time to make the most out of these unit the same way is tought on a spe (except some memory management).
I don't question the cell has more muscle, my question is more like this :
Devs who want to use the power of cell have to code for the spe properly.
good habits=>> good results
But xenon seems more forgivable (i know it's not OoO, lake good speculative execution, etc... so it's not so forgivable) ot least let dev use more traditional coding.
There is very few post about xenon here, but it seems not to be so closed of the ppe and there's few thread about it:
vmx128 units can prove to be powerfull 128 registers same speed as spe, some hardwired functions.
Fp unit and vmx unit are decoupled they have their own "instruction queue" (can find the correct word) and can issue two instructions per cycle so at some point a xenon core can be 4 issues two from integer&branch units two from fp&vmx units.
I remember reading the vmx128 have some optimizations to keep execution units busy (poor OoO? technical insight or proper links welcome :) ).
So to me it seems that for to make the most out of the xenon needs some heavy work too.
do you think it could turn in bad habits==>no so good results situation as far as xenon programming is concerned?
And any insight on the the xenon design is welcome ;) (ars technica article is bad documented... and there few interesting articles on the web :( )

Capeta
27-Dec-2006, 14:50
The fact Xenos has 3 identical cores lends itself to easier programming, relatively speaking.

liolio
27-Dec-2006, 15:17
The think the fact Xenos has 3 identical cores lends itself to easier programming, relatively speaking.
I think the fact the xenon has a share L 2 help too.
But like this dev state the memory controler is share too so there can some concurrencies between the differents cores :(
So it the same question if dev use the xenon as a multi core X86 state of the art core the xenon will perform really poorly. The same bad habits in programming yeld in bad results performance wize.
Devs can manually manage the L2 cache and split it in regard to memory usage of the different cores.
Xenon's code has to be handtuned for good results, the fact the design allow some poor coding is not a good news.

Anyway any links or insight on xenon design are welcome the few threads here or around the web turn too quickly in vs thread to be interesting and the fact xenon is not supposed to be used outside the 360 doesn't help.

Edit Sorry if it's slightly HT but I would like to open a thread about xenon but I don't have the knowledge to keep it alive.. I have a lot of questions, exemple: insomniac devs run collisions system on 2 spe and manage to keep everything smooth with 40 characters and a lot of projectiles. 2 spe equal the computational power of two altivec128 untis and use 512Kb of LS half of the xenon L2 cache. How this could be mapped on the xenon?
why the same devs use two spe merory space (need of 512kb of LS)? computational power? how this is feasible on xenon? the same is feasible on a good X86 (with less computationaal power) I guess so I need technical and somewhat slightly trivial insights.
(sorry I know I lake a lot of knowledge but I 'm sure some here can put together a not so trivial answer that me and a lot of others can understand :) )
I know it looks like vs question but it's really interesting questions and a good way to enlight designs strenght and weakness.

Bobbler
27-Dec-2006, 17:31
Heh, a few of those quoted responses in the first post were in response to my post over there (fronn).

What I responded to didn't really sound like something a dev would say and contained a lot of fishy information, so I pushed it. If I had seen his posts in the "Ps3 hits 1 million mark" thread, I probably wouldn't have pushed it like I did (since those posts were a lot more level-headed). After his response to me, it seems like he definitely is a developer though... It wouldn't surprise me if he came from the PC world instead of the PS2 world though. I'm still in doubt about his 360 GPU always being superior claim (but if hes porting from 360, then it may not be so surprising). Would be interesting to see how a console with Cell and Xenos could have turned out though!

Someone should drag him over here.

almighty
27-Dec-2006, 18:13
Switch your PS3 game from FP16 to an 8/8/8/8 int format and see your framerate jump. Of course, you'll have to forgo HDR on your shipping title, but you can then do msaa. Or, go back to FP16 since HDR looks so cool, but oh ya, you then have to turn off msaa

He's a fool and has not got a clue, saying that because HDR is'nt calculated as an FP format its not HDR? :lol:

ShootMyMonkey
27-Dec-2006, 18:24
I'm with Acert; do we judge the message or the messenger around here? Whether or not this poster is in the industry... and he certainly seems to be IMO... I think his points should just be deconstucted as any other posters points would be.

There seems to be this strange mythos on the Internet that if a 'developer' says something, it somehow takes on the force of natural law. But we have many a dev here, do we not? And they disagree on points all the time.
Yeah, a lot of his points are more or less true, but the fatalism with which he mentions them seem to be based on the assumption that you can't do anything about it. I don't know if those assumptions are valid for his company's art pipeline, but most all of them can be circumvented in various ways. His concern over vertex attributes are very avoidable in various ways (many of which trade shader cycles for data, but since the shader instructions often don't cost you as much, it's often worth it). Where I am, our PS3 development is really not far enough along to say anything one way or another, but there are a lot of circumventions around data-moving limits which we do anyway and are a win on both platforms.

The guy who dominates that other thread (the CPU comparison thread) is clearly an armchair geek who thinks he knows a thing or two, but is really little more than a novice who's visited a few tech sites.

He's a fool and has not got a clue, saying that because HDR is'nt calculated as an FP format its not HDR?
Ummm... I think the point was more about native formats and what the hardware supports, and indeed 8:8:8:8 integer RGBA is not inherently HDR. Though I'm not sure why he's so hot on FP8... I would at least assume he meant FP10.

Acert93
27-Dec-2006, 18:51
He's a fool and has not got a clue, saying that because HDR is'nt calculated as an FP format its not HDR? :lol:

That isn't what he is saying. What he said, in context, was

1. Because it was a port, going with a new HDR technique (like a colorspace format) wouldn't work due to needing to be redesigned.

2. So they have to choose: FP16 based HDR effects which are slower from INT8, FP10, Colorspace (e.g. NOA32), and so forth. We know this, G70 with HDR enabled in games that use FP16 blending and filtering do take a performance hit. So there is a drop in framerate + they cannot use MSAA. Or they can use INT8, gain some framerate back (which seemed to be important to them due to some issues they had porting their Xenos VS code to RSX), and use MSAA for a cleaner image. So for their deadline and game design it was either FP16 and workout the framerate issues or INT8 with MSAA and alleviating some of their framerate issues.

Now, WHY they are having some of these issues is another story. Some of this is feature based. They are most likely using FP10 on the 360 and RSX just doesn't have a similar format. They may also have used some other features if the Xbox 360 was the lead SKU (probably not stuff like tesselation, streamout, heavy vertex texturing) but it wouldn't surprise me if they were using 3Dc for example for normals. There is always the possibility they are using fairly branchy pixel shaders or may have some heavy vertex work that may not port over well in a limited 2-4 month window; and he already noted the issues they had with the split memory pool.

So if they have a game design where they really wanted MSAA and HDR using a FP format, have tailored their assets for specific features that run a little better on Xenos, and didn't give much though to UMA vs. NUMA, and didn't leave time to resolve these issues during co-development (e.g. NOA32 for HDR, more prortable assets with alternate designs that accent RSX strengths, designed their engine to work equally well with a NUMA design and taking account for texturing from XDR, and so forth), then getting asked to solve ALL these problems during crunch to get performance up to snuff could be very frustrating.

It is no different than the first dev we hear frustrated and dissappointed that his sweet SPE algorhythm spanning 4 SPEs runs at like 20% on 2 Xenon cores, or a game using the PS3 as the lead platform with no/little thought to the 360, and then you try to port all your graphics assets, that may even be using some SPE libraries, and so forth.

One could conjure up many, many scenarios where one of the consoles as a lead platform does a port and where the lead consoles strength was also the design bottleneck, and how that could be a problem on the other console. And yet they are very similar in some ways. The easy solution is to cut/add features as necessary, cut down detail (i.e. cut texture reslution by 50%, so your 720x720 texture becomes 512x512, not a big loss; similarly your 200x200 cloth mesh becomes 141x141), and so forth. This is one of the issues of being 2nd to market: everyone is already full steam ahead building stuff for the other guy, but as development matures developers will do a better job tailoring dev cycles to account for these issues.

And even if joker is a joke, we can see that many Xbox to PS ports this fall did have some issues, especially with getting framerates up. Next fall? It could be reversed.

archie4oz
27-Dec-2006, 20:35
There is very few post about xenon here, but it seems not to be so closed of the ppe and there's few thread about it:
vmx128 units can prove to be powerfull 128 registers same speed as spe, some hardwired functions.

Not quite the same speed as SPEs. SPE's have much lower load latency.

p unit and vmx unit are decoupled they have their own "instruction queue" (can find the correct word) and can issue two instructions per cycle so at some point a xenon core can be 4 issues two from integer&branch units two from fp&vmx units.


AltiVec/VMX implementations have always been decoupled. The instruction queues you're referring to are really more like reservation stations. The PPE core is still basically still a dual issue processor, so you're only going to be issuing 2 instructions per clock max.

Kryton
27-Dec-2006, 21:09
Perhaps I'm being silly, but they mention HLSL being compiled to both architectures. Surely this is the simplest give-away, HLSL is for DirectX (360) not OpenGL (PS3)! This is continuously mentioned (compile and run) throughout the posts. It's just another Xbot

phat
28-Dec-2006, 04:15
Anyway... well I'm an AVS member myself but I've been too emotionally involved there of late to respond in that thread right now; I'm trying to scale back and detach myself from the BD/HD DVD war presently underway there, which is so much more over the top than even any gaming forum you've ever seen.

I have a hard time stomaching that place because of the really bizarre HD-DVD love-in they have going on over there... Trying to discuss fundamental technical issues like bitrate and capacity is an exercise in masochism. :)

(Sorry for being OT. Just had to vent a bit.)

Rangers
28-Dec-2006, 05:00
I have a hard time stomaching that place because of the really bizarre HD-DVD love-in they have going on over there... Trying to discuss fundamental technical issues like bitrate and capacity is an exercise in masochism. :)

(Sorry for being OT. Just had to vent a bit.)


Blu Ray supporter eh?

Acert93
28-Dec-2006, 05:11
Perhaps I'm being silly, but they mention HLSL being compiled to both architectures. Surely this is the simplest give-away, HLSL is for DirectX (360) not OpenGL (PS3)! This is continuously mentioned (compile and run) throughout the posts. It's just another Xbot

While there is PSGL, the high level shading language is NV's CG 1.5. Maybe a PS3 developer could clarify on the different approaches, but reading this PPT series from Cedric Perthuis (http://www.cg.tuwien.ac.at/events/EG06/gmgfiles/perthuis-talkeg2006.ppt#271,15,Shading language) makes mention of the CG version used for the PS3 which says, "CG... PS3 specific compiler... mostly compatible with other languages like HLSL". Without knowing the tools and middleware they are using it is hard to say, but it is likely they are using HLSL on the 360 and when they ported the title they took whatever steps necessary to move their shader code to CG. But I am not familiar with this process or the tools.

reltham
28-Dec-2006, 05:19
Perhaps I'm being silly, but they mention HLSL being compiled to both architectures. Surely this is the simplest give-away, HLSL is for DirectX (360) not OpenGL (PS3)! This is continuously mentioned (compile and run) throughout the posts. It's just another Xbot

The PS3 has CG, which is essentially identical to D3D's HLSL.

-tkf-
28-Dec-2006, 10:56
Blu Ray supporter eh?

HD-DVD supporter ehh?

Sorry, had to do it :-)

StefanS
28-Dec-2006, 10:57
HD-DVD supporter ehh?

Sorry, had to do it :-)

That was a joke Rangers made about the state of things at AV... :razz:

liolio
28-Dec-2006, 13:30
archie4oz, thanks for your enlightnings ;)

Graham
28-Dec-2006, 14:42
... In RSX's case you have no choice but to use FP16 (16/16/16/16), compared to FP8 on xenon. So you are forced to move ...


Is this correct?
AFAIK xenon does support FP16, but FP8?

And doesn't xenos only go down to FP10?

The quote would imply xenon is a typo, meant to be xenos?

Or is it too late and am I confused..?


[edit]
I am confused.. It is too late :P I didn't see the second page and Monkeys responce

joker454
28-Dec-2006, 22:36
Wow, this escalated fast. It's definitely exceeded my comfort zone though so I've used a new bogus email address to register here to make tracking me more difficult. I think I'm gonna stick to lurking from now on as I'd like to keep my job ;) But there's a few things that need to be cleared up. I'll try to keep it short, so I'm only quoting parts of peoples posts:

"He is complaining about doing extra work to get performance to match what can be obtained on another vendors hardware."

Not exactly. I prefer working with hardware that helps me, not hinders me. The more time I have to spend getting around hardware quirks/limitations means less time to add new cool features, and the longer it takes to get the game into your hands. There are some coders that love the challenge that quirky hardware poses. My preference though is to spend my time on making the best visuals and adding new features that were impossible on old gen.

"Complaining about having to pre-cull geometry on the SPU before sending to the GPU... The fact that the Cell is good at that should be listed as a strength, but he cites it as a weakness because he does not want to spend the effort to tap that performance."

Normally i would agree with you. In this case though it's not a strength, its a requirement because you have to do it to help the PS3 keep pace with the 360. Remember as well, we already lose one spu to redundency, and another to Sony. We're left with 6, but now we need to spend some of those to help the rsx. I'd far prefer using spu's for full cloth sim on all characters, collision code, animations, etc. I don't mind learning new hardware, me and others do it all the time.

"...would not be surprised if ppl working on 360 and suddenly dropping their datasets onto RSX would not observe good numbers (and viceversa)"

This is far more true going from 360->PS3 than the other way around, again assuming gpu to gpu only. The 360 isn't flawless to be sure. Having to tile because of the tiny amount of edram is a pain, and edram resolves while quick, can still add up (you don't need to resolve on PS3). Still though, I'm far more impressed with the 360's gpu and I'm comfortable saying that feeding an identical 3d scene to PS3 and 360 will result in better framerate on 360.

"Who’s to say he isn’t jaded by his own personal feeling about Sony or it’s hardware."

I have no allegiance to with Sony or Microsoft. In fact, the PS2 is my third favorite console of all time behind the NES and the 2600.

"That and difficulty tuning his code seem to have him bitter. "

Reading back my posts, I suppose I can see how I'd be viewed as being bitter. It's more a mixture of frustration and dissapointment I'd say. I'll never understand why Sony chose that particular rev of NVidia hardware.

"The PS3 makes me work hard... screw that!"

Heh, this one is slightly amusing. We work very hard I assure you ;) My preference is to work hard on stuff that makes the game pop, not spending tons of time just to get the machine to do the basics. That's my preference of course, we have people on staff that love the challenge of getting the PS3 to render as quick as the 360.

"But at the same time he treats the GPU as both the beggining and end of the graphics subsystem, where we know in PS3 the Cell is set to play an ever larger role as tme goes on."

That's part of the problem. I was hoping the gpu would handle itself like a modern gpu. Instead we have to use spu's to help it. The more spu's you have to use to help rsx, the less you have to spend on cool gameplay items like physics simulations.

"nyhow, I found many post by this guy (with the same residing area and screen name) asking some of the simplest questions on how to hook up his tivo to his TV. Or what’s the difference between optical audio cables and coax digital audio cable. To me even a guy with his background can figure that out by himself."

That's definitely not me. We've had tivo since 2000, and I have numerous components with either coax or optical digital out which I can hook up myself thanks ;) The 'joker454' username is not one i chose. I picked 'joker' which was taken, and 'joker454' was suggested by the auto name generator. I suspect there are other 'joker454's out there.

"What I responded to didn't really sound like something a dev would say and contained a lot of fishy information, so I pushed it."

Ya, my first few posts were kinda ******-ish, I probably shouldn't have done that ;) I leveled out my posts later.

"His concern over vertex attributes are very avoidable in various ways (many of which trade shader cycles for data, but since the shader instructions often don't cost you as much, it's often worth it)."

This only partly helps. It's true that in many cases is faster to just recalculate things in the vertex shader rather than passing precalculated data via vertex inputs. We already do this here and there, using PIX on a case by case basis on 360 to see where it makes sense, and likewise benchmarking PS3 to see how it likes it. But that only gets you so far. Bottom line, a next generation game uses lots of lookup maps for a variety of effects, which leads to lots of vertex inputs. Of course there are ways to simply this like packing your data, combining maps so some uv's can be tossed, etc. But you will still hit the vertex delays on rsx because some like 'position' and 'normal' are a must, so you don't have much room left to play with.

"Though I'm not sure why he's so hot on FP8... I would at least assume he meant FP10."

That's a typo on my part, 2/10/10/10 is the floating point format we need (FP10).

"There is always the possibility they are using fairly branchy pixel shaders or may have some heavy vertex work that may not port over well in a limited 2-4 month window"

Our shaders are very expensive. But then again, they look really good, and that's what nex gen is all about ;) We can optimize them some more (we have already), but optimized shaders would still run faster on 360. Porting is not so much the problem in this case as is the rsx's unwillingless to deal with verticies. If you read the rsx docs, they are pretty much saying "please, please, please don't send verticies to rsx". The whole reason for using spu's is to do backface culling on all your verts first, that way you can send a smaller subset of verts to the rsx to get around its limited vertex processing. The rsx can backface cull them itself of course, and this does cut out pixel shader computation, but it still must run thru the vertex shader, which means it still must incur the one cycle penalty per vert input which brings rsx to its knees.

In the end my beef is with the PS3 gpu which I still feel is disappointing compared to the 360's. I have no beef with Sony or the PS3 itself. To make a nex gen game that looks of gears of war quality needs three things. Great shaders, more geometry, and lots of lookup maps. RSX has a hard time with all of those. It seems like an odd choice to me to go head to head with 360.

"we can see that many Xbox to PS ports this fall did have some issues, especially with getting framerates up. Next fall? It could be reversed.

This may very well be true! We'll have to wait and see. Spu's will help, I'll know more once I code for them in the new year.

Bobbler
28-Dec-2006, 22:52
...

Welcome to the board. Enjoy!

Don't feel obligated to say anything that'll hurt your job, obviously, but input from different devs is always welcome. There's lots of devs that post and lurk here.

Tahir2
28-Dec-2006, 22:54
Most silly comments you can ignore joker. I hope to see your input a lot more in these forums.

22psi
28-Dec-2006, 23:08
welcome to the boards joker! thank you for replying in a sensible, intelligent and mature manner to some of those that were a bit hasty in their replies.

Rainbow Man
29-Dec-2006, 00:27
Wow.

80% of what you said Joker made very little sense to me but I'm still glad you came and posted.

I don'tt hink there's quite a board like tihs one on the web.. Welcome aboard from another 2600 fan! :cool:


Peace.

MBDF
29-Dec-2006, 00:48
nm.

Carl B
29-Dec-2006, 00:54
"But at the same time he treats the GPU as both the beggining and end of the graphics subsystem, where we know in PS3 the Cell is set to play an ever larger role as tme goes on."

That's part of the problem. I was hoping the gpu would handle itself like a modern gpu. Instead we have to use spu's to help it. The more spu's you have to use to help rsx, the less you have to spend on cool gameplay items like physics simulations.

Joker, first of all I'm glad you accepted my thread/forum invite. :)

Since this piece of text you responded to is my own, I'll respond only to this.

Firstly I understand your angle here. But from a practical standpoint, the RSX indeed does function like a modern GPU. It *is* a modern GPU. It is not Xenos, but then again Xenos is... ultra-modern? Not that it doesn't have it's own constraints, however. But I don't see the point in feeling 'disappointed' in Sony/NVidia in this regard. For better or for worse, it is simply the case that ATI and Microsoft had corporate strategies that more closely aligned to one another in their coalescing around the R500 project than Sony and NVidia did on their own end. ATI had already begun development on unified architectures, and for some effort customizing it to the world of consoles, MS was going to essentially fund a whole lot more.

Sony signed up for what at the time would have ideally been a chip to ship in March of '07; and that architecture was G71 derived. If they had an original timeframe of Fall '07 instead, maybe the RSX could ave been a little more exciting - who knows? But I don't think the lowered count to 6 SPEs should be a cause of concern for you; as the knowledge base expands, it should be more than enough for you to get your cloth sims in there and address any geometry shortfalls you may feel exist with RSX.

It's like you said; you haven't tried them out yet. Give 'em a shot next year and see how you like them. :cool:

Anyway, I wouldn't worry about losing your job for posting here... nobody else has! I think you'll find also that this is a more appropriate venue overall compared to AVS in which to have your ideas both challenged and applauded on their merits.

Carl B
29-Dec-2006, 02:30
Whatever, :roll:

We just haven't found a way to ruffle your feathers here! xbd in B3D level-headed...xbd in AVS, whoa nelly :razz:

*cough cough*

;) :razz:

ShootMyMonkey
29-Dec-2006, 02:31
This only partly helps. It's true that in many cases is faster to just recalculate things in the vertex shader rather than passing precalculated data via vertex inputs. We already do this here and there, using PIX on a case by case basis on 360 to see where it makes sense, and likewise benchmarking PS3 to see how it likes it. But that only gets you so far. Bottom line, a next generation game uses lots of lookup maps for a variety of effects, which leads to lots of vertex inputs. Of course there are ways to simply this like packing your data, combining maps so some uv's can be tossed, etc. But you will still hit the vertex delays on rsx because some like 'position' and 'normal' are a must, so you don't have much room left to play with.
Yeah, we ran into a few snags on this front when we considered shrinking or removing attributes. We tried dropping one of the basis vectors and recalculating it with a cross product in the shader -- unfortunately, that screws with you when artists start mirroring UVs and causes normal/parallax maps to flip at the seam, so that idea didn't last very long. Also tried determining various things offline to see what could be dropped from the vertex stream, but that really ballooned the build times.

We considered reducing the total number of UV channels coming into the vertex shaders, as well as double-packing them (two UV coords in each 4-vector, so you only use 1 attribute to get 2 UV coords)... that works out well for us, especially since 90% of our assets only uses 2 UV coordinate sets, all of which are 2d (even though having 10+ maps isn't out of the ordinary). Characters almost never have more than one. Things like layered blends were all done using different tiling factors on the same UVs. The real hit we take for these kinds of arrangements, though, is that a lot of materials carry a lot of constants with them. Still, while it sounds restrictive as opposed to "more maps = more UV sets", it also just so happens that there's no motivation to suggest we need to expand further.

In general, though, the things that help the most aren't so much data format, but really trimming what you send. Z-prepasses, software skinning/progressive meshes, etc. And this is all a win on the 360 as well, since the vertex throughput rate on the same geometry with Xenos is hardly all that impressive there either. I'm not about to say that the attribute read rate of RSX isn't among the crappiest hindrances to progress, but you make it sound like having to free-climb over the Great Wall of China.

Graham
29-Dec-2006, 02:47
Yeah, we ran into a few snags on this front when we considered shrinking or removing attributes. We tried dropping one of the basis vectors and recalculating it with a cross product in the shader -- unfortunately, that screws with you when artists start mirroring UVs and causes normal/parallax maps to flip at the seam, so that idea didn't last very long. Also tried determining various things offline to see what could be dropped from the vertex stream, but that really ballooned the build times.


wouldn't they flip anyway, if sharing the seam vertices?

were you doing:

binorm = cross(tangent.xyz,normal) * tangent.w; // where tangent.w is 1 or -1

?

ShootMyMonkey
29-Dec-2006, 03:23
wouldn't they flip anyway, if sharing the seam vertices?
Well, our exporters would make sure the seam vertices are duplicated when there's a flip like that or when using symmetry in modelling/texturing, so they don't really share the same verts per se. The mirrored UVs would mean that somewhere along the surface, the basis switches from right-handed to left-handed, but as long as you just let that happen and you duplicate the seam verts where the other copy has a different basis-space, things stay consistent appearance-wise.

In reality, we didn't run across that case as often as one might think (for instance, it would never happen on characters), but it did happen a fair bit on complex large pieces of architecture where various texture layers had different tiling factors.

binorm = cross(tangent.xyz,normal) * tangent.w; // where tangent.w is 1 or -1
Just the cross-product, actually. And yeah, if you were sharing verts, you would see a flip, or at least a kink right around the seam either way.

RobertR1
29-Dec-2006, 06:49
Joker,

Thanks for your very well written post. It is informative and not overly techincal so many can understand vs. just a few.

I think the RSX is being limited because it was not customized. It was an off the shelf product with minimal tweaks and was the best Nvidia was willing to do likely due to Sony's last min "oh crap, we need go out and buy a GPU." Wasn't the Cell all Sony needed at some point or they were going to design their own GPU of some sort before they went shopping for one? I believe reading something like that many moons ago.

Ati and MS however collaborated on a much deeper level and Xenos was produced. It probably doesn't hurt either that MS has the DirectX team behind them giving pointers.....

nAo
29-Dec-2006, 07:39
Yeah, we ran into a few snags on this front when we considered shrinking or removing attributes. We tried dropping one of the basis vectors and recalculating it with a cross product in the shader -- unfortunately, that screws with you when artists start mirroring UVs and causes normal/parallax maps to flip at the seam, so that idea didn't last very long.
This problem is easily fixable, just store an additional bit per vertex that let you reconstruct the original tangent basis vectors. In HS we store a bit like that in the most significant bit of the w component of our position vectors so that we to reconstruct binormals we do something like that:

float4 binormal = sign(position.w) * cross( normal, tangent );

very cheap and effective.


We considered reducing the total number of UV channels coming into the vertex shaders, as well as double-packing them (two UV coords in each 4-vector, so you only use 1 attribute to get 2 UV coords)... that works out well for us, especially since 90% of our assets only uses 2 UV coordinate sets, all of which are 2d (even though having 10+ maps isn't out of the ordinary).We do something like that either. Artists are free to use all the UV sets they want, then our shaders generator automatically detects how many unique UV sets are really needed and it packs them accordingly, in order to use less input attributes.
More clever optmizations could be done as well, as packing multiple UV coordinates per attribute components (the same trick could be also used to store your tangent+normal vectors in a single attribute at full precision) but we did not go that route cause our VS are so long and complex that in the end would have not made any difference (ie we are almost never attributes limited).
To speed up simple rendering passes as z pre passes or shadow map one just needs to split vertex data in at least 2 streams: one for position and the other one for all the rest..that way one can basicly achieve VS throughput wise some number pretty close to the theoretical capabilities of the chip.
So in the end I really don't understand all this complaining, it's not really that hard nor complex to overcome these 'problems'. ppl were complaining in the same way in the old PS2 days while on the PS2 you needed A LOT more work to make things work as expected and ppl did it anyway.

I'm not about to say that the attribute read rate of RSX isn't among the crappiest hindrances to progress, but you make it sound like having to free-climb over the Great Wall of China.Exactly. I was almost laughing at the GOW comment..I wonder what's so impressive in GOW that RSX could not do. At this time I really fail to see how 360 titles are so much better that PS3 titles graphics wise.. (while devs have more experience on the former platform..)
GPU wise I think 360 and PS3 have more or less the same power; once devs will start to use SPUs to speed up RSX things will start to be even more interesting (and a few titles are already doing that..)

"Nerve-Damage"
29-Dec-2006, 08:15
So in the end I really don't understand all this complaining, it's not really that hard nor complex to overcome these 'problems'. ppl were complaining in the same way in the old PS2 days while on the PS2 you needed A LOT more work to make things work as expected and ppl did it anyway.

Exactly!! :grin:


Exactly. I was almost laughing at the GOW comment..I wonder what's so impressive in GOW that RSX could not do. At this time I really fail to see how 360 titles are so much better that PS3 titles graphics wise.. (while devs have more experience on the former platform..)
GPU wise I think 360 and PS3 have more or less the same power; once devs will start to use SPUs to speed up RSX things will start to be even more interesting (and a few titles are already doing that..)

:cool:

Tap In
29-Dec-2006, 09:14
Wow, this escalated fast. It's definitely exceeded my comfort zone though so I've used a new bogus email address to register here to make tracking me more difficult.

<skip>

This may very well be true! We'll have to wait and see. Spu's will help, I'll know more once I code for them in the new year.

thanks for your perspective and welcome!

BTW Mods.... perhaps thread title change? :)

StefanS
29-Dec-2006, 12:10
BTW Mods.... perhaps thread title change? :)

:razz: Changed. Hopefully that fits better now.

Anyway, guys, leave the GeoW discussion outside, will ya. This is the technical part of the forums and -nomen est omen- it should be a more technical discussion.

Anyway, devs keep feeding us nice infos. :cool2: Anything else you found challenging, etc?

EDIT:
In case anyone is wondering what FKATCT means "formerly known as the Charlatan thread".

Oninotsume
29-Dec-2006, 12:11
I don't know what the situation is like abroad, but I work at a major Japanese publisher, and have friends also working at big name publishers throughout Japan, and NONE of them had PS3 devkits/tools anywhere near the same time as the 360. So, as far as the Japanese side is concerned there has/is a lot more further development going on on the 360 side.

In the end I don't really think it matters what game is using what type of work-around or hardware specific technology. If the game looks great to the player, and it's fun then it's a success.

I too was not totally blown away by Gears of War. Personally I think MotorStorm looks just as good, but that doesn't really matter because blowing guys away in Gears is just as fun as slamming a buggy into a cliff at 150mph!

blakjedi
29-Dec-2006, 18:33
I think joker explained himself completely and succintly in his post. And I find him to be honest especially as a MULTI-PLATFORM developer. Some of the comments since his response read kind of... strange.

Every dev has their own perspective... I find it interesting to see what comes across as lecturing from other folks who may/may not be devs or folks who may/may not be multi...

Can't we all just get along?

scificube
29-Dec-2006, 19:24
I think joker explained himself completely and succintly in his post. And I find him to be honest especially as a MULTI-PLATFORM developer. Some of the comments since his response read kind of... strange.

Every dev has their own perspective... I find it interesting to see what comes across as lecturing from other folks who may/may not be devs or folks who may/may not be multi...

Can't we all just get along?

This is a technology forum. No one has been mean spirited in this thread. Ideas are meant to be shared here and position are meant to explored for the merit.

However, if no one else will say it I will say that just because a developer works with one platform or another this does not invalidate their assertions or color them as biased. What is said here is validated or invalidated based on it's merit not by whether one is a PS3 dev or a X360 dev or a Wii dev or developes on multiple platforms. It simply is not fair to the individuals that post here to give what they say any less credence than anyone else based on the what platform they work with. If what is said is meritous this all that should matter here.

The opinions of multi-platform developers do not belong to placed on pedestal above others out of hand. It should not even matter what kind of developer you are beyond having a perched view one can share from that others do not. Even then what is given/posited is judged by it's merit. If a multi-platform handheld developers posits that global illumination is a snap on the handhelds...just being a multi-handheld developer does not lend anything to the validity of that claim.

This is technology forum. Ideas are meant to shared. Positions are meant to be challenged based on their merit alone.

Nothing personal to you blackjedi. I simply think people should be respected for what they say not who they do or do not work for.

Tap In
29-Dec-2006, 19:41
good points scificube (http://www.beyond3d.com/forum/member.php?u=5441) but it has been rare to hear from a dev that has any experience on both systems and is nice to hear a new perspective. I don't think one is valuing one over the other as much as pleased to see someone who can speak from experience on both.

I hope that continues and that joker can share some more (so long as nobody else tracks him down and tries to take him out) :wink:

ShootMyMonkey
29-Dec-2006, 19:43
More clever optmizations could be done as well, as packing multiple UV coordinates per attribute components (the same trick could be also used to store your tangent+normal vectors in a single attribute at full precision) but we did not go that route cause our VS are so long and complex that in the end would have not made any difference (ie we are almost never attributes limited).
We also have that reason for not going on with the sign-in-the-w component thing you mentioned and are still waiting out to see if we should pack tangent+normal in a single attribute*. The tools and the system we have in place for artists to modify pixel shaders with a graphical interface recently got in some features for them to be able to modify vertex shaders as well. Plus, there are still a number of vertex-level features which are planned, but yet to be written, so we don't know yet how complex vertex shaders will get or how much more we'll want to move out of vertex shaders and move into software. Plus, it also means that there may be cases where artists create vertex shader modifications which mean we can't get away with things like backface culling in software because we won't know which faces are backfacing until you get to the shader. I don't expect that but for a few predictable cases, many of which won't be subject to such scrutiny anyway. It's also generally harder for artists to start wrapping their heads around geometry modification.

As I said, we're not far enough along to decide anything with much certainty yet... especially not on the PS3.

* : I should add that the sign-in-the-w-component thing also would involve some changes to our exporters, which has a nice hefty task list lined up due to recent transitions from using MAX to Maya7, and now we're having to use Maya8 + ZBrush + Turtle... which is making life real hell.

joker454
29-Dec-2006, 20:03
So in the end I really don't understand all this complaining, it's not really that hard nor complex to overcome these 'problems'.

I think part of my point was missed. Sure, theres a million tricks out there, using the sign bit is nothing new. My beef is that you have to do this on PS3 just to help rsx keep pace, you have to baby it. We do these tricks anyways because in many cases they not only benefit PS3, they also benefit 360 so why wouldn't we use them? So, clever tricks alone won't get you to 360 frame rate because the 360 usually benefits from the same tricks as well. Hence why I was saying the only way I believe to get rsx to complete is to use spus to help it deal with its inadequacies.

I was almost laughing at the GOW comment..I wonder what's so impressive in GOW that RSX could not do.

Not sure why you'd laugh, its the most visually impressive console title to date. You need to play a few hours into it to see some of the best graphics though. Even if you assume that rsx by itself could do it, you then run into other PS3 limitations like less free memory available. Both boxes may have 512MB, but you have less to work with on PS3. Maybe only third parties like us are affected by this, but on our end the free memory difference is fairly large with 360 giving us lots more room to play. So, textures somewhere have to get cut down. This may be one of the reasons a common complaint on PS3 games is that "the textures up close are muddy", probably because they are cut down. For example, I'm guessing thats why the crowd in Fight Night looks all pixelated on PS3, but ok on 360. They may have run out of memory on PS3 and had to get memory from wherever they could.

Even barring that, you run into other PS3 limitations. A game like gears I don't believe will be doable in 1080p on either machine, I don't think they have the bandwidth for it. So you do it in 720p. But on 360, I can hardware scale it to 1080p free. You can't do this on PS3 because its 720-1080 hardware scaler is broken, so you'd have to scale it in software which takes up more of those precious cycles.

At this time I really fail to see how 360 titles are so much better that PS3 titles graphics wise.. (while devs have more experience on the former platform..)

Both gears of war and resistance fall of man are first generation titles for their respective developers. Both were in development for roughly the same amount of time. No knock to Insomniac, they are a top notch crew, but gears looks way better.

I think the 'more experience on the former platform' isn't a valid argument. 360 games have all mostly been old gen ports. In other words, all shaders had to be written from scratch, and all new game assets had to be made. That's what happened to us, most of the time was not spent having fun with the 360, it was spent scrambling to get everything re-written. PS3 games on the other hand have mostly been 360 ports. Huge difference! Devs were able to save tremendous amounts of time since the same shaders can be used (I'm simplifying here, but you get what I mean), and they were able to use the same art assets. There still is a bit of a time advantage for 360 devs, but it's no where near as huge as people make it out to be.

GPU wise I think 360 and PS3 have more or less the same power

I fully respect your opinion of course, although this is the first time I've heard a dev say that ;) And I'm even talking about old school programmers that hate Microsoft with a passion! Even they, privately, give the nod to 360 in graphics. Although they will usually immediately follow it up with a lengthy discussion of the joys of cell ;)

once devs will start to use SPUs to speed up RSX things will start to be even more interesting (and a few titles are already doing that..)

Yup, totally true. Although nothing stops you from doing the same on 360. If you have a free 360 hardware thread, why not use it to precull? I'm certainly gonna try. Sure, it's no where near as suited to the task as spu's, but since I've gotta write the code on PS3 anyways, I'm gonna try leveraging it on 360 on the geometry that would benefit the most, solid models like characters that are usually half backface culled anyways.

The spu's are certainly the PS3's ace, but I'm wondering, will they let that box eclipse 360 performance, or just match it? I don't really know the answer to this so we'll have to see.

Carl B
29-Dec-2006, 20:07
good points scificube (http://www.beyond3d.com/forum/member.php?u=5441) but it has been rare to hear from a dev that has any experience on both systems and is nice to hear a new perspective. I don't think one is valuing one over the other as much as pleased to see someone who can speak from experience on both.

I hope that continues and that joker can share some more (so long as nobody else tracks him down and tries to take him out) :wink:

Agreed, but remember that Joker doesn't have experience on both 'systems' yet as we might define them; his PS3/SPE coding will begin in the new year.

joker454
29-Dec-2006, 20:12
Agreed, but remember that Joker doesn't have experience on both 'systems' yet as we might define them; his PS3/SPE coding will begin in the new year.

Yes totally true. I'm certainly not the authority on console coding, I make mistakes here and there and I'm definitely still learning. That's the coolest part of being a games coder, you never really catch up because theres always something new to learn!

Likewise, being multi platform means I'll never be able to match what first parties can't do. Not because we don't do the same tricks (we do/will), but because our time is divided.

Shifty Geezer
29-Dec-2006, 20:17
However, if no one else will say it I will say that just because a developer works with one platform or another this does not invalidate their assertions or color them as biased.Indeed. Developers concentrating on a single system are likely to have a better understanding of how to do things on it, while those who are multiplatform are more likely to know the alternative system a bit better. With both perspectives, some good discussion could be got going.

almighty
29-Dec-2006, 20:52
Both gears of war and resistance fall of man are first generation titles for their respective developers. Both were in development for roughly the same amount of time. No knock to Insomniac, they are a top notch crew, but gears looks way better.

Unreal Engine 3 was first revealed in 2004, and even then it was looking extremely polished and complete. So Gears, if truth be known was in development for atleast 3+ years, how much better do you think Resistance would of looked if Insomniac spent 3 years on a game engine before they starting creating game assett's? ;)

Thats what annoys me when people compare PS3 game's to 360 one's that use UE3, UE3 is an extremely streamlined engine thats had years of work, 90% of PS3 launch game's use game engine's that id bet have'nt even had half of the time spent developing them as UE3.0 has.

jonabbey
29-Dec-2006, 21:02
Thats a good point, he does'nt start on PS3 till after the new year and yet he's got his head set on 360 >> PS3 :???:

I think that's unfair. His comments have not been ad-machina as much as listing issues that he's had problems with in his cross-platform development on PS3. Whether or not single-platform developers can do things differently to take advantage of the PS3's strengths and produce a superior game takes nothing away from his insights.

And I say this as a reasonably hopeless Sony ******.

Shezad
29-Dec-2006, 21:11
I'm also wondering if Joker's comments/evaluation on the PS3 are not rather immature, given that he has not yet become familiar with the platform yet.

Not Exactly, his comments are quite familiar inside the Ps3 development community.
I am a PS3 developer as well and unfortunately it is true that from a graphics point of view we need to help RSX with SPUs, and this means using CELL for something that the GPU should do.
In my very personal opinion, maybe worthless, the 360 GPU is better than RSX and Microsoft gave us better tools.

scificube
29-Dec-2006, 21:14
good points scificube (http://www.beyond3d.com/forum/member.php?u=5441) but it has been rare to hear from a dev that has any experience on both systems and is nice to hear a new perspective. I don't think one is valuing one over the other as much as pleased to see someone who can speak from experience on both.

I hope that continues and that joker can share some more (so long as nobody else tracks him down and tries to take him out) :wink:

I'm glad for any developer that wants to converse here. ;)

Sorry that page is gonna stay blank.

thatdude90210
29-Dec-2006, 21:52
Not Exactly, his comments are quite familiar inside the Ps3 development community.
I am a PS3 developer as well and unfortunately it is true that from a graphics point of view we need to help RSX with SPUs, and this means using CELL for something that the GPU should do.
In my very personal opinion, maybe worthless, the 360 GPU is better than RSX and Microsoft gave us better tools.
I'm wondering that given the timeframe of RSX, would R520 (obviously R580 was much later & G80 even later) have been any better? Just a theoretical question that if Sony had went to ATI instead of Nv for their graphic needs without regards for whether ATI even had the resource for another console.

Mythos
29-Dec-2006, 22:11
Not Exactly, his comments are quite familiar inside the Ps3 development community.
I am a PS3 developer as well and unfortunately it is true that from a graphics point of view we need to help RSX with SPUs, and this means using CELL for something that the GPU should do.
In my very personal opinion, maybe worthless, the 360 GPU is better than RSX and Microsoft gave us better tools.

Really....thatz lots of proof with just a stated oponoin (parroting joker)...care to elaborate?

Pugger
29-Dec-2006, 22:23
Lets be honest here the team nAo is working with will probably have more up to date tools and information from Sony and on a more regular basis than the 3rd party joker454 is working for. This doesn't for one minute undermine jokers viiew, it is just from a differnt prespective which nAo should have taken into account. Also nAo did you work on the 360 before moving to the PS3 as you seem to know a lot regarding development? On a personal level wherever the PS3 is going to end up on a graphical development level it seems quite obvious that 360 is going to rival it very strongly indeed and in somecases outdo it. For a machine released a year earlier (1.5 yrs in the UK) props must go to the design 360 team.

Geo
29-Dec-2006, 22:25
Sometimes I read these threads and get the feeling some people think its reasonable to expect that Sony or MS should have been able to produce a single console that had Cell, Xenos, BRD, HD DVD, 60 GB HD, HDMI, free online community, and cost $199 at release (including the 3-game AAA title bundle, of course). And, of course, that's *not* reasonable. Nor do devs, so far as I've ever heard, program for a component but rather a platform.

nAo
29-Dec-2006, 22:33
My beef is that you have to do this on PS3 just to help rsx keep pace, you have to baby it.
I could easily construct tons of cases where exactly the opposite is true (rsx would run way faster than xenos) and I would have still proved nothing.

We do these tricks anyways because in many cases they not only benefit PS3, they also benefit 360 so why wouldn't we use them?
Sometime tricks benefit both platforms, sometimes they help a platform and harm the other one.
to say "everything we do to make RSX run faster help Xenos as well (or the other way around)" is imo naive at best.. Even in this case I could make a couple of examples related to vertex streams attributes..unfortunately NDAs don't allow me to do that.


Not sure why you'd laugh, its the most visually impressive console title to date.
Well..yes and no.. given the amount of stuff they have on screen I'm not really impressed...but I can see how very big normal maps can impress a lot of ppl :)

Even barring that, you run into other PS3 limitations. A game like gears I don't believe will be doable in 1080p on either machine, I don't think they have the bandwidth for it. So you do it in 720p. But on 360, I can hardware scale it to 1080p free. You can't do this on PS3 because its 720-1080 hardware scaler is broken, so you'd have to scale it in software which takes up more of those precious cycles.
I really cant find any logic in this argument. Why do you think that GOW would be bw limited at 1080p more than it's at 720p?



Both gears of war and resistance fall of man are first generation titles for their respective developers. Both were in development for roughly the same amount of time. No knock to Insomniac, they are a top notch crew, but gears looks way better.
Yes, GOW is prettier..so what?





I fully respect your opinion of course, although this is the first time I've heard a dev say that ;)
Maybe you should check the internal ps3 devs forum more often than, you're not the only one that have worked on both platforms and you might be able to find ppl that agree with you and ppl that don't agree with you at all and that have the opposite experience.
I'm not really suprised by that cause every team has different engines..with different requirements..something that runs good on RSX can run not so good on 360.
Generalizing is not particularly smart..

And I'm even talking about old school programmers that hate Microsoft with a passion! Even they, privately, give the nod to 360 in graphics. Although they will usually immediately follow it up with a lengthy discussion of the joys of cell ;)


The spu's are certainly the PS3's ace, but I'm wondering, will they let that box eclipse 360 performance, or just match it? I don't really know the answer to this so we'll have to see.
?! PS3 is already matching 360 now, with (probably) inferior tools and less experience on the system wrt 360, it can only get vastly better, no doubt about it. Non multiplatform titles are going to show this quite soon imho ;)

Tap In
29-Dec-2006, 22:59
I could easily construct tons of cases where exactly the opposite is true (rsx would run way faster than xenos)

just curious nAo.... have you coded for Xenos (360)?

thanks!

onanie
29-Dec-2006, 23:09
just curious nAo.... have you coded for Xenos (360)?

thanks!

ad hominem attacks aside, I think nAo is at least speaking generally about the fact that anyone could also concoct as many examples that could run badly on xenos as there are for PS3. The author could have used half of the truth to say that xenos is more powerful than RSX.

MasterDisaster
29-Dec-2006, 23:18
just curious nAo.... have you coded for Xenos (360)?

thanks!

same curiosity for me
I just believe mostly to a multiplatform dev than a platform-bounded dev when it came to a comparison between the good and the bad of the two systems
I hope to see here more persons that have really worked with xenos and xenos, in order to have some right informations about this hardware.

Tap In
29-Dec-2006, 23:22
ad hominem attacks aside, I think nAo is at least speaking generally about the fact that anyone could also concoct as many examples that could run badly on xenos as there are for PS3. The author could have used half of the truth to say that xenos is more powerful than RSX.

not sure what that has to do with my question to nAo

Fu3lFr3nzy
29-Dec-2006, 23:31
I hope to see here more persons that have really worked with xenos and xenos, in order to have some right informations about this hardware.

Did you mean Xenos and RSX perhaps? :wink:

Shezad
29-Dec-2006, 23:46
Did you mean Xenos and RSX perhaps? :wink:

Quite difficult to speak about Xenos and RSX without breaking NDAs :(

Mythos
30-Dec-2006, 00:12
same curiosity for me
I just believe mostly to a multiplatform dev than a platform-bounded dev when it came to a comparison between the good and the bad of the two systems
I hope to see here more persons that have really worked with xenos and xenos, in order to have some right informations about this hardware.

Nonetheless there is biases and platform of choice (F@#boies exist for developers as well)! I'd be more interested to hear an in depth developer nuetral assesment of both platforms (seems to be a very diffucult task at hand).

ShootMyMonkey
30-Dec-2006, 00:17
My beef is that you have to do this on PS3 just to help rsx keep pace, you have to baby it.
Well, that's probably true if you're vertex-limited in some way, whether it be attributes or shader instructions or something similar. Well, I don't know anything about your game(s) or what you're working on to say anything for sure, but that is definitely not a boat you want to be in regardless of your platform. Since I'm having to worry not only about Xenon and PS3, but also PC, it's generally the case that all our assets are going to be somewhat sparing on the vertex count. Plus, we have artists who understand the concept of constructing geometry that has very low vertex:tri ratios. As long as we can keep things sitting in the post-transform cache as long as possible, GPUs smile at us.

to say "everything we do to make RSX run faster help Xenos as well (or the other way around)" is imo naive at best..
Unless "we" means "we, in particular"...

Well..yes and no.. given the amount of stuff they have on screen I'm not really impressed...but I can see how very big normal maps can impress a lot of ppl
More than anything else, Gears was a victory of artwork. Technology-wise, it's not doing anything super-special even if their way about it might be unique. The thing is that to say it was mainly about artists and design and stylistic consistency suggests to the average person that any team could have done it (which in fact is true), but the fact that there isn't another Gears of War out there right now tells them "it's all about something unique to UE3."

I fully respect your opinion of course, although this is the first time I've heard a dev say that And I'm even talking about old school programmers that hate Microsoft with a passion! Even they, privately, give the nod to 360 in graphics. Although they will usually immediately follow it up with a lengthy discussion of the joys of cell
Really? I can't say nAo's sentiments on that are all too unique. Usually, when I say something to that effect though, I mean it in a negative light -- i.e. they both suck equally bad. For all you could say about RSX's vertex throughput limitations, I can't tell you that Xenos is out of this world. Just easier to run with out-of-the-box.

Tap In
30-Dec-2006, 00:47
For all you could say about RSX's vertex throughput limitations, I can't tell you that Xenos is out of this world. Just easier to run with out-of-the-box.

thanks for your perspective.

I don't understand why some appear upset that Joker has said that RSX is vertex limited. Did they not expect some trade offs compared to Xenos?

People have been mentioning here for a year that cell would be helping RSX. Only now when we can compare systems based on designing for multiplat games do we find that it needs to help RSX to equal Xenos in some areas. That reduces some of what Cell can do in other areas, but MS made similar trade offs when they invested heavily in making Xenos powerful (easier?) but do not have a beast like Cell in their system.


geo Sometimes I read these threads and get the feeling some people think its reasonable to expect that Sony or MS should have been able to produce a single console that had Cell, Xenos, BRD, HD DVD, 60 GB HD, HDMI, free online community, and cost $199 at release (including the 3-game AAA title bundle, of course). And, of course, that's *not* reasonable. Nor do devs, so far as I've ever heard, program for a component but rather a platform.exactly.... trade offs.

joker454
30-Dec-2006, 01:12
I could easily construct tons of cases where exactly the opposite is true (rsx would run way faster than xenos) and I would have still proved nothing.

I think we agree to disagree on this.

Well..yes and no.. given the amount of stuff they have on screen I'm not really impressed...but I can see how very big normal maps can impress a lot of ppl :)

C'mon, you know there's way more to it than that.

I really cant find any logic in this argument. Why do you think that GOW would be bw limited at 1080p more than it's at 720p?

Both boxes have limited fillrate. Games that have alot of overdraw will falter at 1080p because both machines can only draw so much. This may not affect driving games very much where the only transparencies are some dirt being kicked up, but in games with lots of explosions you will take a framerate hit at 1080p. This is very easy to test on PS3. When you build your test disk, just select 1080p and compare it to your framerate at 720p. On our game the framerate is staggeringly different, it's unplayable at 1080p. Incidentally this brings out one of the plusses of the rsx, targeting 1080p or 720p is trivial, its just a checkbox away. You have to tile on 360 to use 1080p which blows.

Yes, GOW is prettier..so what?

How can you match it on PS3 when you have less available memory to work with? You can argue vertex tricks here, packing tricks there. But when it comes to memory, the only choice is to start half sizing textures. Further, the 360 is more flexible when it comes to texture formats. For example, we can use compressed normal maps on 360 to save even more memory, we can't do this on PS3. Much of our time was spent just getting the game to fit in PS3's available memory. You can use DXT1 or DXT5, but only DXT1 stays compressed in the PS3's texture cache so using DXT5 incurs a performance hit. Further yet, on 360 because its shader units are unified, we can allocate more to pixel processing or vertex processing if we're more performance heavy on one or the other. No such option on PS3 because its shader units are fixed. I'm sure you can argue that there exists trick x, y and z to get around some of these issues. But on 360, we can use tricks *and* leverage the natural advantage that its gpu gives us.

Maybe you should check the internal ps3 devs forum more often than, you're not the only one that have worked on both platforms and you might be able to find ppl that agree with you and ppl that don't agree with you at all and that have the opposite experience.
I'm not really suprised by that cause every team has different engines..with different requirements..something that runs good on RSX can run not so good on 360.
Generalizing is not particularly smart..

This may be true. I have yet to meet one though, maybe I've just been unlucky ;)

?! PS3 is already matching 360 now, with (probably) inferior tools and less experience on the system wrt 360, it can only get vastly better, no doubt about it. Non multiplatform titles are going to show this quite soon imho ;)

I fully agree....the dev tools on 360 are miles ahead of the tools on PS3. I definitely disagree that PS3 is matching 360 now. I honestly don't see this at all, and judging from side to side comparisons, neither do others. Am I wrong on this? I'll let others chime in with their opinions. 360 will get much better as well. You'd be surprised how few games are actually using all 6 hardware threads on 360.

Carl B
30-Dec-2006, 01:16
I'll let others chime in with their opinions.

I'm going to add to this... that let's let others chime in with their educated opinions. There's already some tension starting to enter the thread; let's all try to keep it civil and on-topic.

(Joker though I'm quoting you to post that, understand that it wasn't directed at you.)

nelg
30-Dec-2006, 01:51
Further yet, on 360 because its shader units are unified, we can allocate more to pixel processing or vertex processing if we're more performance heavy on one or the other. No such option on PS3 because its shader units are fixed.

So you are foregoing automatic load balancing?
How much improvement are you getting?

Fox5
30-Dec-2006, 02:03
Just wondering, how does Cell stand to help RSX? What does it add to the graphics? More polygons? Is PS3 going to be another PS2 style console (but to a far lesser extent), inferior textures but particles and polys up the wazoo?

ShootMyMonkey
30-Dec-2006, 02:09
How can you match it on PS3 when you have less available memory to work with? You can argue vertex tricks here, packing tricks there. But when it comes to memory, the only choice is to start half sizing textures.
Mmmm... you've got two pools of memory from which to texture if you really need the space -- and you get extra texture bandwidth out of it to boot. On top of that, there are a million and one ways to get much higher *effective* resolution than Gears of War exhibits while still using less texture memory and less *physical* texture resolution. Our artists have gotten really smart when it comes to these kinds of games, and they do a decent job of it on characters, but an even better job in general on environments.

I think the nature of the fact that modern graphics demands the creation of textures that aren't just about appearances but also about parameters for larger computations means that artists need to be more technically inclined than they used to be a few years ago. When they are, it turns out to be a very good thing.

Further, the 360 is more flexible when it comes to texture formats. For example, we can use compressed normal maps on 360 to save even more memory, we can't do this on PS3.
While the 360 is definitely more flexible in its texture formats, I don't see how DXN saves "even more" memory. Who says you can't drop components and just use DXT#? It does work pretty well, FWIW.

Further yet, on 360 because its shader units are unified, we can allocate more to pixel processing or vertex processing if we're more performance heavy on one or the other. No such option on PS3 because its shader units are fixed.
Again, pointing more to the same vertex throughput issues. If you're pixel-shader limited on RSX, you'll very likely be even more so on Xenos. And yeah, I know you don't like the idea of having to do something differently because of a specific platform's specific strengths and weaknesses, but at the same time, you're working at a multi-platform developer. There will never be a day in your life where you won't suffer this kind of trouble. It doesn't matter if it's this generation or 4 console generations from now, assuming you're still at a multi-platform dev house through all that time.

360 will get much better as well. You'd be surprised how few games are actually using all 6 hardware threads on 360.
Actually, I'd be more surprised if you could name that many games that DO consistently use all 6 hardware threads. All the same that I'd be surprised if you could name all too many games that consistently use all the SPEs (likewise to XeCPU's threads, I mean using in a non-superficial way) you've got on PS3. It's safe to say that we're hardly anywhere with any of the platforms (including Wii). I just hate the smorgasbords of stupidity that come about when companies put out press that "we're only using 20% of the PS3's power" and the obsequious dunderheads on forums everywhere scream that the graphics will be 5x better by the time PS4 comes out...

3dcgi
30-Dec-2006, 03:54
Lets be honest here the team nAo is working with will probably have more up to date tools and information from Sony and on a more regular basis than the 3rd party joker454 is working for. This doesn't for one minute undermine jokers viiew, it is just from a differnt prespective which nAo should have taken into account. Also nAo did you work on the 360 before moving to the PS3 as you seem to know a lot regarding development? On a personal level wherever the PS3 is going to end up on a graphical development level it seems quite obvious that 360 is going to rival it very strongly indeed and in somecases outdo it. For a machine released a year earlier (1.5 yrs in the UK) props must go to the design 360 team.
I would hope Sony provides all developers with the same information and tools. If they don't they are doing a disservice to themselves.

3dcgi
30-Dec-2006, 03:56
So you are foregoing automatic load balancing?
How much improvement are you getting?
I expect games to always use automatic load balancing, but they will nudge the chip in one direction. I'm not sure if Microsoft has exposed a way to forego automatic load balancing completely.

3dcgi
30-Dec-2006, 03:57
If you're pixel-shader limited on RSX, you'll very likely be even more so on Xenos.
Can you give any details on why this might be the case? Tests? Or are you considering the "24" pixel ALUs of RSX to be superior to the 48 ALUs (minus a few for VS work) in Xenos?

Dr. Nick
30-Dec-2006, 04:16
Can you give any details on why this might be the case? Tests? Or are you considering the "24" pixel ALUs of RSX to be superior to the 48 ALUs (minus a few for VS work) in Xenos?
I would like ask if any the devs have seen instances in a game that the Xenos has used all of it's SIMD units for pixel work at any given clock? Same question for vertex work.

scificube
30-Dec-2006, 04:34
Can you give any details on why this might be the case? Tests? Or are you considering the "24" pixel ALUs of RSX to be superior to the 48 ALUs (minus a few for VS work) in Xenos?

24 fragment processors - 2 ALUs per fragment processor. (ignoring mini and fog alu)
dedicated to fragment processing and texturing.

TurnDragoZeroV2G
30-Dec-2006, 04:38
Can you give any details on why this might be the case? Tests? Or are you considering the "24" pixel ALUs of RSX to be superior to the 48 ALUs (minus a few for VS work) in Xenos?

Perhaps more the pitfall of having a 1:3 TMU:ALU ratio at present?

scificube
30-Dec-2006, 04:52
Perhaps more the pitfall of having a 1:3 TMU:ALU ratio at present?

But the TMUs are decoupled completely so as to reduce dependencies in the pixel shader no? If there is so much texture sampling/lookups that the TMUs can't keep pace then you're texture bound. Maybe I'm off but what I gather is that ShootMyMonkey was speaking to being limited on fragment throughput more so than texturing operations.

If I misunderstand ShootMyMonkey is of course free to correct me.

TurnDragoZeroV2G
30-Dec-2006, 05:17
But the TMUs are decoupled completely so as to reduce dependencies in the pixel shader no? If there is so much texture sampling/lookups that the TMUs can't keep pace then you're texture bound. Maybe I'm off but what I gather is that ShootMyMonkey was speaking to being limited on fragment throughput more so than texturing operations.

If I misunderstand ShootMyMonkey is of course free to correct me.

What do you consider to be the basis of fragment throughput, then?

Edit: To not just sit here adding noise to the thread (or attempt avoiding it, at least):

Can one really separate texture sampling, or any of the other fixed function/programmable sections of the "pipeline" from fragment processing? Texturing is one of the primary means of reading data into the fragment processing pipeline, the ALUs being the primary means of manipulating those data.

I can't presume to know specifically to what SMM was referring, hence my (needless) blurb of a comment. However, it's not a simple case of "oh, you're texture limited"--to then be passed off so easily. We've seen the heavy math:tex ratio of Fran's postprocessing shader as compared to what may be more standard on PS3 or a PC GPU. Amongst the numerous performance presentations by MS are notes regarding how you handle texture fetches (i.e, when and where they're called for, balancing out with register usage), packing in more math, etc. There were several events, and Jawed had a few posts IIRC. It's probably not an ideal scenario, and one probably has to either cater to one and suffer performance penalties on the other (both ways! Texture fetch-related penalties on Xenos and a wasting of texture fetches on RSX), sit your shader somewhere in the middle and not extract everything from either one, or tailor the shaders to each GPU.

But, as you said, if the developers haven't already become completely sick of this thread, they'll (hopefully) correct any/everything there.

joker454
30-Dec-2006, 05:44
I expect games to always use automatic load balancing, but they will nudge the chip in one direction. I'm not sure if Microsoft has exposed a way to forego automatic load balancing completely.

This is a more accurate way to word it. We get very limited control, but we can nudge it either way. The PIX gpu tool lets you know which way to nudge it, and even gives you a % estimate of speed improvement. In our case we did nudge it and did see an improvement, but I won't get into specifics. PIX is quite a marvelous tool indeed. A similar tool is being written for PS3 but we don't have our hands on it yet.

pakotlar
30-Dec-2006, 05:49
I could easily construct tons of cases where exactly the opposite is true (rsx would run way faster than xenos) and I would have still proved nothing.

Sometime tricks benefit both platforms, sometimes they help a platform and harm the other one.
to say "everything we do to make RSX run faster help Xenos as well (or the other way around)" is imo naive at best.. Even in this case I could make a couple of examples related to vertex streams attributes..unfortunately NDAs don't allow me to do that.


Well..yes and no.. given the amount of stuff they have on screen I'm not really impressed...but I can see how very big normal maps can impress a lot of ppl :)

I really cant find any logic in this argument. Why do you think that GOW would be bw limited at 1080p more than it's at 720p?



Yes, GOW is prettier..so what?





Maybe you should check the internal ps3 devs forum more often than, you're not the only one that have worked on both platforms and you might be able to find ppl that agree with you and ppl that don't agree with you at all and that have the opposite experience.
I'm not really suprised by that cause every team has different engines..with different requirements..something that runs good on RSX can run not so good on 360.
Generalizing is not particularly smart..

And I'm even talking about old school programmers that hate Microsoft with a passion! Even they, privately, give the nod to 360 in graphics. Although they will usually immediately follow it up with a lengthy discussion of the joys of cell ;)


?! PS3 is already matching 360 now, with (probably) inferior tools and less experience on the system wrt 360, it can only get vastly better, no doubt about it. Non multiplatform titles are going to show this quite soon imho ;)

No offense nAo, but don't you seem to be a tad too enthusiastic about the PS3? I know you have more experience developing with the system, but comparing what joker and other devs have been saying, your posts read as if PS3 has no weaknesses compared to Xbox360 in the graphics dep. Obviously that is not true, but you put a lot of effort into denying any sort of possibility of the inferiority of your system. It reads slightly like f@nboyism. I'm not saying that you aren't impartial, but is there anything that sticks out as a sore thumb on the PS3?

joker454
30-Dec-2006, 05:53
Just wondering, how does Cell stand to help RSX? What does it add to the graphics? More polygons? Is PS3 going to be another PS2 style console (but to a far lesser extent), inferior textures but particles and polys up the wazoo?

Here's a quick way to explain it. A 3d scene may have 1 million+ verticies in it and the 3d hardware normally processes them all. Thing is, often a huge chunk of those aren't really needed because they are occluded, facing away from the camera, etc. In PS3's case, the spu's in Cell are actually very well suited to looking at the verticies of a scene and throwing away those that aren't really needed. So, Cell basically helps rsx by reducing its workload.

rounin
30-Dec-2006, 05:55
No offense nAo, but don't you seem to be a tad too enthusiastic about the PS3? I know you have more experience developing with the system, but comparing what joker and other devs have been saying, your posts read as if PS3 has no weaknesses compared to Xbox360 in the graphics dep. Obviously that is not true, but you put a lot of effort into denying any sort of possibility of the inferiority of your system. It reads slightly like f@nboyism. I'm not saying that you aren't impartial, but is there anything that sticks out as a sore thumb on the PS3?

Sounds rather unfair, as the some "weaknesses" of the PS3 have been discussed quite thoroughly (over and over as well...we see it in this thread as well) whereas I can't recall the last time somebody mentioned that of the Xbox360 (nor any details either for that matter). Info on CELL is much more available than for the xbox360's CPU, and as a result, nobody knows how they compare, and likewise for the GPU, where RSX is often comparable to a commercial part. I think nAo offers balance in light of this.

In addition, who are these "other devs", and what credibility to they offer over nAo? For the most part, I think devs, especially, those with more even experience in both machines (or in general?), are usually not the ones to point out advantage in either machine...

pakotlar
30-Dec-2006, 05:58
I fully agree....the dev tools on 360 are miles ahead of the tools on PS3. I definitely disagree that PS3 is matching 360 now. I honestly don't see this at all, and judging from side to side comparisons, neither do others. Am I wrong on this? I'll let others chime in with their opinions. 360 will get much better as well. You'd be surprised how few games are actually using all 6 hardware threads on 360.

Judging by what others have been saying about multiplatform games, what you are saying is definetely not unique. Even games like FN3, which spent a long time in PS3 (~ 9 month longer dev time?) centric development, came out looking worse overall than their Xbox360 equiv. Edit: Many multiplatform game looks better on Xbox360. Yes one could argue that it was a difference in development time, but the point is that at this point most games out on X360 perform better and/or have more complex assets (maybe excluding Ridge Racer 7) than the same games (or increase quality in one area at the expense of another ala FN3) on PS3. And PS3 devs have, for all intents, had similar time to develop those games.

I don't know why nAo is implying that this isn't the case.

pakotlar
30-Dec-2006, 06:03
Sounds rather unfair, as the some "weaknesses" of the PS3 have been discussed quite thoroughly (over and over as well...we see it in this thread as well) whereas I can't recall the last time somebody mentioned that of the Xbox360 (nor any details either for that matter). Info on CELL is much more available than for the xbox360's CPU, and as a result, nobody knows how they compare, and likewise for the GPU, where RSX is often comparable to a commercial part. I think nAo offers balance in light of this.

In addition, who are these "other devs", and what credibility to they offer over nAo? For the most part, I think devs, especially, those with more even experience in both machines (or in general?), are usually not the ones to point out advantage in either machine...

These "other devs" are from major studios that have just as much credibility as nAo. Google is your friend in this regard; i'm not going to data mine for you. I believe many of us have read comments from devs other than nAo and joker, and the general sentiment seems to be that X360 may have a better GPU (tho not in all cases) and PS3 has a better CPU (tho again not in all cases; for example Assasin's Creed Dev team said AI code is faster on X360).

As far as info on Cell vs info on X360, I'm not sure why that was brought up, but I believe that the public info out there is pretty indepth for both systems. And X360 weaknesses have been brought up many times in these forums and in others (in fact probably more than PS3's, as up till launch people assumed that PS3 would win or tie in all catagories).

Again, I'm not attacking nAo, I'm just trying to figure out why his word is final in these matters. He has produced a great looking game, but not only is that game (as far as we have seen in previews) not head and shoulders (that point is arguable, some may find it to be better looking others worse, as compared to x360 games) above x360's best, he has only developed on the one platform.

dantruon
30-Dec-2006, 06:05
I don't know why nAo is implying that this isn't the case.

because he developed game for the PS3 and he KNOWS the in and out of the system more comprehensively compared to the other developers.

rounin
30-Dec-2006, 06:08
These "other devs" are from major studios that have just as much credibility as nAo. Google is your friend in this regard; i'm not going to data mine for you. I believe many of us have read comments from devs other than nAo and joker, and the general sentiment seems to be that X360 may have a better GPU (tho not in all cases) and PS3 has a better CPU (tho again not in all cases; for example Assasin's Creed Dev team said AI code is faster on X360).

I was purely speaking on what I've read on Beyond3D, and on sites that have been posted here. Feel free to post some of your data mined devs because I'm sure theres people apart from me who would appreciate it. Helios, deanA,DeanOC, Vyzec, nAo, and the other devs whom I forget to name are the ones I was referring to as B3D people who seem to be neutral in discussing GPU merits. In terms of on the net interviews, I'm not sure if theres any one side being leaned on.

As far as info on Cell vs info on X360, I'm not sure why that was brought up, but I believe that the public info out there is pretty indepth for both systems. And X360 weaknesses have been brought up many times in these forums and in others (in fact probably more than PS3's, as up till launch people assumed that PS3 would win or tie in all catagories).

I brought that up because I feel nAo is offering insight on how a piece of equipment that at least been partially released to the public, benches against, for all most people know, a paper tiger for which we have the released specs and fullstop. I trust that many of us believe relatively speaking, info on X360 is much scarcer than that of CELL and RSX. For instance, who has benched the CPU on a X360 and has posted on it. This is not really something that needs debate.

pakotlar
30-Dec-2006, 06:13
I was purely speaking on what I've read on Beyond3D, and on sites that have been posted here. Feel free to post some of your data mined devs because I'm sure theres people apart from me who would appreciate it. Helios, deanA,DeanOC, Vyzec, nAo, and the other devs whom I forget to name are the ones I was referring to as B3D people who seem to be neutral in discussing GPU merits. In terms of on the net interviews, I'm not sure if theres any one side being leaned on.



I brought that up because I feel nAo is offering insight on how a piece of equipment that at least been partially released to the public, benches against, for all most people know, a paper tiger for which we have the released specs and fullstop. I trust that many of us believe relatively speaking, info on X360 is much scarcer than that of CELL and RSX. For instance, who has benched the CPU on a X360 and has posted on it. This is not really something that needs debate.

X360 benchies are not available, that is true. As far as deanA,OC, and nAo, don't they all work together on the same team producing the same game on PS3? I'm not saying that invalidates their opinions, and certainly they can provide great insight to PS3's relative strength, but when it comes to a comparison between the two systems, I don't think their opinions are the only ones we should consider. That's all :)

rounin
30-Dec-2006, 06:13
X360 benchies are not available, that is true. As far as deanA,OC, and nAo, don't they all work together on the same team producing the same game on PS3? I'm not saying that invalidates their opinions, and certainly they can provide great insight to PS3's relative strength, but when it comes to a comparison between the two systems, I don't think their opinions are the only ones we should consider. That's all

Of course, which is why I mentioned other devs.

Fox5
30-Dec-2006, 06:13
Here's a quick way to explain it. A 3d scene may have 1 million+ verticies in it and the 3d hardware normally processes them all. Thing is, often a huge chunk of those aren't really needed because they are occluded, facing away from the camera, etc. In PS3's case, the spu's in Cell are actually very well suited to looking at the verticies of a scene and throwing away those that aren't really needed. So, Cell basically helps rsx by reducing its workload.

How many games are vertex limited though? I thought games were generally TMU limited or shader limited? Or would throwing away unneeded vertices also reduce what needs to be shaded/textured?

because he developed game for the PS3 and he KNOWS the in and out of the system more comprehensively compared to the other developers.

He's a first (or 2nd?) party dev right? So he's probably put considerably more work into the PS3 than other devs and knows its ins and outs much better. However, I don't think you could say the same about his 360 knowledge. He may be able to debunk what other devs say about ps3 (saying you can't get good performance for something when there is in fact a way), but is he more qualified than a multiplatform dev in saying that 360 can or can't do something better than ps3? That said, I think he's been cautious on his 360 statements and left them as possibilities (ie: there's some type of code that the 360 will run like crap but the ps3 will handle better) rather than a specific example (ie: 360 can't handle as many pixel shaders at once as ps3).

pakotlar
30-Dec-2006, 06:16
edit:

Of course, which is why I mentioned other devs.

Dude I think you are just trying to argue for argument sake. Other devs have talked about both systems, and joker's sentiments have been reflected. Aka, Xenos has some benefits over RSX, unified architecture is nicer, x360 has more available ram, xenos can deal with vertex loads better. A dev doesn't have to post in b3d forums to be reliable (aka many have come out both officially and anon. saying these things), and no one would argue otherwise.

edit2: On the other hand so have a lot of nAo's remarks about PS3. I'm just trying to bring up the possibility that nAo's opinion on the x360 is not completely impartial. Some of his comments about X360 and GOW give me the ol' competition between studios vibe :D. Not saying he isn't a very talented PS3 developer. And I'm certainly not trying to argue that the PS3 is a bad piece of kit. The question is how good is it compared to its main competitor and why.

joker454
30-Dec-2006, 06:19
Mmmm... you've got two pools of memory from which to texture...

We've gotten around the split memory issue, but in our case we're seeing far less memory free in general. Out of the entire 512mb in each machine, both Sony and Microsoft reserve some for assorted reasons. We have somewhat more free memory on 360 for some reason. Maybe this is just due to the sdk's we're currently using, I'm not sure. Whatever the case may be, we maxed out memory on 360 so that left us scrambling for ways to free memory to get it to fit on PS3. Do you guys see this? I've always been curious if its just us that's seeing less free memory on PS3.

If you're pixel-shader limited on RSX, you'll very likely be even more so on Xenos.

This one interested me because we're actually seing the opposite. We actually had a very specific case to deal with where a cutscene was running slower on PS3 and we tracked it down to being pixel shader bound. It was using a 'crazy expensive' pixel shader which stressed even the 360, but it was able to maintain 30fps. Hard to say for sure why we're see different results though.

Actually, I'd be more surprised if you could name that many games that DO consistently use all 6 hardware threads.

We do ;) Although we are definitely not using them as effectively as we could. We're only using 1 spu at the moment as well. Shamefull, I know ;( But, I plan to devote a chunk of 2007 to making better use of threads on both PS3 and 360. My current thought is to make numerous 'threadlets', each being an extremely simple process that has one specific purpose, and snoozes and waits to be fed data for processing. We'll definitly be making full use of the spu's in '07.

joker454
30-Dec-2006, 06:31
I would hope Sony provides all developers with the same information and tools. If they don't they are doing a disservice to themselves.

I hope so. Although we got our PS3 dev kits waaaaaaay after first parties did ;(

one
30-Dec-2006, 06:35
the general sentiment seems to be that X360 may have a better GPU (tho not in all cases) and PS3 has a better CPU (tho again not in all cases; for example Assasin's Creed Dev team said AI code is faster on X360).That "better AI on 360" was debunked already.
http://ps3land.com/article-820.php
Besides, sweeping generalization like yours is not very suitable for B3D discussion IMO. One can argue the both GPU and CPU in the PS3 are worse because RSX needs the help of Cell and Cell is more difficult to code for. This disadvantage does not equal the performance capacity of the hardware itself. It's due to economic/human problems that they can't put enough monetary/human development resources for the R&D in the early stage of the PS3 platform.
Again, I'm not attacking nAo, I'm just trying to figure out why his word is final in these matters. He has produced a great looking game, but not only is that game (as far as we have seen in previews) not head and shoulders (that point is arguable, some may find it to be better looking others worse, as compared to x360 games) better looking than x360's best, he has only developed on the one platform.Cross-platform devs are doing ports for economic reasons of dev houses. In other words they are forced to support very different architectures by diluting some aspects of their game design, or by putting the priority on the platform with a larger install base. Though this extra pressure is not essential for developing games, it affects cross-platform developers' point of view.

pakotlar
30-Dec-2006, 06:43
That "better AI on 360" was debunked already.
http://ps3land.com/article-820.php
This disadvantage does not equal the performance capacity of the hardware itself. It's due to economic/human problems that they can't put enough monetary/human development resources for the R&D in the early stage of the PS3 platform.
Cross-platform devs are doing ports for economic reasons of dev houses. In other words they are forced to support very different architectures by diluting some aspects of their game design, or by putting the priority on the platform with a larger install base. Though this extra pressure is not essential for developing games, it affects cross-platform developers' point of view.

This is a generalization. It is due to difference in ease of development (dev tools + hardware) as well as the dilution of resources you mentioned. I believe joker already talked about this.
Didn't know that the AI rumour was "debunked". As far as I remember the dev stated that AI code was easier to implement. It has been stated numerous times that branch intensive code like AI is easier to implement on Xenos. Not my opinion. I never stated that I read that AI would be different for either version btw (reread my post).

Acert93
30-Dec-2006, 06:58
can't recall the last time somebody mentioned that of the Xbox360

Please reread this thread and specifically the links in the OP, where said poster himself noted issues (e.g. Xenon related issues, tiling, etc).

I know some of you believe this stuff (everything is always anti-Sony/MS), and there are definately leanings in certain areas among different posters, the reality is people tend to amplify the negative they dislike and ignore the kudos they agree with.

I do have to chuckle though about your 360 comment because in the last year we have had swarms of threads (not just posts, but threads) about lack of AF, lack of MSAA, draw call overhead, broken tiling APIs, thread swapping latency, inability to MEMEXPORT and Tile, and so forth.

Cell and Xenos, both, take by far the biggest lashings -- but also the biggest praises -- on B3D. RSX and Xenon, due to the lack of disclosure by Sony and MS, respectively, has kept discussion on both to a lower degree than the other two, although I think we have a lot better understanding of Xenon now than 12 months ago and I think MOST have come to the realization of what RSX is (although a little late for any interesting discussion).

For the most part, I think devs, especially, those with more even experience in both machines (or in general?), are usually not the ones to point out advantage in either machine...

I think fans tend to pit extremes too often.

The reality is that for multiplatform development, and the issues multiplatform devs face codeveloping a titles for 2 or 3 platform targets and typically under tighter annual deadlines and funding restrictions are quite different from flagship AAA 1st party title.

Neither position invalidates the other, they are just different. A perfect example will be Motorstorm and Heavenly Sword. They will be some of the first games (along with Resistance) to use a bit of the SPEs. Thus far multiplatform devs, due to the nature of the industry, have not had that luxury. What is a perk to one is neutral to the other.

And these sorts of check and balances vary greatly, not only based on exclusive/multiplatform, but also the type of game and technology you are trying to leverage.

IMO, what observers may best glean from this discussion (hopefully it stays calm) is that the hurdles, troubles, and difficulties of development for some 3rd parties is different than those from some 1st parties. Some of the things will be absolutely true for all developers within a confined context, many won't.

Personally, from a business standpoint, I find the opinions of 3rd and 1st parties interesting because their business models are so very, very different and compete and coexist in the same market, but by doing things very differently.

We've gotten around the split memory issue, but in our case we're seeing far less memory free in general. Out of the entire 512mb in each machine, both Sony and Microsoft reserve some for assorted reasons. We have somewhat more free memory on 360 for some reason. Maybe this is just due to the sdk's we're currently using, I'm not sure. Whatever the case may be, we maxed out memory on 360 so that left us scrambling for ways to free memory to get it to fit on PS3. Do you guys see this? I've always been curious if its just us that's seeing less free memory on PS3.

I am not a developer, but from my browsing I think their are two main culprits most agree on:

1. Framebuffer. Since the eDRAM does all the heavy lifting for the buffers the GDDR3 pool primarily holds the finished framebuffer itself. On the PS3 your 720p 4xMSAA framebuffer is going to be about 30MB, on Xenos much of that data is stored on the eDRAM and tiled in to the system memory.

2. OS. Hard to get any hard figures from MS or Sony, but it seems nearly absolutely certain that the PS3 operating system is a bit larger than the Xbox 360 operating system.

I think those would explain your available memory resource differences. Those and different storage formats and such which you already mentioned.

This one interested me because we're actually seing the opposite. We actually had a very specific case to deal with where a cutscene was running slower on PS3 and we tracked it down to being pixel shader bound. It was using a 'crazy expensive' pixel shader which stressed even the 360, but it was able to maintain 30fps. Hard to say for sure why we're see different results though.

I think the reality is depending on your enigne and shader code the 360 or PS3 can come out on top. Which would come out on top, most regularly, would be hard to tell even in an "ideal" world because even if one of the two chips was faster on 7 out of 10 shader codes, who is not to say that the 3 of those 10 are more common or important (in general or to a certain games design)?

We run into this problem all the time when benchmarking applications. What is better, GPU-A that edges out GPU-B by 5% in 7 out of 10 games, or GPU-B which edges out GPU-A by 25% in 3 applications? And when you dig deeper--like how many of those situations were at 30fps or below, and so forth--can make crowning a winner very difficult.

And the reality that you guys have hit on is there is more than 1 way to skin a cat. As you guys dig deeper into the consoles some of the different architectural decisions as well as featuresets may become more relevant. You may even find that to get a similar end result on screen you take competely different approaches and different technologies to get there. Personally, I expect over the next 2 years to hear stuff like, "We did ABC on an SPE" with a response, "We just used vertex texturing to do that on Xenos" and "We used tesselation on Xenos for this" with a response, "We didn't need RSX to do that because we did it on an SPE".

What really will matter is how the tools and hardware MS and Sony gave all of us makes for better games. The PS3 and Xbox 360 are so similar, yet frighteningly different. But in general performance envelope they are in the same general ballpark and most games with some adjustments will run on either, and should quite well. Of course, as your original thread vented and hit on, the time frame differences and price disparities and the obvious ****** attraction of every microcosmic event really blow things overboard and can make the discussion process, even in friendly disagreement, an act of frustration at times. For that I deeply feel bad for you devs! Almost as bad as I feel for myself :P

I think I can speak for everything when I say we appreciate having another developer here, especially a multiplatform developer (not many of those here who are vocal) and one who has worked on the Xbox 360 (before a couple months back ERP was pretty much it, but Cal and Fran have joined recently, but that is still a very small number compared to the number of PS developers here). Hopefully goodwill will prevail in the coming year and we can all learn something new, even if we have to agree to disagree.

We do ;) Although we are definitely not using them as effectively as we could. We're only using 1 spu at the moment as well. Shamefull, I know ;( But, I plan to devote a chunk of 2007 to making better use of threads on both PS3 and 360. My current thought is to make numerous 'threadlets', each being an extremely simple process that has one specific purpose, and snoozes and waits to be fed data for processing. We'll definitly be making full use of the spu's in '07.

It will be interesting to hear the results. SPEs are 'crazy fast' when you lean on their strengths. Please keep us updated for the sort of algorhythms you get up on the SPEs. It would be very neat to read a developer diary discussing the development process in detail, hurdles, false starts, restarts, and accomplishments (and dare I say compromises, corners cut, and failures) that occur from the planning, to designing, implimenting and finally to shipping stage.

Alas I am afraid that is a time consuming project and probably would not be NDA friendly. :(

rounin
30-Dec-2006, 07:05
...

I was only able to make it through the first paragraph before my translation part of my brain fried. I think I agree though:lol:

zRifle1z
30-Dec-2006, 07:47
........


I think I can speak for everything when I say we appreciate having another developer here, especially a multiplatform developer (not many of those here who are vocal) and one who has worked on the Xbox 360 (before a couple months back ERP was pretty much it, but Cal and Fran have joined recently, but that is still a very small number compared to the number of PS developers here). Hopefully goodwill will prevail in the coming year and we can all learn something new, even if we have to agree to disagree.
...........:(


Your entire post was very well written. Glad to see how this thread turned out and to see more light shed on the truth between both systems. This is why I like to lurk here. A special thanks to Joker454 and the way you responded within this thread. If you never post here again thanks for breathing new life into the subject of console gaming in the B3D forums.

Fox5
30-Dec-2006, 07:50
We've gotten around the split memory issue, but in our case we're seeing far less memory free in general. Out of the entire 512mb in each machine, both Sony and Microsoft reserve some for assorted reasons. We have somewhat more free memory on 360 for some reason. Maybe this is just due to the sdk's we're currently using, I'm not sure. Whatever the case may be, we maxed out memory on 360 so that left us scrambling for ways to free memory to get it to fit on PS3. Do you guys see this? I've always been curious if its just us that's seeing less free memory on PS3.

I've heard people say that Sony's OS reserves 64MB more ram than MS's. Additionally, ps3 doesn't have edram so it should have slightly less ram than the 360 anyway.

ShootMyMonkey
30-Dec-2006, 07:56
Damn... this thread really filled out in the course of my commute home from work.

We've gotten around the split memory issue, but in our case we're seeing far less memory free in general. Out of the entire 512mb in each machine, both Sony and Microsoft reserve some for assorted reasons. We have somewhat more free memory on 360 for some reason. Maybe this is just due to the sdk's we're currently using, I'm not sure. Whatever the case may be, we maxed out memory on 360 so that left us scrambling for ways to free memory to get it to fit on PS3. Do you guys see this? I've always been curious if its just us that's seeing less free memory on PS3.
Well, I'd think that much is a given because of the fact that there's just the framebuffer in VRAM as opposed to eDRAM and a split pool meaning there's probably some stuff allocated in both pools for the OS. In general, the PS3 OS is just plain bigger, but I'd have a feeling most of that reserved RAM at the moment is for "yet-to-come" features. I can only see Sony piling on more.

This one interested me because we're actually seing the opposite. We actually had a very specific case to deal with where a cutscene was running slower on PS3 and we tracked it down to being pixel shader bound. It was using a 'crazy expensive' pixel shader which stressed even the 360, but it was able to maintain 30fps. Hard to say for sure why we're see different results though.
Hmmm... well, in my case, I've been working on a pretty massive set of tools for generating shader code from artist input in a graphical layout tool -- it's akin to what Unreal has for materials, but we let artists control a broader scope and also share their work more easily (basically everything that isn't "fixed function" for our purposes, the artists control). In any case, that ultimately means that the largest real estate in our shaders is full of independent fragments in their own macros/functions many of which have a nice mix of vector and scalar ops (or at least you'll have a mix of code fragments some of which are mainly vector ops, some mainly scalar ops), which makes the compiler very happy (though very slow to build) when it comes to optimizing. Everything pairs up nicely for co-issues and also gets both the (mini-)ALUs in each pixel shader pipe working pretty effectively in concert for almost every cycle. We also tend to use a lot of FP16 operations in our shader code wherever it works out usefully, which the Cg compiler optimizes into using certain "trickery" native to the RSX. The 360's HLSL compiler casts them all to FP32, so no harm done.

I don't know what you qualify as 'crazy expensive', but we have little trouble maintaining 120 fps on both machines even with shaders of a few thousand instructions and 8 textures minimum on everything. Can't say that we approach the 5-figures range yet, though.

I may eat my words when we actually get around to constructing *real* levels (as even our most complex levels at the moment are all mainly proof-of-concept creations), but for the most part, it's the software side of things that is the bigger hurdle for us. Rendering is still not a big concern -- the GPU is still very underworked as it is.

Dr. Nick
30-Dec-2006, 08:07
This one interested me because we're actually seing the opposite. We actually had a very specific case to deal with where a cutscene was running slower on PS3 and we tracked it down to being pixel shader bound. It was using a 'crazy expensive' pixel shader which stressed even the 360, but it was able to maintain 30fps. Hard to say for sure why we're see different results though.
Isn't it true that sometimes Ati hardware is better a handling certain shaders and sometimes Nvidia hardware is better at handling certain shaders. Couldn't it be that your shaders are just more friendly to Ati hardware. I'm sure there are going to be games that pixel shaders are so optimized for the RSX that the Xenos would have alot of difficulty running them.

dantruon
30-Dec-2006, 08:28
But it doesn't mean that the PS3 version is better out right. Without some of the info stated in this thread, one could come to the conclusion that the devs made a trade off to get better looking models when one would have expected it to match the 360 in every aspect that it didn't improve upon. There are things about the game that look better than the 360 version and some that look worse. It doesn't really seem to be the clear graphics winner when that is the case. Sorry if this is off topic.

Isn't it true that sometimes Ati hardware is better a handling certain shaders and sometimes Nvidia hardware is better at handling certain shaders. Couldn't it be that your shaders are just more friendly to Ati hardware. I'm sure there are going to be games that pixel shaders are so optimized for the RSX that the Xenos would have alot of difficulty running them.

i agreed and that is why i did not say that the ps3 version is outright superior but i just want to suggested that the 360's version was not an outright superior compare to the ps3's version.

"Nerve-Damage"
30-Dec-2006, 08:39
Why do people feel easier = more powerfull!?

Yes, the Xbox 360 dev tools maybe more flexible and rich than PS3 tools, but that doesn’t equate into having better hardware (Xbox 360). More or less it represents Microsoft already proven strengths, which is software development. So I can picture certain amount of developers stating and feeling the Xbox 360 is easier, faster, in getting better port-to-port code.

That being said, that doesn’t equate into the PS3 hardware being crippled or flawed by RSX GPU. Many developers have stated that the PS3 tools are a whole lot cleaner and more intuitive this time around, compared to the PS2 tools when they were released. And as some have said, the PS3 tools will only get better and become more refined as time passes.

So if nAo and the rest of the Ninja Theory clan aren’t seeing or experiencing any of these PS3 issues (not enough memory, memory bandwidth issues, RSX stalling, ETC…) which other developers maybe experiencing, then the Ninja Theory team should be commended. Developer’s who write their own straight to the mantel PS3 code, will undoughtedly yield better results than a developer porting multiplatform Unicode. And the same applies to the Xbox 360.

Tap In
30-Dec-2006, 08:43
Why do people feel easier = more powerful!?


easier was not the only reason sighted by Joker for his comments.


I doubt NT was not experiencing some of the issues, my guess is without coming FROM the 360 with their code, they aren't able to distinguish the differences in going from one to the other which Joker has addressed in this thread. :smile:

NT just worked around it as they always would because they are smart and talented. Joker also agreed that they would do the same but that the hardware (memory available for one) physically makes it better for their game which was already using more memory than they could find on PS3.

StefanS
30-Dec-2006, 08:45
Guys, this is the final call! From here on, there'll be bloodshed...

I am trying as hard as I can to keep this thread on topic and to keep the quality as high as it can possibly be. This is topic about programming on RSX and Xenos (Note: this is not a software comparison thread!). So please stay on-topic.
To make things a little more obvious:

If your post contains / needs to relie on visual evidence, don't post...
If your post is about the "allegiance" of the devs, don't post ... Beyond3d readers should be smart enough to form their own judgement
If your post needs to statistical evidence (X games look better than Y games. X>Y), don't post... I think the focus should be on developing rather than the numbers of games released
etc.

Since I've spent now some time pruning this thread, I will not be very tolerant concerning derailment etc. In fact, further abuse will have consequences.

That said I'd like to say a big thanks for contributions of the devs. Everyone else keep the questions coming!

pakotlar
30-Dec-2006, 10:11
I trust that many of us believe relatively speaking, info on X360 is much scarcer than that of CELL and RSX. For instance, who has benched the CPU on a X360 and has posted on it. This is not really something that needs debate.

Who has benched RSX? Even though it is based on G71 architecture, no one has ever benchmarked the RSX to my knowledge. There are no results that say, ok RSX gets 2200 points on 3dmark 06 Shader 3.0 benchmark, or whatever. Something that gives us a frame of reference. Obviously what is a good benchmark is debatable, so it doesn't have to be 3dMark. The Cell benchies that we have are useful only in looking at how fast cell can iterate mandelbrot, or how fast it can render a terrain in a contrived case. Very interesting, but it doesn't tell us a whole lot about how it handles AI + Physics + Culling etc concurrently under specific workloads.

It is true that Cell has been benched more than Xenon (I wonder if anyone can dig up legitimate Xenon benchies :D), but how useful are those numbers to us for comparitive purposes? The only stuff that I've seen that hasn't come from IBM isn't very optimized.

The more important part question is how well Cell + RSX + split buses complement each other. It is more than the sum of its parts.

The same question exists for Xenos + Xenon.

And in-depth tech specs are readily available for Xenos and Xenon just like they are for Cell. If anything RSX is the more unknown part due to the lack of disclosure from Sony.

edit: I don't know how legitimate these are but these are "estimated" benchies for Xenon, but here goes : http://www.anime.net/~goemon/benchmarks.html

Can anyone tell me if Xenon's performance is more predictable because of its likeness to PPC architecture?

Shezad
30-Dec-2006, 10:16
That being said, that doesn’t equate into the PS3 hardware being crippled or flawed by RSX GPU.

Every GPU has hardware bugs RSX as well, it is difficult to get something good when you rush a project involving a high complex asic.

MasterDisaster
30-Dec-2006, 10:18
about the pixel shading capabilities of the two console, Joker454 can you confirm this (comparison with Pixel Shader 3.0, taken from the article about xenos by Dave Baumann)?

# Instruction slots
PS3 512
360 4.000
NB: MEMEXPORT" could be used to increase the length of a shader program beyond the nominal 4000 instructions.

Max # of instructions executed
PS3 65.535
360 500.000

Temp Registers
PS3 32
360 64

# constant registers
PS3 224
360 512

Dynamic Flow Control Depth
PS3 24
360 8.388.608 nesting

# of texture samplers
PS3 16
360 32

Interpolated Registers
PS3 10
360 16

could be this different capabilities the reasons that makes xenos faster in your code?

edit:
and what about other 360 features as:

* Multiple Render Targets (MRT)
4 render target outputs are supported as output and, as an addition to current processors, each target can have different blend capabilities.
* Hierarchical Stencil Buffer
Operates similar to the Hierarchical Z buffer to quickly cull unnecessary stencil writes.
* Alpha-to-Mask
Converts Pixel Shader output alpha value to a sample mask for sort-independent translucency.

An additional functional element that Xenos provides to developers is a Geometry Tessellation Unit.

excuse me for so many questions, and thank in advance if you can answer some of those (if NDA permit this)

DeanoC
30-Dec-2006, 10:29
We do ;) Although we are definitely not using them as effectively as we could. We're only using 1 spu at the moment as well. Shamefull, I know ;( But, I plan to devote a chunk of 2007 to making better use of threads on both PS3 and 360. My current thought is to make numerous 'threadlets', each being an extremely simple process that has one specific purpose, and snoozes and waits to be fed data for processing. We'll definitly be making full use of the spu's in '07.

We use a job based system, a job being a single task >100,000 spu cycles. A small job manager (running on the SPUs themself) simply takes job descriptor from a main memory list and allocates that job to a free SPU. Each job runs to completion, so you have a simply co-operative multitasking system. One key point is that a job can create new jobs, which allows a single SPU job to kick off a lots of other jobs, providing autonomy from the PPU.
We use the facility in the army code, an SPU job is kicked off, this does a spatial hierachy job division. Each new sub job then does a localised AI/Physics update for the soldiers inside that small part of the battlefield.
Per frame (in the army sections) we might have ~500 jobs, covering animations (DeanA the man with the details, but essentialy we batch something like 32 animation updates per job), army AI/Physics, rendering, procedural (i.e. hair & flags), frustra culling and clipping, etc.

Shezad
30-Dec-2006, 10:44
could be this different capabilities the reasons that makes xenos faster in your code?




Unlikely, with the Xenos you can do very important and cheap operations for free (like changing constants), not with the RSX, so you can imagine that when we try to run the same asset + same shaders on both platform the latter blows up.

DeanoC
30-Dec-2006, 10:47
So if nAo and the rest of the Ninja Theory clan aren’t seeing or experiencing any of these PS3 issues (not enough memory, memory bandwidth issues, RSX stalling, ETC…) which other developers maybe experiencing, then the Ninja Theory team should be commended. Developer’s who write their own straight to the mantel PS3 code, will undoughtedly yield better results than a developer porting multiplatform Unicode. And the same applies to the Xbox 360.
Of course we encountered problems, we moved from PC and an early 360 version (alpha kit) to PS3. However we have the advantage of just doing whatever voodoo the PS3 requires.

However we seemed to have worked around them, without any major SPU GPU work (I personally see too much SPU time on graphics as a waste, I want the SPU to make the game better).

MasterDisaster
30-Dec-2006, 11:01
Unlikely, with the Xenos you can do very important and cheap operations for free (like changing constants), not with the RSX, so you can imagine that when we try to run the same asset + same shaders on both platform the latter blows up.

this is a very useful information, can you elaborate more about those operations and the other things related?

matrix960
30-Dec-2006, 11:02
Maybe I'm wrong but vertex shader unit (in term of gflops/real performance) were not very very good. Some companies wanted to use GPU to help CPU in common tasks and don't achieve one tenth of the number given by Nvidia or ATI. So with all the power in Cell, it would very useful in games when coorectly used because :

8 vertex shader at 500 Mhz (or 550) versus 6 SPE at 3.2 GHz, that must make a difference, isn't it?

reilo
30-Dec-2006, 11:05
This is a great thread. What a breath of fresh air from System Wars at Gamespot :shock:

I have a question... I don't know if this is the appropriate question to ask or not.

Everywhere I read it says that the PS3 is crippled by the split-memory, and that developers are restricted to essentially 256MB from the GPU for textures, and that developers have a hard time with that, but what about the 256MB of system memory? Can developers go about and use that 256MB of system memory for textures, or is that not possible? Can someone clear this up, because I have not been able to find any conclusive answer(s) as to why this is such a huge problem (as said by certain people). Or is it even a problem?

"Nerve-Damage"
30-Dec-2006, 11:22
Can developers go about and use that 256MB of system memory for textures, or is that not possible?

Yes the XDR is accessible for textures…all 256MB of it…I don’t think so. There’s other things going on in PS3 (OS, code, ETC…) that requires XDR memory also.

MasterDisaster
30-Dec-2006, 11:34
Everywhere I read it says that the PS3 is crippled by the split-memory, and that developers are restricted to essentially 256MB from the GPU for textures, and that developers have a hard time with that, but what about the 256MB of system memory? Can developers go about and use that 256MB of system memory for textures, or is that not possible? Can someone clear this up, because I have not been able to find any conclusive answer(s) as to why this is such a huge problem (as said by certain people). Or is it even a problem?

from what I know RSX can't reach directly the system memory but it have to pass trought cell adding ome serious latencies

the simple scheme is

DDR3<-->RSX<--------->CELL<-->XDR

DDR3 can hardy used as main memory from the system (if it can ve used at all)

from a dev perspective the texture flow from the memory have to be constant as possible, I thought that FB and textures are mainly stored in Vram, and other textures used less often can be stored in sysram
I think this can put some serious limitations to the overall amount of critical-mission textures of the scene, but I'm not a ps3 dev plu some further limitations (I think of how hard can it be to rsx and cell to work on the same large data without duplicate this), so wait for some exact information by nAo, deanoC, joker454 and others for more educated and precise informations.

"Nerve-Damage"
30-Dec-2006, 11:35
Yeah, I understood that much, I am just more curious if this poses a challenge to developers or if it was just fud.

All systems pose a challenge, no matter how good the programmer and dev-tools are. Xbox 360 may have the advantage over PS3 as being more programmer friendly, but that doesn’t elevate it from certain bottlenecks the system has. Balance is the key…

MasterDisaster
30-Dec-2006, 11:37
There’s other things going on in PS3 (OS, code, ETC…) that requires XDR memory also.

I've read somewhere that the OS keeps a separate frame buffer for OS function while a game is running (32 MB in Vram), don't know if it's correct but it make sense to me
never heard a single word about code which uses Vram, can you elaborate?

Xbox 360 may have the advantage over PS3 as being more programmer friendly, but that doesn’t elevate it from certain bottlenecks the system has. Balance is the key

Since I thought that all the custom hardware makes of the 360 a very well balanced machine, can you elaborate further, please?

reilo
30-Dec-2006, 11:43
I've read somewhere that the OS keeps a separate frame buffer for OS function while a game is running (32 MB in Vram), don't know if it's correct but it make sense to me
never heard a single word about code which uses Vram, can you elaborate?


Some have speculated that since Sony said that a game developer can create a custom OS as they wish and please -- correct me if I am wrong NT devs -- that it is potentially possible that Sony will release libraries to be stored in that "reserved for OS" SPE and allocated RAM.

Again, this is just what I hear, and take it with a grain of salt. I am not a dev.

Squeak
30-Dec-2006, 12:13
Any way you PS3/360 devs. can tell us exactly how much memory is free to use on either machine? I mean how much is locked and set aside for the OS?

Concerning texturing from XDR, is the latency really anything to worry about, since there is no way you are ever going to be able to splash all 256MB on the screen in any one frame in a normal game? Won't there be plenty of time to fetch textures between frames?

deathkiller
30-Dec-2006, 14:14
Any way you PS3/360 devs. can tell us exactly how much memory is free to use on either machine? I mean how much is locked and set aside for the OS?
I think that you are asking for infromation protected by NDA and they already have said more than they should in that deparment.

Concerning texturing from XDR, is the latency really anything to worry about, since there is no way you are ever going to be able to splash all 256MB on the screen in any one frame in a normal game? Won't there be plenty of time to fetch textures between frames?
Are you talking about moving the textures to the VRAM? if not you have a problem with the GPU cache size, you can't fech textures for the next frame because the cache is limited.

PiNkY
30-Dec-2006, 14:20
I don't know what you qualify as 'crazy expensive', but we have little trouble maintaining 120 fps on both machines even with shaders of a few thousand instructions and 8 textures minimum on everything. Can't say that we approach the 5-figures range yet, though.


Perhaps I am getting something wrong but doesn't an avg. workload of 1k operations/fragment exceed the theoretical capabilities of RSX & Xenos by a factor of at least 4 at 720p/120Hz (assuming zero overdraw)?

DeanoC
30-Dec-2006, 15:21
Unlikely, with the Xenos you can do very important and cheap operations for free (like changing constants), not with the RSX, so you can imagine that when we try to run the same asset + same shaders on both platform the latter blows up.
There is a technique that makes constant changes quite cheap on RSX, but discussion is not for here...

And neatly hooking up with another question, texturing (note NV also consider other things as a texture fetch) from XDR is fine. The hardware is designed to cope with it fairly well, there are some caveats but they probably only become a problem with very simple shaders.
The main problem you find, is that given up some of your precious main ram for graphics can be a hard pill to swallow.

-=P3tRaN=-
30-Dec-2006, 15:31
What does FKATCT mean?
"formerly known as the Charlatan thread"





joker welcome to this board! looking forward with interest to read your opinions.
cheers


p.s.
with all this talk from NT team, I am pretty hyped for the game!!! good stuff!

Shifty Geezer
30-Dec-2006, 15:34
Isn't it true that sometimes Ati hardware is better a handling certain shaders and sometimes Nvidia hardware is better at handling certain shaders. Couldn't it be that your shaders are just more friendly to Ati hardware. I'm sure there are going to be games that pixel shaders are so optimized for the RSX that the Xenos would have alot of difficulty running them.I remember it was said of G70 that nVidia consulted with devs about the most common shaders and optimized for those. I've no idea how that's accomplished, but it does sound the case that some architectures will be better at some generic shaders than others, not taking into account more exotic features like branching.

almighty
30-Dec-2006, 18:15
You can't do this on PS3 because its 720-1080 hardware scaler is broken, so you'd have to scale it in software which takes up more of those precious cycles.

So PS3 does have a hardware scaler? i thought it was software only :???:

inefficient
30-Dec-2006, 19:13
We use a job based system, a job being a single task >100,000 spu cycles. A small job manager (running on the SPUs themself) simply takes job descriptor from a main memory list and allocates that job to a free SPU.

That is awesome. I didn't expect we would see that technique being used so soon. Did Sony provide libraries for this sort of thing? Or did you have to design/implement the whole thing entirely?

To be able to get good results from this on a first gen game this is quite exciting! Hopefully other teams will pick it up fast too.

ShootMyMonkey
30-Dec-2006, 19:53
# Instruction slots
PS3 512
360 4.000
When you say "PS3", do you mean just "pixel shader 3" spec or "Playstation 3"? 512 is the minimum spec for SM3.0 (I believe that's the case for all those specs you have listed under "PS3"), but even the GeForce 6 series offered up to 4096 instruction slots, IIRC. Or at least the 6800, did I think. My memory for these things is horrid since I hardly ever buy new video cards. Everything I own at home predates AGP.

Perhaps I am getting something wrong but doesn't an avg. workload of 1k operations/fragment exceed the theoretical capabilities of RSX & Xenos by a factor of at least 4 at 720p/120Hz (assuming zero overdraw)?
D'oh... I just realized I should have said "everything major" -- as these are generally proof-of-concept levels, the areas are dominated by stuff that is meant to illustrate key features, and usually shading is among them. Everything else tends to get relatively lightweight stuff. All the same though, the lightweight materials rarely if ever dominate the screen (short of deliberately zooming in on something specific). And of course, I'm also counting other things besides computational instruction slots. And BTW, it's not exceeding the theoretical capacities by a factor 4.

I should also add that those were figures for one particular project. The other one has its proof-of-concept levels being enormous with really huge draw distances and very few occluded polys (lots of wide-open area), loads of full-screen effects, and so one... and we stick around 40 fps on that one -- 40 on the 360, that is. PC is lucky to get 30, and they don't have a PS3 build yet.

Carl B
30-Dec-2006, 19:54
So PS3 does have a hardware scaler? i thought it was software only :???:

It's not 'broken' either as implied... it's just inaccessible to games.

deathkiller
30-Dec-2006, 20:02
That is awesome. I didn't expect we would see that technique being used so soon. Did Sony provide libraries for this sort of thing? Or did you have to design/implement the whole thing entirely?
I heard that the PS3 SDK has a library for developing job systems for SPUs and that is quite powerfull. I don't know if Ninja Theory is using it as a base of their job system.

DeanA
30-Dec-2006, 20:37
I heard that the PS3 SDK has a library for developing job systems for SPUs and that is quite powerfull. I don't know if Team Ninja is using it as a base of their job system.
There's SDK support for both out-of-the-box and custom SPU job management schemes, and internally we have a job manager that effectively plugs into this system which is available for teams operating as part of (or for) SCE WWS. So specifically, it's this custom job manager which Ninja Theory (*not* Team Ninja, as they are a group within Tecmo) are using.

Cheers,
Dean

22psi
30-Dec-2006, 20:37
I heard that the PS3 SDK has a library for developing job systems for SPUs and that is quite powerfull. I don't know if Team Ninja is using it as a base of their job system.

Do you mean Ninja Theory?

Acert93
30-Dec-2006, 20:57
Of course we encountered problems, we moved from PC and an early 360 version (alpha kit) to PS3. However we have the advantage of just doing whatever voodoo the PS3 requires.

However we seemed to have worked around them, without any major SPU GPU work (I personally see too much SPU time on graphics as a waste, I want the SPU to make the game better).

Our hero :grin: I confess my unnatural love for graphics, but what makes games great are the things that occur and how players can interact with such. When I hear such sweet love music from a developer I truly wonder how MS let you slip off their platform. I can see Allard now :runaway:

I remember it was said of G70 that nVidia consulted with devs about the most common shaders and optimized for those. I've no idea how that's accomplished, but it does sound the case that some architectures will be better at some generic shaders than others, not taking into account more exotic features like branching.

This was why they added an extra MAD (or was it a MUL? foggy... one or the other I believe) to each fragment shader in G70. So each Pixel Shader in G70 has 2 fragment shader ALUs as well as the additional MAD. Basically through testing of shaders they saw that many shaders could use an extra MAD and that the cost of offering such was cheap. At least that is how I remember it...

deathkiller
30-Dec-2006, 21:08
Do you mean Ninja Theory?
Yea, sorry...

DeanoC
30-Dec-2006, 22:24
There's SDK support for both out-of-the-box and custom SPU job management schemes, and internally we have a job manager that effectively plugs into this system which is available for teams operating as part of (or for) SCE WWS. So specifically, it's this custom job manager which Ninja Theory (*not* Team Ninja, as they are a group within Tecmo) are using.

Cheers,
Dean
So as Dean say we (NT) use the WWS provided job manager, which is itself built as a custom SPU job scheduler on the standard PS3 job api (SPURS).
We (NT) also have a layer above the WWS job manager which provides a bunch of high level things to make our lives easier but all the hard work is done by WWS and the OS, Which is nice :)

Fran
30-Dec-2006, 23:17
This problem is easily fixable, just store an additional bit per vertex that let you reconstruct the original tangent basis vectors. In HS we store a bit like that in the most significant bit of the w component of our position vectors so that we to reconstruct binormals we do something like that:

float4 binormal = sign(position.w) * cross( normal, tangent );

very cheap and effective.

Yep. Same here. Works fine.

To speed up simple rendering passes as z pre passes or shadow map one just needs to split vertex data in at least 2 streams: one for position and the other one for all the rest..that way one can basicly achieve VS throughput wise some number pretty close to the theoretical capabilities of the chip.

Only problem with this approach on the 360 is that each stream forces a full vfetch (and 32 cycles), so we want to reduce the number of streams to the bare minimum. Only one wherever possible. I tend to duplicate position information for z-only rendering where it makes sense. Ugly, but faster in vertex-limited situations on the 360 and with predicated tiling always looming around...

Fran
30-Dec-2006, 23:25
Not sure why you'd laugh, its the most visually impressive console title to date. You need to play a few hours into it to see some of the best graphics though. Even if you assume that rsx by itself could do it, you then run into other PS3 limitations like less free memory available.

It must be said that most of the amazing look of GoW comes from the fantastic job done by the artists in setting up each scene, most probably greatly helped by the slick tool chain.
From a purely engine perspective, I also can't see anything that can't be done with a RSX and anything that can't be done better on the 360 in future titles, especially with engines tailored to each console's strengths and designed to exploit them.

Fran
30-Dec-2006, 23:30
You'd be surprised how few games are actually using all 6 hardware threads on 360.

Also because using two threads on the same core won't give a big speed up if both threads are doing integer math or fp math :p

babcat
30-Dec-2006, 23:37
It has been mentioned on this thread that the Playstation 3 has less available total RAM than the 360. I have been curious about this issue before this thread ever began.

I know that the OS reserves some portion of the RAM in both the 360 and the PS3. Can anyone here please confirm the exact amount of RAM reserved by the OS in both systems?

The last best guess that I heard is that the PS3 has 64 megabytes reserved by the OS and the 360 reserves 32 megabytes. These numbers were just someone's guess from working with a previous early devkit.

Can anyone here please settle this issue once and for all?

I believe this issue is significant to this thread because someone already said that it's difficult to port a 360 game to the PS3 because there is simply not enough room to fit all the textures in at full size. This is a very bold claim to make. It very well could be true, but it needs to be backed up with facts about the two system's OS requirements.

crazygambit
31-Dec-2006, 00:22
It has been mentioned on this thread that the Playstation 3 has less available total RAM than the 360. I have been curious about this issue before this thread ever began.

I know that the OS reserves some portion of the RAM in both the 360 and the PS3. Can anyone here please confirm the exact amount of RAM reserved by the OS in both systems?

The last best guess that I heard is that the PS3 has 64 megabytes reserved by the OS and the 360 reserves 32 megabytes. These numbers were just someone's guess from working with a previous early devkit.

Can anyone here please settle this issue once and for all?

I believe this issue is significant to this thread because someone already said that it's difficult to port a 360 game to the PS3 because there is simply not enough room to fit all the textures in at full size. This is a very bold claim to make. It very well could be true, but it needs to be backed up with facts about the two system's OS requirements.

It's been mentioned in this very thread that the reason developers aren't giving out the exact number of RAM reserved by the OSs is because that information is under NDA. There's no point in continuing to bug developers with those questions. They'll give you as much info as they are willing and able to give, and I think we should be thankful for it. This thread already has proved to be very informative, so thanks to the developers for all their input, it's greatly appreciated.

dantruon
31-Dec-2006, 02:10
^ I second that.

_phil_
31-Dec-2006, 09:19
Double post

_phil_
31-Dec-2006, 09:47
It must be said that most of the amazing look of GoW comes from the fantastic job done by the artists in setting up each scene, most probably greatly helped by the slick tool chain.
From a purely engine perspective, I also can't see anything that can't be done with a RSX and anything that can't be done better on the 360 in future titles, especially with engines tailored to each console's strengths and designed to exploit them.

err.. some people got bad rep for telling this..
But it's so true.
Most of the graphics have a static approach of lighting ,and probably a lot simple emissive cubemaps on lambert type of surfaces.A lot of detailmap (normalmap and diffuse) is making up for very hirez texturing.
Certainly a very smart job from artists ,but for developpers ,certainly not an incredible showcase of technology.

On the topic of plateform ,when we straight port our first Ps3 engine to X360 we had much better performances.Then ,becoming ps3 exclusive ,we did a lot of rethink and tuning (and up to date kits and libs) ,it 's now a lot much better than x360 's....
This Is normal ,when you have oportunity play with the strenghts.

Most multiplateform titles can't get that dedicated tailoring pass so both versions will compromise.Ports,depending on $$ pressure ,will even more.

X-AleX
31-Dec-2006, 10:24
.

On the topic of plateform ,when we straight port our first Ps3 engine to X360 we had much better performances.Then ,becoming ps3 exclusive ,we did a lot of rethink and tuning (and up to date kits and libs) ,it 's now a lot much better than x360 's....
This Is normal ,when you have oportunity play with the strenghts.


Of course it is. Following this logic tho, if you would have become x360 exclusive with up to date kits and libs directly from Microsoft and an engine tailored for 360, perfomances could have been very similar to ps3 ones.
Am I correct?
Someone asked the costs of each system OS.

According to this article http://dpad.gotfrag.com/portal/story/35372/?spage=6 , Everything comes at a cost and here are the costs for the 360. # 32MB of the 512mb of available GDDR3 RAM
# 3% CPU time on Core1 and Core2 (nothing is reserved on Core0)

Microsoft still has room left from what they’ve already reserved for future updates.

Transitioning to the PS3’s Operating system here is what the resource allocation looks like.

Sony of course has decided to match Microsoft by using a constantly running in the background Operating system and here is what it includes. Again I will not be going into what it offers as most already know by now.

The costs for the PS3’s operating system are as follows
# 32mb of the 256mb of available GDDR3 memory off the RSX chip
# 64mb of the 256mb of available XDR memory off the Cell CPU
# 1 SPE of 7 constantly reserved
# 1 SPE of 7 able to be "taken" by the OS at a moments notice (games have to give it up if requested).

inefficient
31-Dec-2006, 10:37
...

Any numbers on what memory resources the PS3 allocates is just rumors and speculation at this point. And there is no point discussing it because 1. It's already been discussed to death and it leads to fighting. 2. The information is under NDA so no one can back up their claims.

Darkon
31-Dec-2006, 10:46
Of course it is. Following this logic tho, if you would have become x360 exclusive with up to date kits and libs directly from Microsoft and an engine tailored for 360, perfomances could have been very similar to ps3 ones.
Am I correct?
Someone asked the costs of each system OS.

According to this article http://dpad.gotfrag.com/portal/story/35372/?spage=6 , Everything comes at a cost and here are the costs for the 360. # 32MB of the 512mb of available GDDR3 RAM
# 3% CPU time on Core1 and Core2 (nothing is reserved on Core0)

Microsoft still has room left from what they’ve already reserved for future updates.

Transitioning to the PS3’s Operating system here is what the resource allocation looks like.

Sony of course has decided to match Microsoft by using a constantly running in the background Operating system and here is what it includes. Again I will not be going into what it offers as most already know by now.

The costs for the PS3’s operating system are as follows
# 32mb of the 256mb of available GDDR3 memory off the RSX chip
# 64mb of the 256mb of available XDR memory off the Cell CPU
# 1 SPE of 7 constantly reserved
# 1 SPE of 7 able to be "taken" by the OS at a moments notice (games have to give it up if requested).

Don't know about how much memory the OS reserves ( heard it was 64 mb ) but 1 spe taking by OS at any moment is bullshit.

Edit

Dear lord the author of that article is clueless.

almighty
31-Dec-2006, 10:59
# 1 SPE of 7 able to be "taken" by the OS at a moments notice (games have to give it up if requested)[/B].

Thats complete rubbish

Hardknock
31-Dec-2006, 11:16
96MB has been confirmed by devs on this very forum if I'm not mistaken.

ah here we go. It was Heliosphere(multiplatform dev):

http://www.beyond3d.com/forum/showpost.php?p=736647&postcount=213

http://www.beyond3d.com/forum/showpost.php?p=735945&postcount=97

Darkon
31-Dec-2006, 11:22
96MB has been confirmed by devs on this very forum if I'm not mistaken.

No your not but so has 64 MB, if I’m not mistaken

almighty
31-Dec-2006, 11:24
No your not but so has 64 MB, if I’m not mistaken

I always remeber it being reduced aswel :???:

DeanA
31-Dec-2006, 11:29
Microsoft still has room left from what they’ve already reserved for future updates.
And you think SCEI haven't got room for future updates..? That would be a bizarre thing to assume, especially when taking into account SCEI's fairly agressive firmware upgrades for PSP. I can see no reason why this would be different on PS3 - infact, Phil Harrison has (along with other SCE management) already said as much.

Anyway, this thread is getting way off topic... I'm surprised xbd hasn't popped up yet!

To kind of get back on track, my own view of it is that while it's unfortunate that the same systems & assets may not yield maximum performance on both platforms (for those doing multiplatform development), it's not exactly a surprise. And while some devs (DeanoC for one) may prefer using SPUs for game code rather than any GPU-related work, depending on what the goals of a specific project are, using SPUs to do trimming (and, at the same time, potentially doing progressive meshing, skinning, etc) doesn't seem unreasonable if you've got a *really* vertex-heavy application. A nice thing about the PS3 approach is that it's completely up to the developer as to what to use the SPUs for. Of course, the down-side of this is that multiplatform developers either need to accept that there are going to be differences in this area (code, assets, stripping algorithms, attribute packing, alpha fill-rate performance etc) and just deal with them, or develop their titles such that it's targetted at a base specification that's achievable on both machines with a minimum of platform-specific change.

The choice is theirs, based on their project timescales and resources. The top-tier of multiplatform developers will, I suspect, put the effort in. This is already evident by Joker's feedback to this thread .

Cheers,
Dean

babcat
31-Dec-2006, 12:05
I had originally heard that the OS reserved 96 total megabytes. However, the person who indicated that only had experience with an early devkit.

Then somewhere (I'm not sure where) I read that in the final commercial unit that the total memory reserved by the OS was 64 megabytes.

All I can say is that even though I believe that overall the PS3 has more potential to create better graphical effects (with a good bit of work programming the SPU's to help out the RSX) I think that Sony was a little greedy with the OS memory requirement.

If the 360 can make do with 32MB why could the PS3 not make due with it?

If the PS3 truly has either 32 or 64 fewer megabytes of free RAM for developers to work with that's a significant hint in my opinion.

I still think that the extra shading abilities of the RSX, the power of the SPU's, and the large storage space provided by Blu-ray will in the end make the PS3 the most powerful system and game developers will eventually admit it has the most absolute potential if you are willing to work for it.

But I can't help but think to myself that 64 or 96 megabytes is a LOT of RAM for the OS to reserve for it's own purposes.

wazoo
31-Dec-2006, 13:08
We do not know what are the Sony's final plans as far as multimedia goes for the ps3, but from the beginning, Sony wants the ps3 to be a multimedia hub, whereas MS wants the xbox360 to be more like a Vista media center extender. That alone may means more processing and memory eaten on the ps3 side for the same task (the ps3 doing some task whereas the the same task could be done on the PC then streamed on the X360) ??

almighty
31-Dec-2006, 13:12
If the 360 can make do with 32MB why could the PS3 not make due with it?

Beucase the PS3 does more stuff then 360 while running a game :???: Cant it run web pages and multiple downloads while running a game?

Hardknock
31-Dec-2006, 13:20
Beucase the PS3 does more stuff then 360 while running a game :???: Cant it run web pages and multiple downloads while running a game?

No. From my understanding you can't have the web browser up or download at the same time while playing a game.

wazoo
31-Dec-2006, 13:26
According Harrisson, multitasking should be up around the euro launch.

Graham
31-Dec-2006, 13:38
Would it be feasible, say, to sacrifice 1 frame latency to have the SPEs handle post processing (whilst RSX carries on it's merry way with the next frame?). I've wondered about that a bit.

I've also been thinking about things like cloth simulation. I'd expect very well suited to SPEs, yet at the same time xenos could probably do this very well, with a few textures representing the forces, etc.

Given an SPE culling geometry and streaming indices to RSX (thats how it happens?) - would there not be some fairly tricky sync issues? Might not the SPE have to sit idle waiting on RSX a fair bit?. Also I assume it's cache limited to how many triangles it can throw out before needing a refill? Would this hit the PPU (interrupt?) or is it capable enough on it's own?

I for one am curious to see what developers manage to crank out of the SPEs. (or is it SPU? I always thought it was sugargestic proclamation events.. ohh well)

Btw 2007 is awesome. Beware of the dragons though.

DeanoC
31-Dec-2006, 14:30
A nice thing about the PS3 approach is that it's completely up to the developer as to what to use the SPUs for.

Indeed and the nice thing about having a bunch of SPU with a good task system, is its entirely possible to mix both types of programs (as a GPU enhancer and for gameplay system).

For example an area where SPU can benefit RSX a fair bit, is as Dean talks about as a geometry modifier (trimming small triangles, doing progressive meshing, HO tesselation, etc.). You can do this on either part of frame across all SPUs, or dedicate 1 or 2 SPU to the job and leave the others for general tasks.

I suspect you could do a similar thing on 360 CPU as well, to maximise the 2nd threads of each core. Put a cooperative job system on the 2nd hardware thread of each core, that picks up VMX128 jobs to assist R500... If your main threads weren't doing much VMX ops, that might actually be a good way to get both good performance...

Shifty Geezer
31-Dec-2006, 14:35
Given an SPE culling geometry and streaming indices to RSX (thats how it happens?) - would there not be some fairly tricky sync issues? Might not the SPE have to sit idle waiting on RSX a fair bit?Depending on what scheduling system you use, idle time could be minimized. Similar to US versus fixed shaders, VS may be sitting idle, whereas in US, those units would switch to PS. When the SPE isn't needed for vertex work, shift it onto another job with the option to preempt out back to vertex work.

Nesh : I'm tempted to negative rep you for the above. You know screenshots of that size aren't allowed on this forum, and the GeOW vs. Resistence debate has already been removed from the thread. I'm sure the mods don't want to be cleaning up messes after they've already said what not to post about.

Nesh
31-Dec-2006, 19:00
Nesh : I'm tempted to negative rep you for the above. You know screenshots of that size aren't allowed on this forum, and the GeOW vs. Resistence debate has already been removed from the thread. I'm sure the mods don't want to be cleaning up messes after they've already said what not to post about.

It wasnt intentional. Sorry about that. I didnt notice because I didnt follow the thread from the beginning.

Also I wasnt making a game VS discussion. Its a misunbderstanding if I gave that impression. I was only pointing out to the time frames and Unreal Engine 3's capabilities which should be the reason for the difference in visual results. And since this is a technical forum I wasnt refering to these as games either but mostly as developer's work exploiting hardware and features which differ due to more and other reasons than hardware limitations and similar development time.

With other words there was no point comparing Resistence with GoW to extract conclusions

joker454
01-Jan-2007, 00:09
The costs for the PS3’s operating system are as follows
...
# 1 SPE of 7 able to be "taken" by the OS at a moments notice (games have to give it up if requested)[/B].

This isn't entirely correct. I'm going by what other devs have told me here, but of the 6 spu's nomally for dev use, Sony can use roughly 5% of one of them at a moments notice. As a fellow dev once told me, we effectively have 5.95 spu's. I haven't verified this though.

joker454
01-Jan-2007, 00:25
But I can't help but think to myself that 64 or 96 megabytes is a LOT of RAM for the OS to reserve for it's own purposes.

Those numbers seem "more or less" in line with what we've seen. They don't include the edram that the 360 has though, on PS3 we have to use some of the precious vram for frame buffers, don't need to do that on 360. The 360's memory advantage is huge currently, although this could change if sony trims back their memory needs. I think this is a much bigger issue to multi platform devs like myself. If you just do PS3 then you may not be feeling the pain as much. Taking a 360 game that looks nice and suddenly realizing that you have to free up 60+ megabytes of memory sucks ;( Likewise, taking your PS3 game and porting it to 360 will leave you with gobs of memory free which you may as well use to improve visuals. This is one of the reasons why I've been thinking lately that our 360 version will always look better than our PS3 version. We try to be clever as to which textures we downsize of course, so it's entirely possible that the typical game player won't notice.

joker454
01-Jan-2007, 00:37
Unreal Engine 3 was first revealed in 2004, and even then it was looking extremely polished and complete. So Gears, if truth be known was in development for atleast 3+ years, how much better do you think Resistance would of looked if Insomniac spent 3 years on a game engine before they starting creating game assett's? ;)

Thats what annoys me when people compare PS3 game's to 360 one's that use UE3, UE3 is an extremely streamlined engine thats had years of work, 90% of PS3 launch game's use game engine's that id bet have'nt even had half of the time spent developing them as UE3.0 has.

Oh, seems like I missed this one. Gears does leverage unreal, but Insomniac has also been leveraging an engine that Naughty Dog had written and tweaked for many many years as well. Seems like a fair comparison to me.

babcat
01-Jan-2007, 00:40
joker454,

Let me ask you a question. You have indicated many times that you 360 games will look better than your PS3 games due to the 360 having more available RAM for you to utilize.

Do you believe that the extra RAM of the 360 (both due to EDRAM and lower OS requirements) will be more significant to producing the best possible graphics than the other factors that are in the PS3's favor (such as the CELL chip, standard HDD, or Blu-ray drive)?

In other words, lets say you had a fantastic looking 360 game that you had spent a ton of time an money working on. Then you were told to port it to the PS3 but were given a huge load of money to work with. By fully utilizing the CELL processor to help the RSX, by streaming textures off the HDD drive, and by optimizing the PS3 as much as possible do you think the same game could look just as good or better on the PS3?

By the way, I want to thank you for coming on here and posting. Your comments have been very interesting and I appreciate hearing your view point on several matters.

Hardknock
01-Jan-2007, 00:45
joker454,

Let me ask you a question. You have indicated many times that you 360 games will look better than your PS3 games due to the 360 having more available RAM for you to utilize.

Do you believe that the extra RAM of the 360 (both due to EDRAM and lower OS requirements) will be more significant to producing the best possible graphics than the other factors that are in the PS3's favor (such as the CELL chip, standard HDD, or Blu-ray drive)?

In other words, lets say you had a fantastic looking 360 game that you had spent a ton of time an money working on. Then you were told to port it to the PS3 but were given a huge load of money to work with. By fully utilizing the CELL processor to help the RSX, by streaming textures off the HDD drive, and by optimizing the PS3 as much as possible do you think the same game could look just as good or better on the PS3?

By the way, I want to thank you for coming on here and posting. Your comments have been very interesting and I appreciate hearing your view point on several matters.


You can stream of a HDD on the 360 so that isn't in the PS3's favor. Blu-Ray won't increase graphic fidelity (it will allow you to hold more varied data but you are still limited by RAM). Cell would be the major difference I would think.

stats
01-Jan-2007, 00:49
Oh, seems like I missed this one. Gears does leverage unreal, but Insomniac has also been leveraging an engine that Naughty Dog had written and tweaked for many many years as well. Seems like a fair comparison to me.

But surely there's a reason why the UE3 is being licensed by a huge number of 3rd party developers for big moolah, and is garnering tons of hype as one of the industry's premier engines, while none of that could be said for Insomniac's Resistance? Clearly, I don't think any person in his right mind would say that Insomniac's engine is even close to comparable to UE3. Just ask anyone in the industry.

joker454
01-Jan-2007, 00:57
Do you believe that the extra RAM of the 360 (both due to EDRAM and lower OS requirements) will be more significant to producing the best possible graphics than the other factors that are in the PS3's favor (such as the CELL chip, standard HDD, or Blu-ray drive)?

In other words, lets say you had a fantastic looking 360 game that you had spent a ton of time an money working on. Then you were told to port it to the PS3 but were given a huge load of money to work with. By fully utilizing the CELL processor to help the RSX, by streaming textures off the HDD drive, and by optimizing the PS3 as much as possible do you think the same game could look just as good or better on the PS3?

It depends on your game. Hopefully I don't give it away, but in our case we need an entire scene to be visible at one time and the entire machines might is put to making that one scene looks its absolute best. There are no assets streamed in or anything like that, its basically load it all up, display it, and make it look as cool as possible. In that type of case yes, I don't think the PS3 will be able to match the 360's visuals because no matter what voodoo we do, when the PS3 is out of memory the 360 still has lots of breathing room left so we can add more to it.

In a streaming asset type game like GTA or Jak and Daxter the reverse might be true because the limit is not so much how much you can display at one given instant, but how many new assets are available to you over time. Bluray gives PS3 the advantage in this case because, using GTA as the example, as you drive around the PS3 could technically have 50gb's worth of assets available to it to stream in and display whereas 360 would have roughly 8.5gb or so.

Some additions to the above points:

- 'mission' type games can get around the disc space limit on 360 by shipping on multiple discs. Not an elegant solution, but doable.

- It's questionably whether or not many studios have the budget to fill a 50gb disc with assets.

- On multiplatform games like GTA, will they even bother since it's so much easier to make one set of assets that works on both platforms, and hence limited to 8gb or so.

- Correct me if I'm wrong in this, but from what I've heard streaming load times are slightly longer on PS3 because the optical head has a longer settling time, so it will be slightly slower at streaming than 360. I'm going on another devs info on this so I haven't verified it.

- Single platform games with huge budgets like Metal Gear don't need to care so they may very well fill the whole darn 50gb with stuff which would be awesome.

Ventresca
01-Jan-2007, 01:01
Those numbers seem "more or less" in line with what we've seen. They don't include the edram that the 360 has though, on PS3 we have to use some of the precious vram for frame buffers, don't need to do that on 360. The 360's memory advantage is huge currently, although this could change if sony trims back their memory needs. I think this is a much bigger issue to multi platform devs like myself. If you just do PS3 then you may not be feeling the pain as much. Taking a 360 game that looks nice and suddenly realizing that you have to free up 60+ megabytes of memory sucks ;( Likewise, taking your PS3 game and porting it to 360 will leave you with gobs of memory free which you may as well use to improve visuals. This is one of the reasons why I've been thinking lately that our 360 version will always look better than our PS3 version. We try to be clever as to which textures we downsize of course, so it's entirely possible that the typical game player won't notice.

Hi Joker454, can you comment on this ?

"For example, the texture formats. Compressed normal maps? That's an ATI patent, proprietary. You can't get that with nVidia hardware. We know it reduces cycles on ATI hardware which was why it was brought up a long time ago. There were questions about UE3.0 and the fact that it relies heavily on advanced texture technology like normal mapping.
The whole point of the the UE3.0 is to generate high poly models, and then simulate the geometry detail with normal mapping. The result is great looking models at a fraction of the vertex processing cost.
Will PS3 games benefit from this? Of course. His point is, Xenos benefits from it even more.
The unified shaders, for some reason lots of people were brushing that off as like a non feature. They kept quoting nVidia about how they said segmented shaders were just as fast and that Unified shaders weren't impressive etc.
Now nVidia uses unified shaders. Go figure. It's the only thing that allows games like Viva Pinata to have the look it does. Options are good.

Biggest thing? Memory. Memory. Memory. Memory. Memory. Memory.

You can never escape the confines of memory. PS3's biggest problem by far. Everything, is just peanuts in comparison. Nothing makes the gap between Xenos better, than the memory issues. (and bandwidth)

By RayOpSys on teamxbox forum"


Is it really true that Compressed normal maps are an Ati exclusive ?

babcat
01-Jan-2007, 01:03
Joker,

Thanks for the explanation. I appreciate you taking the time to answer my questions.

joker454
01-Jan-2007, 01:05
You can stream of a HDD on the 360 so that isn't in the PS3's favor.

The 360's default drive is 20gb, of which most is used by microsoft, game demos, movies, and all that other cool stuff you can get off of live. Only a small portion of it is useable by games, of which its typically used to cache data temporarily. PS3 on the other hand has 50gb at its disposal to stream in off a dual layer disc.

babcat
01-Jan-2007, 01:09
Joker,

Are there any other data types that you would have wanted to use (if the PS3 had more memory) or was it mostly just textures?

Carl B
01-Jan-2007, 01:14
Anyway, this thread is getting way off topic... I'm surprised xbd hasn't popped up yet!

Well... sometimes you wonder if trying to get things back on course just creates another vector for noise. :) But I totally agree.

There's a lot of activity surrounding this thread, and it's almost a little surprising; maybe that's from my linking to it on another forum to draw Joker here in the first place, maybe not (I notice some new members, lots of visitors, and rare posters hovering around this thread).

But it's just non-productive when people start chiming in simply to express a view they have, which a or b developer has just supported. These threads are valuable because it's people who know the ins-and-outs discussing with one another, and from that we can all learn. A bit of that is lost when the 'audience' starts jumping in, perceiving that the discussion is actually perhaps a proxy... arena battle?... between the two consoles, with the developers acting as champions for such.

Guys, this is not a 'battle.'

Anyway getting back on topic some more, I think one of the positives to be highlighted here in this thread is the extent to which artwork comes into what consumers perceive, almost exclusively, to be engine-related 'graphics' achievements. We know that art assets are becoming an ever larger component of the costs in this industry, and personally I hope that the appreciation of their role in game creation begins to sink in with the lay-folk that argue the engine side exclusively when they compare in-game images to one another.

scificube
01-Jan-2007, 01:52
Oh, seems like I missed this one. Gears does leverage unreal, but Insomniac has also been leveraging an engine that Naughty Dog had written and tweaked for many many years as well. Seems like a fair comparison to me.


The studios have shared ideas and technology as it goes with first parties but Insomniac is not using anyone else's engine.

scificube
01-Jan-2007, 02:10
off topic. I removed the post.

Carl B
01-Jan-2007, 02:47
Incidently, I want to give a thanks to 'the Deans' for giving some insights into the SPE task-management system being used in Heavenly Sword and other Sony published games.

Also ShootMyMonkey, I remember you talking about that art-pipe project you're working on now back in the day when you started it; seems to me that it's coming along quite nicely. :) (and great posts in general in this thread)

Anyway here's a question to get us back on that track for either Joker, Fran, or any other dev working on or with knowledge of the present back-end state of 360-centric engine development. Joker, in a previous post you wrote:

Incidentally this brings out one of the plusses of the rsx, targeting 1080p or 720p is trivial, its just a checkbox away. You have to tile on 360 to use 1080p which blows.

Now I don't believe you've mentioned whether your projects engine is licensed or proprietary as yet, but to the extent you can, what can you share about the level to which your game utilizes Xenos' tiling feature, and in recreating the development decision tree, what choices were made (in terms of possible alternatives) to bring your team to whatever that state is?

Also during the launch of 360, we of course all remember the discussions taking place around under-utilization and the problem stemming primarily from engine design not structured from the ground up with tiling in mind. Are we closer now to that paradigm? I know that the MS tools have been improving in that regard throughout the last year, but your comment on tiling Joker just sort of put me in the mindset... one year later, let's get a new snapshot on developer:tiling 'mastery.'

Obviously Fran, I'm excited about whatever you've got to add to this as well, since I know your engine is proprietary. :) And Joker if you guys *are* licensing, I think that whatever the case, it would make a good juxtaposition.

Acert93
01-Jan-2007, 03:41
Indeed and the nice thing about having a bunch of SPU with a good task system, is its entirely possible to mix both types of programs (as a GPU enhancer and for gameplay system).

For example an area where SPU can benefit RSX a fair bit, is as Dean talks about as a geometry modifier (trimming small triangles, doing progressive meshing, HO tesselation, etc.). You can do this on either part of frame across all SPUs, or dedicate 1 or 2 SPU to the job and leave the others for general tasks.

I suspect you could do a similar thing on 360 CPU as well, to maximise the 2nd threads of each core. Put a cooperative job system on the 2nd hardware thread of each core, that picks up VMX128 jobs to assist R500... If your main threads weren't doing much VMX ops, that might actually be a good way to get both good performance...

And this is why developer feedback on the forums is so valuable, especially not in the one-up scenario. Obviously both platforms have some upsides and downsides (some of which they both share in both cases as well), but hearing how developers approach these issues and different solutions to problems to get a shipping product is very informative. Thanks Dean.

Is it really true that Compressed normal maps are an Ati exclusive ?

He is most likely discussing 3Dc (http://en.wikipedia.org/wiki/3Dc). This format retains a fairly high image quality with ~4:1 compression compared to non-compressed 32bit normals (e.g. Toms (http://brit.tomshardware.com/2004/05/04/ati/page7.html)and Neoseekers (http://www.neoseeker.com/Articles/Hardware/Reviews/r420preview/3.html)parroting ATI press kit info (http://ati.amd.com/products/radeonx800/3DcWhitePaper.pdf)). A lot of software uses DXTC for normal map compression; 3Dc offers better quality with the same memory footprint IRC and is hardware accelerated so there is little impact on performance. Of course 3Dc can be used for other useful things, as ATI demonstrated in their very cool ToyShop demo.

The 360's default drive is 20gb, of which most is used by microsoft, game demos, movies, and all that other cool stuff you can get off of live. Only a small portion of it is useable by games, of which its typically used to cache data temporarily. PS3 on the other hand has 50gb at its disposal to stream in off a dual layer disc.

With the PS3 HDD being standard they also can stream some vital info from the HDD cache as well. I think this is one of the reasons it is standard.

Anyway getting back on topic some more, I think one of the positives to be highlighted here in this thread is the extent to which artwork comes into what consumers perceive, almost exclusively, to be engine-related 'graphics' achievements. We know that art assets are becoming an ever larger component of the costs in this industry, and personally I hope that the appreciation of their role in game creation begins to sink in with the lay-folk that argue the engine side exclusively when they compare in-game images to one another.

You are parroting Acert93 circa 2004 -- for shame! :P Comparing last gen (NV2A & GS; EE and a PIII/Celeron; memory architecture and resources) I think it is fair to say that the consoles are a) more similar than disimilar than last gen and b) in regards to performance envelopes they are more similar than disimilar, overall, than last gen. Obviously there are some differences, even big differences, in the current hardware and when doing a "checklist of feature performance" on each platform there are examples when there is a significant chasm in performance. But that said we are reaching certain diminishing returns in regards to certain techniques (e.g. the jump from a 1,000 poly model to a 10,000 poly model is visually more appearant than a 10,000 to 100,000 jump in most games and at the same resolutions; and likewise 2x the cloth physics performance is the difference between a 200x200 mesh and a 141x141 mesh). I do think we will see techniques on Cell that are much slower on Xenon and vice versa; ditto RSX and Xenos. How important, and how often these occur are really a matter of game design and the movement of the industry as well as tool design, what is determined to be sweet spots, and what resonates with consimers. Devs with the time and resources will also find ways to leverage the strengths and offload work to other system resources where there are bottlenecks. And matter of factly most consumers cannot tell the difference anyhow. In the long run we get faced with the reality that while Shrek 2 may have required a magnitude or more of rendering power of Toy Story 1, they both look great. And dare I say the technology in Shrek 1 would not have hindered the visual or creative abilities in Shrek 2 (just different design choices and compromises).

My real hope, as Cal stated in another thread, is that with the next consoles his main concern is how the hardware helps him churn out new, creative games with a lot of high quality content very quickly. At some point we will hit the situation of, "What is better: 1x 2m poly model in 1 month or 4x 1m poly models in 1 month?" This is where having Sony and MS in the market is pretty awesome because on the Sony side you now have a platform (CELL) and the leveraging of proven, robust, and well supported GPU technology (NV, CG, OpenGL) which is tackling this problem from a hardware equation to a large degree. What works on SPEs now should be able to be ported to Cell2, and for near linearly scaling code (e.g. lets say a physics engine) you now have a ton of resources to instantly scale your current platform code. MS is obviously taking the software tool route, as that is their expertise. Yet Sony isn't ignore software (even had a big software dev side aquisition in early 2005; and I often wonder how things would be different if Sony had strongly partnered with, or aquired, Epic) and MS isn't ignoring hardware partnerships. And I think consumers as well as publishers/developers benefit form this. Some pains, yes, but it keeps everyone honest and spurs development and investment into making the products better... Although I still think Panajav had the right idea of Xenos and Cell. The Playstation 360 :P

Anyhow, to a degree I am not confident that next gen will see the flip flop where performance takes a big back seat to creation. This gen there is still a major disparity in performance and technology being deployed by various studios; until we get to a point where we get easily deployable unified lighting and shadowing technologies (I can dream of RT and GI, but that is way not gonna happen in 5 years in realtime), stuff like physics for cloth, water, destroyed objects, etc is not only fast, but extremely fast and versatile on middleware, and a general shift where the tools and middleware allow content creation folks to do most of the design and heavy lifting with a focus on design and less on performance (within reason) I think we will still be in the current situation. Over the next decade, with the emergance of multicore solutions, I think it will become even more tech design oriented because so many resources have to be tailored toward getting the most out of the hardware instead of the hardware just doing what the artist wants.

Maybe we will never get to the place where the hardware and tools just allow people to be creative--draw, design, WYSIWYG, drop in code gaming, etc. I think stuff like XNA is dabbling in such and I think we all want to see more access and production from creative people... now I am OT so I will stop there. But the next decade will be very interesting. Hopefully developers will be pleasantly surprised by the hardware and software MS and Sony offer in 2010-2012.

wco81
01-Jan-2007, 05:03
There's SDK support for both out-of-the-box and custom SPU job management schemes, and internally we have a job manager that effectively plugs into this system which is available for teams operating as part of (or for) SCE WWS. So specifically, it's this custom job manager which Ninja Theory (*not* Team Ninja, as they are a group within Tecmo) are using.

Cheers,
Dean

So this internal job manager is purely a trade secret for SCE WWS developers?

Not available at all to third-party developers?

It would only be usable on the PS3 right, since it was designed for the architecture? (although if future consoles from competitors use a more Cell-like design, I guess it would be a competitive advantage to keep close).

Otherwise, to keep it internal might help SCE-published games in the PS3 market against third-party PS3 games. But for the benefit of the overall platform versus other platforms, it may be counterproductive?

Acert93
01-Jan-2007, 05:13
So this internal job manager is purely a trade secret for SCE WWS developers?

I hope that is not the case. I think everyone has learned from the [failed] approach Nintendo had with tools and resources with their little Dream Team fiasco. Getting as many devs on board as possible with equal access to tools is a bigger win that focusing on teams that are exclusive to your platform. This is one reaon Sony stomped Nintendo, so I doubt they would replicate it. But I could see certain Cell-based task managers and such being proprietary and only truly useful for PS3 development. In which case that makes sense.

Fox5
01-Jan-2007, 07:10
Hi Joker454, can you comment on this ?

"For example, the texture formats. Compressed normal maps? That's an ATI patent, proprietary. You can't get that with nVidia hardware. We know it reduces cycles on ATI hardware which was why it was brought up a long time ago. There were questions about UE3.0 and the fact that it relies heavily on advanced texture technology like normal mapping.
The whole point of the the UE3.0 is to generate high poly models, and then simulate the geometry detail with normal mapping. The result is great looking models at a fraction of the vertex processing cost.
Will PS3 games benefit from this? Of course. His point is, Xenos benefits from it even more.
The unified shaders, for some reason lots of people were brushing that off as like a non feature. They kept quoting nVidia about how they said segmented shaders were just as fast and that Unified shaders weren't impressive etc.
Now nVidia uses unified shaders. Go figure. It's the only thing that allows games like Viva Pinata to have the look it does. Options are good.

Biggest thing? Memory. Memory. Memory. Memory. Memory. Memory.

You can never escape the confines of memory. PS3's biggest problem by far. Everything, is just peanuts in comparison. Nothing makes the gap between Xenos better, than the memory issues. (and bandwidth)

By RayOpSys on teamxbox forum"


Is it really true that Compressed normal maps are an Ati exclusive ?

I believe there are some standardized formats that can be used, but 3dc is about twice as effective as the next available solution.

With the PS3 HDD being standard they also can stream some vital info from the HDD cache as well. I think this is one of the reasons it is standard.

The 360 harddrive can also stream, just developers either have to code for streaming from both the harddrive and disc or they have to cut down the user base they can sell to. (or cut down on what they stream for users without a harddrive)

MasterDisaster
01-Jan-2007, 07:17
Unreal Engine 3 was first revealed in 2004, and even then it was looking extremely polished and complete. So Gears, if truth be known was in development for atleast 3+ years, how much better do you think Resistance would of looked if Insomniac spent 3 years on a game engine before they starting creating game assett's?

Thats what annoys me when people compare PS3 game's to 360 one's that use UE3, UE3 is an extremely streamlined engine thats had years of work, 90% of PS3 launch game's use game engine's that id bet have'nt even had half of the time spent developing them as UE3.0 has..

I think that this is false at all, Unreal Engine 3 was in developing for years, but in a whole different platform, PC Windows.
They developed the engine mostly on Nvidia hardware (ok, they was first with ps3.0 and vs3.0), so the UE3 is far more fitting a ps3 machine, than a 360
it don't uses any of C1 advanced features, it don't tile at all, nor MSAA (devs says that it scales bad with msaa), nor memexport, nor cache locking, nor core locking, nor tessellator, nor procedural textures, nothing useful for the gpu of 360
and this is obvious, it is a *port* from another platform
it's as like final fantasy 11 on 360 would be a wonderfull game graphically because squarenix was working on their engine for tens of years on ps1/2/PC
there are not sense at all
Cliff and the rest of the team received the dev kit with Xenon and Xenos almost an year ago (end september if I rememeber well, everything about GOW before this date was showed on a PC, rumored as PC with SLI of 6800 ultra, included the E3 05 demo), so they port the engine from pc to a machine as 360 is, in only a year, where is the advantage that you are talking about?
And if I remember well (this is the case) Cliff says that GOW don't uses a lot of features of the 360, and this include Xenon too, this makes a lot of sense
(would be very very nice if Cliff start to write here, joker454 welcome to the board NB)

popper
01-Jan-2007, 07:31
Perhaps I'm being silly, but they mention HLSL being compiled to both architectures. Surely this is the simplest give-away, HLSL is for DirectX (360) not OpenGL (PS3)! This is continuously mentioned (compile and run) throughout the posts. It's just another Xbot

true, but theres apparently now an open source converter for that.
http://www.powerdeveloper.org/forums/viewtopic.php?t=915
"popper said:ATI offers DirectX - OpenGL converter for the x86.

perhaps some people might like to look at the possibility of adding PPC conversion options?.

interesting non the less......... "

"Graphics chip maker ATI Technologies has released HLSL2GLSL, an open source application designed to help programmers convert graphics code optimized for Windows’ DirectX 9 Application Programming Interface (API) to OpenGL, which is used on the Mac. Binaries for Mac OS X and Windows are available for download."

talking about HLSL and gfx in general for PPC/CELL , it seems plenty of game devs etc are happy to use the Altivec/spe's as a gfx engine but has anyone even started to refactor one of the 3D gfx bases 'OpenGL ES' http://www.khronos.org/opengles/spec/ perhaps ?, to use this power inside gentoo PPC linux for instance ?, if not why not?, no interest!.

[edit]

i found this latest pdf interesting for instance..
http://www.khronos.org/developers/library/kmaf_cambridge_2006/High-performance-3D-for-handhelds_NVIDIA_Dec06.pdf
lol "It can be *VERY* difficult to throw things at the chip fast enough" seems its a problem at both ends of the spectrum (16k although i like ZX81 myself) 8)

seeing as the world is now waking up to the PPC cores, personally i think they should stop piddleing about and just put a cheap KiloCORE on all new kit incase some insightful programmers need to re-invent some innovation.
http://www.technewsworld.com/story/49772.html

Acert93
01-Jan-2007, 07:39
While I agree that the Xbox 360 has a lot of leg room and has hardly been exploited to its full potential (2007-2008 is my long held guess for ground up engines with art geared toward the platform/engine strengths) I think these statements are waaay to strong.

it don't uses any of C1 advanced features, it don't tile at all, nor MSAA (devs says that it scales bad with msaa), nor memexport, nor cache locking, nor core locking, nor tessellator, nor procedural textures, nothing useful for the gpu of 360

UE3 may not be designed to use many of Xenos centric features, but it is overboard to say "nothing useful". First is we have to assume that some features will not be performant in all situations; likewise we do know some don't necessarily play nice together (e.g. tiling and streamout). Finally a GPU is all about putting pretty stuff on screen. For all the lashings some give GOW for technical reasons, the bottom line is UE3 is offering not only great tools but a rendering engine that does quality shadows (and self shadowing) as well as very high resolution textures and normal maps. My arguement for UE3 has been that while it isn't doing SPE voodoo or Vertex Texturing and Variance Shadow Mapping, or whatever new technique, the rendering technologies it is using are all very high quality. It is a matter of tradeoffs (lower quality new technique or a boat load of older proven techniques), and UE3 seems to have found a nice sweet spot with the GOW design. The few (any) games in 2006 have consistantly matched the end result (large part art, but you cannot ignore the technology pushing the art either) is a nod that, for at least 2006, UE3 was a good compromise for quality and technology and getting a nice looking product out. And games like Mass Effect do nothing to diminish that impression.

So argueing that UE3 does nothing useful for the 360 GPU isn't true. It is pushing texturing, shading, fillrate, etc like any other game. Are there more elegent techniques that will produce better IQ results in the future? SURELY! Are some of the technologies untapped in Xenos useful for such? Most likely! But there is a large chasm between "nothing usefull" and "room to grow". It is pretty clear with typical game dev schedules and when games began development and when final beta kits hit in late Summer 2005 that nothing out yet it a ground up effort with all the kinks worked out and a good idea of how to best use the hardware to get the best performance/iq as well as picking art styles that pick. Xbox fans don't need to defend this. It can take 4-5 years before that happens. It is a given.

If people really wanted to complain, maybe we can ask MS why so many titles are using UE3 instead of funding more efforts to exclusively hit the hardware hard? :twisted: Sony seems to be doing a good job of getting their exclusive titles to use the SPEs, so why MS would create a design like Xenos that requires some TLC (tiling for example) and then select middleware that doesn't really match the featureset well... hmmm. But I think the reason is simple: UE3 has the tools to push software development of next gen titles at a quickened pace, there is little to compete with it, and MS is about the software with their early launch strategy. Tiling, vertex texturing, memexport, datastreaming, tesselation, etc are things devs can figure out in years 3,4,5, and 6... at least that is how I interpret the signals I am getting from Redmond. Of course they can be hard to see sometimes from Auburn. :lol:

deathkiller
01-Jan-2007, 10:07
I hope that is not the case. I think everyone has learned from the [failed] approach Nintendo had with tools and resources with their little Dream Team fiasco. Getting as many devs on board as possible with equal access to tools is a bigger win that focusing on teams that are exclusive to your platform. This is one reaon Sony stomped Nintendo, so I doubt they would replicate it. But I could see certain Cell-based task managers and such being proprietary and only truly useful for PS3 development. In which case that makes sense.
As DeanoC said SPURS is the job manager included in the SDK for everyone but Ninja Theory use a more avanced version from the SCE WWS code base. From what I have read Sony have two diferent codebase the one included in the SDK and other one for first/second partys (the SCE World Wide Studios code base).

-The code base for third partys is more multyplataform oriented. Sony have software dev team/s developing only for that codebase. PSSG is a mayor example of this (http://www.beyond3d.com/forum/showthread.php?t=35010) (http://www.beyond3d.com/forum/showthread.php?t=35010%29).

-The code base for first/second partys is more PS3 expecific and includes both developed by Sony libraries and develped by teams operating as part of (or for) SCE WWS. The only visible result of this is the "flag algoritm" (Motorstorm, GTHD and Heavenly Sword flags look mostly the same).

If any developer can comment what they think about the diferent codebases and their future that would be appreciated. (Sorry about my bad English, it isn't my first language)

-tkf-
01-Jan-2007, 10:10
- 'mission' type games can get around the disc space limit on 360 by shipping on multiple discs. Not an elegant solution, but doable.

- It's questionably whether or not many studios have the budget to fill a 50gb disc with assets.

- On multiplatform games like GTA, will they even bother since it's so much easier to make one set of assets that works on both platforms, and hence limited to 8gb or so.

- Correct me if I'm wrong in this, but from what I've heard streaming load times are slightly longer on PS3 because the optical head has a longer settling time, so it will be slightly slower at streaming than 360. I'm going on another devs info on this so I haven't verified it.

- Single platform games with huge budgets like Metal Gear don't need to care so they may very well fill the whole darn 50gb with stuff which would be awesome.

More discs = more complexity in the development phase, but again those that need more discs are rarely hindered by budgets. For the smaller developers though it´s easier to compromise and aim for one disc.

You don´t need to fill 50GB worth of data in order to claim "superior storage technology" if you are in sony camp. Anything beyond what can be on a DVD is enough. 10GB would still not fit on a DL DVD :-)

Afaik the DVD vs BluRay streaming speed, seek times etc is dependent on SL DVD or DL DVD vs BluRay. Being that SL DVD is always faster than BluRay while DL DVD is on par with BluRay and sometimes Slower.

Unless GTA is memory limited or "stream limited" it should be fairly easy for them to use more storage for higher quality textures though the difference wouldn´t be mindblowing (but surely enough to tick it off on the box :-))

One question, you seem to indicate that the memory difference is one of the most important differences, At most wouldn´t the difference be something like 5% ?

Fran
01-Jan-2007, 10:40
Those numbers seem "more or less" in line with what we've seen. They don't include the edram that the 360 has though, on PS3 we have to use some of the precious vram for frame buffers, don't need to do that on 360

This is not entirely correct. The EDRAM is a scratch pad memory, not storage memory, you can't really store anything in there, you render to, immediately resolve, clear, rinse and repeat. I wouldn't count it as available memory. You still need to resolve the EDRAM content to a framebuffer in main memory that will be displayed. Some memory can still be saved from the fact the framebuffer in main memory is not using MSAA (EDRAM will resolve samples) and with correct timing you don't need to double buffer it. But a framebuffer ready to be displayed is still present in main memory.

AbbA
01-Jan-2007, 11:30
..... I also can't see anything that can't be done with a RSX .....

Also because you don't know RSX?

Shifty Geezer
01-Jan-2007, 11:39
Also becouse you don't know RSX?More likely because they're fundamentally the same design. They work the same way fundamental, transforming vertices and rendering fragments, just with slight tweaks about how they go about it. Kinda like a left-hand drive car versus a right-hand drive car. Both can turn left and right corners, but each has an viewing advantage turning one way and disadvantage the other. Each GPU will be more efficient in some tasks, but there aren't many that can't be done at all. Given the UE3.0 engine and GeoW, technically there's nothing going on there that either GPU can't handle, because it's a fairly generic engine.

In a customized, single patform engine, the differences will become more notable, such that analogy might shift to being between a Lotus Elise and a large Corvette. Both still get round the track quickly by burning fuel in an internal combustion engine, but one relies on lightweight agility and the other raw power. Not that I'm likening either GPU to either car - I'm just trying to show how fundamentally they are the same and you can get the same job done.

DeanA
01-Jan-2007, 12:37
So this internal job manager is purely a trade secret for SCE WWS developers? Not available at all to third-party developers?
Well, it's a bit harsh to say it's a 'trade secret', to be honest. It's just code that we have internally - SCE WWS is kinda separate to the bit of SCEI that deals with PS3 SDK development.. we're busy working on stuff for SCE-published titles. They're busy working on stuff for the platform in general (and all the developers using it). I guess the main reason we have it isn't because it's some kind of miracle system (it's good, but it ain't gonna magically make everything just *run* on SPUs!), but because it helps various SCE WWS developers use a common job framework - which further promotes code sharing between the different studios. If all of us used a different job manager, it would make it difficult to share SPUs to the extent we do now.

As was said before, this sits on top of (or inside, I guess) the SCEI released SPU runtime system.. so there's nothing to stop other developers from doing the same thing.. infact, I'd be surprised if the larger devs (with multiple PS3 titles in production) hadn't already standardised on a single job management scheme for exactly the reasons I stated above.

Cheers,
Dean

DeanA
01-Jan-2007, 12:49
From what I have read Sony have two diferent codebase the one included in the SDK and other one for first/second partys (the SCE World Wide Studios code base).
I'll get straight to the point on this.. your post makes it sound like SCEI have one magical SDK for 1st/2nd party teams, and one slightly crummier SDK for 3rd parties.. this is absolutely not the case. We *all* use the SCEI supplied SDKs.

As far as multiplatform-style development goes, as far as I'm aware (and hey.. it's New Years's Day, so my head is a little rough at the moment), PSSG is the only thing that falls into that category. And even that is not a core component of the distributed SCEI SDK.. it's an optional download.

libraries and develped by teams operating as part of (or for) SCE WWS. The only visible result of this is the "flag algoritm" (Motorstorm, GTHD and Heavenly Sword flags look mostly the same).
I don't know how you came to that conclusion (in short, I'd love to know what you read in order to come up with the details in your posting), but it's completely wrong. That's like me saying because all those games have characters that are skeletal, they must be using the same skeletal animation and rendering system.

And besides, flag systems are 10 a penny.. they're not the hardest thing to do on any system..

Cheers,
Dean

Shezad
01-Jan-2007, 13:00
As DeanoC said SPURS is the job manager included in the SDK for everyone but Ninja Theory use a more avanced version from the SCE WWS code base. From what I have read Sony have two diferent codebase the one included in the SDK and other one for first/second partys (the SCE World Wide Studios code base).


This is not exactly true, I don't think Sony has 2 different SDKs, more likely internal studios share the same kind of technology



-The code base for first/second partys is more PS3 expecific and includes both developed by Sony libraries and develped by teams operating as part of (or for) SCE WWS. The only visible result of this is the "flag algoritm" (Motorstorm, GTHD and Heavenly Sword flags look mostly the same).


The SDK is almost the same but Sony has very talented teams that can customize the code and share it, probably EA for example does the same.

almighty
01-Jan-2007, 14:17
Oh, seems like I missed this one. Gears does leverage unreal, but Insomniac has also been leveraging an engine that Naughty Dog had written and tweaked for many many years as well. Seems like a fair comparison to me.

Yes Insomniac did use ND's engine, but that was on PS2, were discussing PS3. Resistance is using a modified version of Racthet and Clanks engine ( Witch is based on ND's PS2 engine ) so id assume there is still some PS2 hardware limitaion's present in the engine itself. Comparing a next generation game that use's a tweaked last generation game engine that had little to no support of any next generation effects in the first place to an engine that was prupose built for the next generation hardware is i feel extremely unfair. :)

nAo
01-Jan-2007, 14:20
The only visible result of this is the "flag algoritm" (Motorstorm, GTHD and Heavenly Sword flags look mostly the same
Where did you get this?! good fantasy! Our flags code was written internally..

Bad_Boy
01-Jan-2007, 16:59
Resistance is using a modified version of Racthet and Clanks engine ( Witch is based on ND's PS2 engine )

Where did you hear that from? I always thought Ratchet & Clank (PS3) was using the resistance engine, just improved for obvious reasons like time. Neither of which was developed by ND.

TTP
01-Jan-2007, 17:05
Where did you hear that from?

GameFAQs message boards probably

almighty
01-Jan-2007, 17:25
Where did you hear that from? I always thought Ratchet & Clank (PS3) was using the resistance engine, just improved for obvious reasons like time. Neither of which was developed by ND.

:???: Reistance is using a modified version of PS2's R&C engine, and PS2's R&C engine is a modified version of ND's Jak game's engine. How could they use the PS3 R&C engine when the game has'nt been properly unveild? Maybe i did'nt explain myself very well in my post :???:

DeanoC
01-Jan-2007, 17:40
This is not exactly true, I don't think Sony has 2 different SDKs, more likely internal studios share the same kind of technology




The SDK is almost the same but Sony has very talented teams that can customize the code and share it, probably EA for example does the same.
As Dean has stated there is one SDK for all, on top of that developers build libraries etc. Most large publishers have some libraries that can be used by any of there teams, for example EA has Renderware tech that its teams can use if they want. Same for Sony WWS (who is the games publisher side of Sony and has almost nothing to do with the SCEI PS3 maker side of the company), teams who are published by them (which obviously includes 1st parties but also people like nt and evo) have access to that shared tech.
WWS is not that different from EA with regard access to 'SCEI' (which most people mean when they say 'Sony').
Its also worth noting, that which bits a team using it upto them. In some cases we choose not to use WWS shared tech, and use our own or buy middleware in.

BTW flag tech isn't shared. But given its a standard verlet system its not surprising they look the same as other.

DeanoC
01-Jan-2007, 17:51
:???: Reistance is using a modified version of PS2's R&C engine
Erm I'm not sure thats a very accurate statement...

Dr. Nick
01-Jan-2007, 17:52
Question for the devs: How effective is 3Dc on the Xenos and is there any reason not to use it for Xbox 360 games that are exclusive to the platform. Is there a catch to using it?

TurnDragoZeroV2G
01-Jan-2007, 17:52
:???: Reistance is using a modified version of PS2's R&C engine, and PS2's R&C engine is a modified version of ND's Jak game's engine. How could they use the PS3 R&C engine when the game has'nt been properly unveild? Maybe i did'nt explain myself very well in my post :???:

Hm? According to this (http://blogs.ign.com/Ted-Insomniac/2006/09/), it was simply the case of Naughty Dog and Insomniac sharing some code (which went both ways). Nothing about modified engines at all. I couldn't find anything on it, but AFAIK, the Resistance engine was all-new as well, built from the ground up for PS3. How often are components of a PS2 engine going to be useful for PS3 development (with the aim of being competetive or even better than most other engines out there on release)?

Bad_Boy
01-Jan-2007, 18:14
:???: Reistance is using a modified version of PS2's R&C engine, and PS2's R&C engine is a modified version of ND's Jak game's engine. How could they use the PS3 R&C engine when the game has'nt been properly unveild? Maybe i did'nt explain myself very well in my post :???:

I always thought as TurnDragoZeroV2G said, resistance was built from the ground up for the PS3. And Ratchet & Clank for the PS3 (coming in 07 I believe), is an extention of the resistance engine as there has been more development time to work on it. I dont think either games have to do with ND code or any PS2 engines.

Darkon
01-Jan-2007, 18:19
Where did you hear that from? I always thought Ratchet & Clank (PS3) was using the resistance engine, just improved for obvious reasons like time. Neither of which was developed by ND.


Ratchet & Clank is using their up coming engine named Isla or something like that , i don't quite remember

Acert93
01-Jan-2007, 18:44
This is not entirely correct. The EDRAM is a scratch pad memory, not storage memory, you can't really store anything in there, you render to, immediately resolve, clear, rinse and repeat. I wouldn't count it as available memory. You still need to resolve the EDRAM content to a framebuffer in main memory that will be displayed. Some memory can still be saved from the fact the framebuffer in main memory is not using MSAA (EDRAM will resolve samples) and with correct timing you don't need to double buffer it. But a framebuffer ready to be displayed is still present in main memory.

Thinking out loud.

A 720p 4xMSAA framebuffer is ~ 30MB. A fully resolved framebuffer is (taking a stab at this) ~ 3.5MB? Someone feel free to correct my math.

I think this is where the majority of the difficulty in discussion forums come in. Depending on how you look at things, and how resources are being used, and how things are stated can make a big difference in how people perceive things.

e.g. Fran notes that there are savings, but there is still a small framebuffer in system memory. His answer wasn't the simplest but was fair and accurate as far as I could tell. I think scratch pad is a better description of what eDRAM does, but it does seem one way or another (indirectly) it does save some system memory. But this is one of the reasons 1-to-1 comparisons are so difficult is because the PS3 and Xbox 360 use resources differently. The classic example we always bicker about is system bandwidth for graphics. It isn't accurate fair to say RSX has ~45GB/s of bandwidth and Xenos 22.4GB/s of bandwidth for graphic rendering; likewise it isn't accurate to use the 278.4GB/s spec for the Xbox 360 for graphic rendering either (because not all that bandwidth is available to all graphic rendering tasks and the system pool is also shared with the CPU).

I guess what I am trying to say is that looking at the workflow and how the design impacts available resources on each machine is different depending on what it attempting to be accomplished. And I think this is where many of the misunderstandings and disagreements we see on the forums come from.

Fran
01-Jan-2007, 19:20
A 720p 4xMSAA framebuffer is ~ 30MB. A fully resolved framebuffer is (taking a stab at this) ~ 3.5MB? Someone feel free to correct my math.

That's correct. You basically save two 4X (or 2X) render targets (colour and depth), and only need a resolved 1X frambuffer, unless you also need to resolve the depth buffer for post processing, which is common. But it must also be said that you if you are doing post processing, and there's really no reason to not have a post processing step nowadays, you can probably easily reuse that video memory for other purposes on PS3 after you have manually resolved them. In this common scenario, there probably wouldn't be a big memory save in having EDRAM.

e.g. Fran notes that there are savings, but there is still a small framebuffer in system memory. His answer wasn't the simplest but was fair and accurate as far as I could tell. I think scratch pad is a better description of what eDRAM does, but it does seem one way or another (indirectly) it does save some system memory. But this is one of the reasons 1-to-1 comparisons are so difficult is because the PS3 and Xbox 360 use resources differently. The classic example we always bicker about is system bandwidth for graphics. It isn't accurate fair to say RSX has ~45GB/s of bandwidth and Xenos 22.4GB/s of bandwidth for graphic rendering; likewise it isn't accurate to use the 278.4GB/s spec for the Xbox 360 for graphic rendering either (because not all that bandwidth is available to all graphic rendering tasks and the system pool is also shared with the CPU).

I wasn't very clear in my post. I was under the impression that EDRAM was seen as the 'framebuffer', which is not really the case since the EDRAM is a write-only memory and nothing can read from it. The EDRAM can 'write itself' (resolve) to main memory. The DAC can only read the framebuffer from main memory where it effectively lives.

On the other hand, it's true that rendering to EDRAM will save some memory compared to a more traditional architecture, but you pay this save in terms of having to deal with predicated tiled rendering. There's no free supper :)

deathkiller
01-Jan-2007, 19:43
Sorry for talking like I knew something, I will go back to read only mode...

Shezad
01-Jan-2007, 19:53
Sorry for talking like I knew something, I will go back to read only mode...

There is no problem eh to say something wrong or non exact, I do it more often than you :D

Jawed
01-Jan-2007, 21:34
A 720p 4xMSAA framebuffer is ~ 30MB. A fully resolved framebuffer is (taking a stab at this) ~ 3.5MB? Someone feel free to correct my math.
On RSX, like all NVidia GPUs of that generation, the frontbuffer retains its AA data for its entire lifetime, with the RSX display hardware resolving the AA data to produce the picture on screen with every refresh of the screen (e.g. 60 hz), regardless of the frame render rate (say 30fps).

So, as I understand it, the 720p "framebuffer" consists of ~30MB backbuffer during rendering and a separate ~30MB frontbuffer for actual display. After every frame has been rendered, and now needs to be displayed, the memory areas swap roles.

Jawed

DeanA
01-Jan-2007, 21:38
On RSX, like all NVidia GPUs of that generation, the frontbuffer retains its AA data for its entire lifetime, with the RSX display hardware resolving the AA data to produce the picture on screen with every refresh of the screen
That is incorrect, as the auto resolving of AA buffers on output is/was a function of the display controller on nVidia cards.. not of the GPU itself. Front buffers on RSX have to be of the real display resolution (eg: 1280x720) rather than any AA-adjusted variant.. which means applications are responsible for the resolve via a full-screen pass.

Cheers,
Dean

Jawed
01-Jan-2007, 21:44
Thanks for correction :smile:

Jawed

Acert93
01-Jan-2007, 22:24
That is incorrect, as the auto resolving of AA buffers on output is/was a function of the display controller on nVidia cards.. not of the GPU itself. Front buffers on RSX have to be of the real display resolution (eg: 1280x720) rather than any AA-adjusted variant.. which means applications are responsible for the resolve via a full-screen pass.

Cheers,
Dean

To understand you correctly, does that mean a ~28.1MB backbuffer (720p 4xMSAA 32bit and Z) is then resolved to ~3.5MB frontbuffer (or smaller for 24bit?) that is used as the framebuffer displayed on screen?

Jesus2006
02-Jan-2007, 00:31
So now im a little bit confused (more than before ;):

My sum up, cmiimw!:

Xenos has a rendering advantage by saving memory when traditional rendering is done. When post buffer effects are used (like in every game nowadays) this advantage is gone since the edram processed scene has to be written back to the GDDR via a rather slow bus?

RSX on the other hand has the advantage that a frontbuffer resides in VRAM all the time and can thus be processed easier since no additional transfers to another buffer (edram) have to be performed? Imo that sounds like rendering on PS3 is alot easier to do, with exception for non-HDTV resolutions (not tiling required) where AA is applied on, as it is done in many current 360 games (PGR3, Tony Hawks, CoD3...)?

My conclusion:

All the memory problems on PS3 result from the OS, not the non-exisiting EDRAM? Guess this cannot be answered because of NDAs...

Laa-Yosh
02-Jan-2007, 00:55
When post buffer effects are used (like in every game nowadays) this advantage is gone since the edram processed scene has to be written back to the GDDR via a rather slow bus?

That rather slow bus is as fast as the PS3's VRAM bus... It's just that in the X360 the same bus has to provide the CPU-RAM bandwith as well.

Acert93
02-Jan-2007, 01:25
You completly forgot the poin of EDRAM is not to free up memory but to provide FREE AA and if i am not mistaken it can also provide free HDR.

Yes on his mixing and mashing of space & performance (I will let a dev answer most of his questions), but the point of the eDRAM is not to give free AA. The goal of eDRAM is to remove the backbuffer bandwidth, which is a large bandwidth client, from the main system memory. The backbuffer is fairly small, but consumes a disproportional amount of bandwidth for its footprint. So the eDRAM basically isolates a lot of the ROP activity. So that is the purpose of eDRAM. Some of the benefits of such is that the eDRAM provides just enough bandwidth for 4xMSAA as well as 4Gigapixels of fillrate. There is no bandwidth crunch and contention. Likewise the ROPs take this into consideration and can do single cycle 4xMSAA so there is no computational bottleneck either. Of course at 720p with 4xMSAA there is the hurdle of tiled rendering which does have a performance hit. How big has many variables.

As for HDR, there are a number of HDR is a group of technologies (iris effects, bloom, multiple render targets with high percision blending, etc) and has a number of different ways to accomplish such. There are shader based HDR schemes (like NAO32 in Heavenly Sword and Valve's approach in HL2: Lost Coast), and more specialized hardware based approaches that use FP16 and FP10 filtering and blending. The Xbox 360 can use FP10 based approaches with no penalty as they consume typical footprint and bandwidth, but FP16 formats consume 2x the bandwidth and memory footprint and are 2x as computationally expensive. FP16 based HDR formats are slower to process as well as require more tiles.

In a nutshell eDRAM does more than "free MSAA" and has a lot of benefits even when MSAA is not used -- but also has some design "gotchas" that require some elbow grease when using MSAA at HD resolutions -- and HDR is fairly unrelated to MS's choice of eDRAM unless talking about FP16, and in which case eDRAM may help in some areas (like bandwidth) but doesn't help in regards to tiling or computational bottlenecks in the ROPs.

EDIT: Marik2 added the comments about eDRAM being used for more than just MSAA after I posted, all is good.

Rash'
02-Jan-2007, 01:46
My knowledge of software development isn't as educated as some on these forums, but I feel I should offer my two cents to see if I can add to the discussion. So tell me if I've misunderstood anything.

It appears to me that the architectures of the two consoles are very different and that in comparison PS3 is the least understood not just because of time but also because of the radical nature of it's design. It seems unfair at this stage to label PS3 as the least able of the two, particularly if you're applying the rules of one architectural design to a system that clearly hasn't been designed with the same thought process. It seems memory is the current bug bearer in the discussion which in comparison to development on 360 appears to be a genuine concern. But could it not be that to tackle the problem, rather than look at it from the perpective of work conducted on Micorosft's console, the developer has to address his/her understanding of the issue by looking the particularities of the PS3 design?

Of course I may just be stating the obvious , but it does appear that some are looking at this from a comparitive deficiency angle which to me seems a little harsh considering the state of third party develop on PS3 at the moment.

Acert93
02-Jan-2007, 01:55
It appears to me that the architectures of the two consoles are very different and that in comparison PS3 is the least understood not just because of time but also because of the radical nature of it's design.

I think that "radical" only applies partially, mainly to CELL. RSX is an adaptation of a PC GPU and is fairly straight forward and 'traditional' evolution of what has been happening in the PC GPU space over the last half decade. Developers have had access to the general overall architecture that predates RSX since 2004 (NV40) and G70, which RSX is derived and makes substantial improvements and efficieny gains on NV40, was released in early Summer 2005. RSX also is using fairly mature APIs and tools like OpenGL derivatives and Cg.

Of the GPUs and CPUs on both consoles I think many would agree with me that RSX is the least radical design; it probably is also the best known in regards to what it can do, and what works well and what doesn't. Just my 2 cents on that :smile:

Jov
02-Jan-2007, 02:03
Yes on his mixing and mashing of space & performance (I will let a dev answer most of his questions), but the point of the eDRAM is not to give free AA. The goal of eDRAM is to remove the backbuffer bandwidth, which is a large bandwidth client, from the main system memory. The backbuffer is fairly small, but consumes a disproportional amount of bandwidth for its footprint. So the eDRAM basically isolates a lot of the ROP activity. So that is the purpose of eDRAM. Some of the benefits of such is that the eDRAM provides just enough bandwidth for 4xMSAA as well as 4Gigapixels of fillrate. There is no bandwidth crunch and contention. Likewise the ROPs take this into consideration and can do single cycle 4xMSAA so there is no computational bottleneck either. Of course at 720p with 4xMSAA there is the hurdle of tiled rendering which does have a performance hit. How big has many variables.

...

Slightly OT, but it has been mentioned with the latest firmware update the XBox360 can display 1080p (http://uk.xbox360.ign.com/articles/733/733658p1.html).

Thus if a project targets 1080p native (no up scaling) support and an engine designed from the ground up with Predicated Tiling, is this possible on the Xbox 360? If so what kind of challenges and trade-offs?

TurnDragoZeroV2G
02-Jan-2007, 02:24
Just considering the performance hit, based on how many tiles you'd need... 720p 4xMSAA is 3 tiles (28.x MB), while 1080p 0xMSAA would be 2 tiles,, and 4 tiles for 2xMSAA, and 7 for 1080p. You can see how this really adds up. Performance penalties will really depend on how the engine deals with tiling, but if that as low as 5% hit for 3 tiles holds up, depending on how it scales, it could become pretty extreme. In other words, probably never any 4xMSAA, though 2x would certainly be possible.

Jov
02-Jan-2007, 02:38
...
Of the GPUs and CPUs on both consoles I think many would agree with me that RSX is the least radical design; it probably is also the best known in regards to what it can do, and what works well and what doesn't. Just my 2 cents on that :smile:

From a component only perspective this may be the case, but from the view of the console architecture as a whole I would disagree. It’s analogous to viewing the GS in the PS2 as a crippled GPU compared to the XGPU (or any modern PC GPU in the last 6 or so years), when it was designed to work with the EE.

Traditionally, the GPU handled to all the heavy lifting when it comes to graphics, but if the SPU(s) can reduce the load by carrying things like backface and or occlusion culling more effectively, then the RSX has room for more exploitation. The same apply for the Xenon/Xenos relationship.

Regarding the RSX been best known, I often wonder if this is truly the case and that if there is a bit more to it then we are led to believe.

"Nerve-Damage"
02-Jan-2007, 02:52
The only visible result of this is the "flag algoritm" (Motorstorm, GTHD and Heavenly Sword flags look mostly the same

Where did you get this?! good fantasy! Our flags code was written internally..

I think he may have misinterpreted the IGN Gran Turismo HD Concept quote (see bottom) in the wrong way. Possibly thinking all developers are sharing the same code/algorithm to generate there flag movement.

IGN (http://ps3.ign.com/articles/752/752330p1.html)
The game has also been spiced up with some nice effects, like an impressive glare as you emerge from the track's tunnel, and those waving flags that PS3 developers seem to love (see MotorStorm and Heavenly Sword).

Acert93
02-Jan-2007, 03:05
From a component only perspective this may be the case, but from the view of the console architecture as a whole I would disagree. It’s analogous to viewing the GS in the PS2 as a crippled GPU compared to the XGPU (or any modern PC GPU in the last 6 or so years), when it was designed to work with the EE.

The PS3 isn't that radical though in regards to general architecture. CPU with memory (XDR System memory) and GPU with memory (GDDR3 VRAM) with some FlexIO voodoo connecting them. Sounds a lot like a PC, especially when you consider that the PPE is a PPC chip.

Where PS3 is radical is in the CELL SPEs; instead of multiple traditional CPU cores like the PPE, it has 1 PPE and 7 assymetric processors that are simpler (e.g. no branch prediction and no L2 cache) and require some extra elbow grease (DMAs to the system memory) but have an insanely fast local store (memory) that make them little monsters when you can fit within the confines of the memory (and even better SIMD). No doubt, that is radical -- both in terms of departure and in coolness :cool:

The Xbox 360 has 3 CPU cores (PPC) with shared L2 cache; these CPUs connect to a unified memory pool shared with the GPU. Like Cell the hurdle of multicores is fairly new to many developers and is a departure from the Xbox, GC, gaming PCs (up to 2005) and in many ways the PS2. For Xbox developers there are a lot of other little issues like big/little endian, the PPC ISA, VMX units and libraries, in order design, and so forth. Not really radical, but different. The GPU on the other hand has its feet in both pools. It is an SM3.0 GPU using a customer DX and HLSL. But on the other hand you have quite a few unique features not found in previous GPUs (call it DX9.5; unified shaders, coherant memory read and writes, tesselation, etc), shared memory pool (like the Xbox, but unlike the PC), and a small eDRAM pool with 256GB/s of internal bandwidth and 32GB/s bandwidth between the two GPU chips. So now you have this eDRAM, and logically predicated tiling, and can toss in architecturally the ability for the CPU to stream L2 data to the GPU directly. So on a basic level the Xbox 360 IS very traditional and not radical at all--PPC CPUs, single memory pool, and GPU with eDRAM. Yawn. But the proprietary features and design are quite a bit different and have been hardly touched.

And hence the dovetail with the post I replied to. The arugement was that the PS3 was very radical and not well known. Of the major components on all the systems RSX is by far the best known and understood. Is there headroom? Of course! Are there better ways to use RSX--even without Cell help--than currently being shown. Absolutely. Is this because RSX isn't as well as understood as the Xbox as the post I replied to indicated? No.

Regarding the RSX been best known, I often wonder if this is truly the case and that if there is a bit more to it then we are led to believe.

Yes, it is G80. A driver update will resolve the confusion... hello Brimstone! :razz:

From a practical perspective this isn't realistic, not with developers like Joker asking Sony, "How can I best get the most out of RSX?"

Traditionally, the GPU handled to all the heavy lifting when it comes to graphics, but if the SPU(s) can reduce the load by carrying things like backface and or occlusion culling more effectively, then the RSX has room for more exploitation. The same apply for the Xenon/Xenos relationship.

So we don't understand either :P

I agree that SPEs can be leveraged for certain graphic work. "Traditionally" CPUs did a lot of this, but GPUs offloaded a lot of this. There seems to be some rebalancing in both directions (both consoles having the CPUs being capable of more work; on the PC DX10 allowing the GPU to do more without CPU dependance). So there is some learning to go on on both ends.

I would argue that PS3 devs will get a chance to take a hack at this before Xbox devs. First is because RSX is a pretty well known quantity, and second because the SPEs open up a lot of doors. I think devs will be playing with Xenos for a while (ditto PS3 devs with SPEs) and use the CPU for other stuff... all that insignificant stuff like game code :lol:

Graham
02-Jan-2007, 03:09
Does xenos support 3Dc or 3Dc+?

joker454
02-Jan-2007, 03:15
Performance penalties will really depend on how the engine deals with tiling, but if that as low as 5% hit for 3 tiles holds up, depending on how it scales, it could become pretty extreme. In other words, probably never any 4xMSAA, though 2x would certainly be possible.

Our 360 title does 4x msaa (3 tiles) and can still occaisionally hit 60fps, although usually its locked in the 30fps range. Our ps3 version does not do any anti aliasing, but still falls behind the 360 version in framerate. As stated previously though we are vertex heavy, typically having 6 or so inputs and outputs to the vertex shader, and thats after optimizing! The title of this thread states 'vertex input limited', but actually vertex output is also a limiting factor as per rsx docs. So our title is doubly hit on performance on rsx.

TurnDragoZeroV2G
02-Jan-2007, 03:49
Does xenos support 3Dc or 3Dc+?

You can find a list of Xenos' supported texture formats here (http://www.beyond3d.com/forum/showpost.php?p=746115&postcount=5).

It would appear from the first two posts that our guest's stay here will be gloriously short, barring a significant change in attitude.

Jov
02-Jan-2007, 04:04
[/color][/color]

The PS3 isn't that radical though in regards to general architecture. CPU with memory (XDR System memory) and GPU with memory (GDDR3 VRAM) with some FlexIO voodoo connecting them. Sounds a lot like a PC, especially when you consider that the PPE is a PPC chip.

Where PS3 is radical is in the CELL SPEs; instead of multiple traditional CPU cores like the PPE, it has 1 PPE and 7 assymetric processors that are simpler (e.g. no branch prediction and no L2 cache) and require some extra elbow grease (DMAs to the system memory) but have an insanely fast local store (memory) that make them little monsters when you can fit within the confines of the memory (and even better SIMD). No doubt, that is radical -- both in terms of departure and in coolness :cool:



Yes it does sound very much like a PC with some radical bits and pieces. :wink:



Yes, it is G80. A driver update will resolve the confusion... hello Brimstone! :razz:


Never crossed my mind. If anything having a G80 like design will cause more overlap in functionality and purpose (SPU -> GPU and G80's GPGPU -> CPU). btw who's Brimstone? :smile:


...

I would argue that PS3 devs will get a chance to take a hack at this before Xbox devs. First is because RSX is a pretty well known quantity, and second because the SPEs open up a lot of doors. I think devs will be playing with Xenos for a while (ditto PS3 devs with SPEs) and use the CPU for other stuff... all that insignificant stuff like game code :lol:

Agree things are balancing out more between the workloads of the two main chips, and that will produce different if not more interesting games.

granrooster
02-Jan-2007, 04:25
Our 360 title does 4x msaa (3 tiles) and can still occaisionally hit 60fps, although usually its locked in the 30fps range. Our ps3 version does not do any anti aliasing, but still falls behind the 360 version in framerate. As stated previously though we are vertex heavy, typically having 6 or so inputs and outputs to the vertex shader, and thats after optimizing! The title of this thread states \'vertex input limited\', but actually vertex output is also a limiting factor as per rsx docs. So our title is doubly hit on performance on rsx.

Is there more you can share with us what your engine is technically doing? The SCE devs have been an accommodating bunch. :)

22psi
02-Jan-2007, 04:34
Our 360 title does 4x msaa (3 tiles) and can still occaisionally hit 60fps, although usually its locked in the 30fps range. Our ps3 version does not do any anti aliasing, but still falls behind the 360 version in framerate. As stated previously though we are vertex heavy, typically having 6 or so inputs and outputs to the vertex shader, and thats after optimizing! The title of this thread states 'vertex input limited', but actually vertex output is also a limiting factor as per rsx docs. So our title is doubly hit on performance on rsx.

Very interesting. Can you tell us if your game is doing HDR as well?

Acert93
02-Jan-2007, 04:41
Very interesting. Can you tell us if your game is doing HDR as well?

I think he mentioned it did, specifically when he mentioned the ability to do MSAA with FP10 and how porting this to the PS3 had the issue the FP16 wasn't compatible with MSAA and there was no time to design a shader based solution.

Is there more you can share with us what your engine is technically doing? The SCE devs have been an accommodating bunch.

He actually has said a lot in his posts. I won't collect all his hints here, but I think one can get a pretty good idea of not only the scope of the game (which he described in one of his recent posts) but could probably figure out to a high degree what game it is. If I could PM him I would shoot him my guess as I am 90% sure I know what title it is :cool:

pakotlar
02-Jan-2007, 04:44
First, change your username.



OT, but unless there is a rule on this forum against this, I don't like your attitude towards the poster, despite whatever edgy tone he had towards joker.

NRP
02-Jan-2007, 04:52
Our 360 title does 4x msaa (3 tiles) and can still occaisionally hit 60fps, although usually its locked in the 30fps range. Our ps3 version does not do any anti aliasing, but still falls behind the 360 version in framerate. As stated previously though we are vertex heavy, typically having 6 or so inputs and outputs to the vertex shader, and thats after optimizing! The title of this thread states 'vertex input limited', but actually vertex output is also a limiting factor as per rsx docs. So our title is doubly hit on performance on rsx.
Even though tiling appears to be a pain in the ass, I am glad devs are starting to take advantage of it.

Thanks for sharing your insight and experiences, joker454. I'm glad you're here, and I hope you stick around.

Jov
02-Jan-2007, 05:03
Just considering the performance hit, based on how many tiles you'd need... 720p 4xMSAA is 3 tiles (28.x MB), while 1080p 0xMSAA would be 2 tiles,, and 4 tiles for 2xMSAA, and 7 for 1080p. You can see how this really adds up. Performance penalties will really depend on how the engine deals with tiling, but if that as low as 5% hit for 3 tiles holds up, depending on how it scales, it could become pretty extreme. In other words, probably never any 4xMSAA, though 2x would certainly be possible.

So with Tiling you implying it is possible to have only ~5% hit compared to not Tiling? So why is 4xMSAA not possible @ 1080p with 7 tiles (give all things are equal)?

TurnDragoZeroV2G
02-Jan-2007, 05:24
Edit:
So with Tiling you implying it is possible to have only ~5% hit compared to not Tiling? So why is 4xMSAA not possible @ 1080p with 7 tiles (give all things are equal)?
It is possible. I'm merely suggesting that depending on how a specific engine scales, it could see a pretty significant penalty. Only developers will have profiled and found out what they can do. We've heard 5% hit, but that was rather ambiguous if I remember properly. It could have easily applied to just two tiles. And we have no solid proof of either a) how big the penalty has been in real game engines (i.e., a number of them with different requirements, poly counts, etc.) so far, and b) how the penalty scales with number of tiles. If it got as big as 30%, I'd say that's pretty significant.

In that vein, I shouldn't have said it wouldn't happen. Both because I'm not a games developer, and because there might very well be games that do so. But I don't think those games are going to be the high-profile games that everybody looks as the next bar in graphics. Very well might be the next Micky-D's Super Mini Go-kart racer, though. Or whatever.

jonabbey
02-Jan-2007, 06:36
So now you have this eDRAM, and logically predicated tiling, and can toss in architecturally the ability for the CPU to stream L2 data to the GPU directly. So on a basic level the Xbox 360 IS very traditional and not radical at all--PPC CPUs, single memory pool, and GPU with eDRAM. Yawn. But the proprietary features and design are quite a bit different and have been hardly touched.

I know it's not been discussed as a prominent Cell feature, but doesn't the PPE also have the same ability to lock parts of the L2 cache down to let an external device like the RSX read from cache?

I mean, I think the XDR is supposed to be fast enough that there's not nearly the advantage that the 360 takes from doing that sort of thing, but my understanding was that the cache line locking was a feature of the underlying PowerPC architecture, and not something that was devised especially for Xenon/Xenos.

Fafalada
02-Jan-2007, 06:37
it probably is also the best known in regards to what it can do, and what works well and what doesn't.
Maybe it's just me - but I could swear this thread demonstrates pretty clearly that working well with RSX is not exactly clear to many people out there (developers or general public alike). In fact lot of the discussion sounds eerily reminiscent of 6 years ago.

nonamer
02-Jan-2007, 06:49
Maybe it's just me - but I could swear this thread demonstrates pretty clearly that working well with RSX is not exactly clear to many people out there (developers or general public alike). In fact lot of the discussion sounds eerily reminiscent of 6 years ago.

Are you refering the the PS2's "lack" of VRAM?