[liolio]

Originally Posted by Capeta

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]

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]

Originally Posted by The so called dev's words

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?

[ShootMyMonkey]

Originally Posted by xbdestroya

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]

Originally Posted by almighty

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

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]

Originally Posted by liolio

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.

Originally Posted by liolio

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]

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]

Originally Posted by xbdestroya

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]

Originally Posted by phat

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]

Originally Posted by Kryton

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 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]

Originally Posted by Kryton

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-]

Originally Posted by Rangers

Blu Ray supporter eh?

HD-DVD supporter ehh?

Sorry, had to do it

[StefanS]

Originally Posted by -tkf-

HD-DVD supporter ehh?

Sorry, had to do it

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

[liolio]

archie4oz, thanks for your enlightnings

[Graham]

... 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]

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]

Originally Posted by joker454

...

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]

Most silly comments you can ignore joker. I hope to see your input a lot more in these forums.

[22psi]

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]

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!


Peace.

[MBDF]

nm.

[Carl B]

Originally Posted by joker454

"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.

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]

Originally Posted by NucNavST3

Whatever,

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

*cough cough*

[ShootMyMonkey]

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]

Originally Posted by ShootMyMonkey

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

?