PDA

View Full Version : 'PS3 and XBox 360 in the Real World' Editorial thread



xbdestroya
08-08-2005, 02:57 AM
This isn't the norm that I would normally take an article from our front page and just post it here word for word, but this one stands out from the rest as being particularly relevant to some of the discussions we've had over the last couple of months. In particular it refutes some of the points made by Anand in his recent article and MajorNelson in his crazy blog, and in general it gives a very good insights into programming for these consoles.

And beyond the usual commentary, you can use this thread as a Q&A as well, since the author is staff of course.

Warning that the article is long! http://forums.e-mpire.com/images/icons/icon12.gif

Article Link (http://psinext.e-mpire.com/index.php?categoryid=4&m_articles_articleid=153)


It’s practically a law of nature that with every new console generation, you’ll have armchair hardware architects putting up info that says one machine is superior to the other and will completely change the world resulting in games of such dazzling realism as to render one likely to pass out with each title. Ah, yes, and of course, the marchitecture campaigns from the various companies designed to have as divisive of effects as possible on the community. Fanboys, of course, will lap up the nonsense and hold it as the gospel truth. And the average person will simply approach it in the form of “I don’t know what any of that means, but it sure sounds like he knows what he’s saying.”

There are always pitfalls when you make comparisons based on theoretical limits of devices. The fact of the matter is that from what we know about Xbox360 and PS3 at this time, the differences aren’t that big overall. It’s going to be the little things that make all the difference in real games.

Multicore is the general direction all CPU makers are moving, as it provides superior long-term scaling than trying to push the IPC (instructions per cycle) and clock speed barriers. When you think about it, going from earlier x86 CPUs to the current crop of Athlon64s and P4s, we’ve ended up using around 18x the number of transistors in order to increase IPC by a factor of about 2-3 (that and adding 300 or so new instructions). Consoles are a little different from PCs, though, in that they rest on a single design that has to carry the platform for a very long time. And yet, both the next-gen consoles we know anything about (and most likely the third as well) have taken a multicore path. Why? For one, the added complexity of all this extra IPC-saving logic makes chip design very difficult and very involved depending on a great deal of prior experience. This is why the PC CPU market is dominated by only two chipmakers. On top of which, adding all this extra logic piece by piece over several generations of chips has created a tangled web of interacting systems that somehow manage to work. This makes for what most engineers refer to as a fragile framework; it works well, but it doesn’t fail well. Going multicore with simpler cores proves to be a cheap way to get high throughput that should hopefully be sufficient for a very long time, and at the same time, do it at low power consumption.

There’s a key distinction to be made here between “performance” and “throughput.” If any of you read Anandtech’s short-lived article that made the points of “the real-world performance of the Xenon CPU is about twice that of the 733MHz processor in the first Xbox” and that “floating point multiplies are apparently 1/3 as fast on Xenon as on a Pentium 4”, the problem here is that it’s not making the distinction between the profiles of single operations and the total throughput of the CPU. There’s no question that single threaded performance of next-gen CPUs will almost invariably be much slower than that of current PC CPUs. It’s not that the operations themselves are slow so much as there are more incurred delays between operations. As I said, we’ve got loads of transistors in our PC CPUs to keep a high IPC going. Both Xenon and PS3 have largely forgone that extra hardware and instead opted to use the extra transistor space to get more functional hardware in place. This kills single-threaded performance, but the fact that it can run MANY threads means that overall throughput can still be very high.

There’s no question however, that this takes some massaging to actually work in practice. Throughput-oriented computing is not new to the server world (hence, products like Niagara and Itanium), but it is certainly new to gaming. The worst part of it is that 360 and PS3 take entirely different approaches to the problem. Xbox360 takes the SMP route, while PS3 takes a sort of master-slave route. Xbox360 is better suited to large-scale threading where most of the work per thread is on a relatively even keel and your main concern is synchronization. PS3 is seemingly better suited to micro-thread type tasks where the operations themselves are small, but there are many of them that are completely independent.

There’s no real empirical basis within gaming to say that one method is easier on developers than the other. It’s really something that can only be shown after the fact. This is primarily because, if for no other reason, the toolset will define the bulk of development. In the case of 360, there’s a certain advantage to SMP in that the performance profile of any given thread is the same and is always predictable regardless of the core it’s running on. With CELL, the code has to separated between SPE tasks and PPE tasks. The adage that game code is around 80% “general purpose” and 20% floating point is certainly accurate if you’re talking about code volume. The problem is that game code is never the big time consumer in a game. It’s the engine code where we’re always reinventing the wheel over and over to get just a few more polygons down the pipe or to make sure we can get that consistent framerate. That end of things is certainly floating-point heavy. More importantly, the game code is usually not something that multi-threads well because games are not really parallel. Every step goes in a very specific order because of the information prepared after each step. XeCPU would certainly have an advantage in an instance where one box may be used in a LANparty as a server for a multiplayer game.

When I see things like Major Nelson’s little post-E3 counterargument in favor of Xbox360, I can’t help but think that he really chooses all the wrong arguments so that the average Joe and fanboys can understand, rather than actually making valid points.

Before I get into the finer points, I’d rather just start off pointing fingers at the dumbest of all the arguments -- the purported memory bandwidth advantage. The comparison claims an advantage for Xbox360’s 278.4 GB/sec of memory bandwidth to PS3’s 48 GB/sec. Of course, the stupidity of this statement is that the 48 GB/sec of PS3’s bandwidth is all point-to-point bandwidth, whereas 256 out of Xenon’s 278.4 GB/sec is internal to a die. If I wanted to include PS3’s die-internal bandwidth, I could include the fact that CELL’s EIB ring allows up to 96 bytes per cycle to be sent between the various SPEs and the PPE, which at a clock speed of 3.2 GHz, amounts to an extra 307.2 GB/sec. Kind of puts the argument to rest, doesn’t it? Hell, if I wanted to be really stupid, why not include the bandwidth between the SPEs and their own SRAMs (230.4 GB/sec per SPE)? Either way, neither comparison is at all valid. The GPU of Xbox360 has a daughter die containing 10 MB of DRAM plus a little bit of extra logic. The bandwidth between this logic and the DRAM is 256 GB/sec. However, this die cannot communicate with other devices at this rate or anywhere near it. The bandwidth between this daughter die and the functional part of the GPU is only 32 GB/sec. The bandwidth between the GPU and any other device is at most 22.4 GB/sec. No matter how fast the eDRAM is, it will never be able to transfer to and from other devices faster than that 22.4 GB/sec. Comparing the sum of chip-internal bandwidth and point-to-point bandwidth of one machine to point-to-point bandwidth only of another machine is fundamentally stupid. It’s not so much apples-to-oranges; it’s a pile of apples compared to a mixed fruit basket that happens to contain a few apples among other things.

Measuring point-to-point memory bandwidth only is actually more meaningful anyway since it’s this bandwidth that has always been a limiting factor for performance. Bandwidth within the silicon area of a single chip is rarely a problem until a chip becomes too complex for its own good. By that measure, Xbox360 has at most 22.4 GB/sec to PS3’s 48 GB/sec. Not so good-looking numbers there for 360. Of course, we could confine exclusively to the CPU and point that 360 has 21.6 GB/sec of memory bandwidth to the CPU vs. PS3’s 25.6 GB/sec. That is actually not a very big difference in practice. The fact of the matter is that neither CPU will really be all that happy with the level of memory bandwidth it may get. In other cases of multi-core processors being limited by bandwidth, the typical workaround is really quite simple -- make the cache large. Neither console really does this, most likely due to cost of production. A 1 MB L2 cache like in Xbox360 may only have a miss rate of around 5%, but that 5% can translate to an average CPI cost of some 26 cycles. In layman’s terms... that’s extremely bad. It means that if you’re not careful, single-threaded performance on PS3 or Xenon could be outpaced by that of a Dreamcast.

Now a valid argument using this 256 GB/sec of bandwidth on the daughter die would have been in regards to points about “virtually free” antialiasing or the fact that it can potentially improve the relative efficiency of the GPU. The fast eDRAM on the daughter die is theoretically quite effective in these matters, but these are things that are impossible to prove without actual field testing. Instead, the comparison leans towards comparing the wrong numbers against each other because the layman would see a numerical comparison as completely objective. By the way, I heard at one point that 772.6 is greater than both 278.4 and 48 combined. That proves that Nintendo Revolution will be the most powerful console ever! How? I don’t know; I just made it up, but you can’t deny the numbers, right?!

The supposed general-purpose computing advantage of 360 is also an erroneous figure because they base it only on number of so-called GP cores and not the actual execution profiles of the CPUs. It’s certainly true that out of CELL’s theoretical 217.6 GFLOPS, 179.2 of those are from vector ops on the SPEs. Additionally, another 25.6 GFLOPS are extracted from the vector unit on the PPE. Xbox360 is not exempt from this point, either -- 76.8 of its 115.2 GFLOPS come from vector ops. However, all these pipes can handle both integer and floating point, and there’s nothing really inherently preventing those vector units from performing general purpose code. They’re just not very good at it. Moreover, as bad as the SPEs are at general purpose code, referring to them as DSPs is nonsense and can be called nothing short of childish on MS’ part. If we were to hypothetically put all the vector units of both CPUs running entirely scalar float/int code, we’d end up with the following numbers -- XeCPU : 48 GFLOPS, CELL : 64 GFLOPS. Not looking so good for Xbox360. Either way, though, numbers like that aren’t very realistic because no game programmer in the world would actually WANT to use the vector units in a scalar fashion -- mainly because that raw throughput difference is so huge, and because vector units are so sensitive to instruction latency.

Real world performance is not going to be dictated however, by how often you can use vector ops. What gets lost in the whole “general purpose” argument is what people are actually referring to when they speak of “general purpose computing.” To me, the bulk of “general purpose” code is going to induce the risk of hitting memory. Chasing pointers, branching, shuffling data around, state checking and synchronization, passing messages... all of which is very important to game code no matter what some uninitiated might think. These are not problems exclusive to game logic or AI, either. Actually, with CPUs as fast as they are these days, this particular factor is the single biggest limiting factor to performance. CPUs these days are so fast that the speed of light and the physical distances that signals have to be routed is actually a limiting factor. And with the very simplistic designs of each core in both XeCPU and CELL, that limiting factor will show itself more clearly than on a PC CPU. It’s as if we’ve got all this computational power that utterly puts a PC to shame, but we can’t actually move data around (assuming we want things to run at a decent speed).

This is yet another thing that really can’t be shown without actual in-the-field results. I haven’t seen any data on this matter regarding PS3 yet, but several people, even on public forums, have mentioned the 500+ cycle stalls for cache misses on Xbox360. Getting the frequency of that occurrence to a minimum is going to involve a lot of changes to the way we do things currently. There will probably be a lot of cases where it’s cheaper to recalculate things every time you need them instead of storing the values off in memory. Simple branches where a particular calculation is chosen may be better handled by simply doing all the calculations and performing a conditional move. So far though, things in the memory arena look worse for Xbox360 simply because it uses a high-latency type of memory and the CPU is farther away from memory. While GPUs don’t really care that much about latency (which is why there’s no harm in using GDDR-3 for a GPU), it makes a big difference to a CPU. Data dating back to 2003 regarding XDR DRAMs at 250 MHz suggested latencies getting as high ~310 CPU clock cycles (for a 3.2 GHz CPU, not including cache latency). Since PS3 uses 400 MHz DRAMs (3.2 GHz signaling rate), it will probably fare a little better. Given that, the average cache miss on PS3 will probably have about the same cost as a cache miss on a P4, except that no fraction of that latency will be hidden, and they’re likely to happen more often because we won’t have the benefit of an aggressive auto-prefetch.

As much as a core processing difference might show up in the long run, there’s probably nowhere near as much difference between the two machines graphically. You’ve got the 500 MHz Xenos vs. the 550 MHz RSX. MS makes a big deal about Xenos’ unified shader architecture and its huge set of 48 pipelines that can serve either vertex or pixel shading operations. One of the very nice things about this is that it can dynamically balance well between pixel and vertex shading according to the respective demands at a given time. How well it does this is uncertain without testing in practice, but there is no question that good load balancing is no trivial problem. Major Nelson’s graphs for the 360 and PS3 GPUs shows the two being nearly even but slightly in favor of Xenos. There are errors here, but in this particular case, the errors are due largely to the fact that detailed info on RSX was not available at the time, so people had to make guesses as to what Sony was referring to when they said things like “136 shader ops per cycle.” With what we know now, it seems that those 136 ops were purely computational. However, it’s not entirely clear yet whether things like the texture sampling or flow control will actually take up ALU slots. Given that the Sony press event at E3 mentions both 136 shader ops per cycle and 100 billion shader ops per second (the two numbers don’t agree at 550 MHz), that suggests that there’s at least 1 other component that gets its own issue lines separate from the ALU.

In general, it seems that if the usage of the render pipeline tilts the load extremely to one direction or the other, Xenos will have a distinct advantage. It also depends on how strongly weighted the complexity of shaders is. RSX shows a clear bias towards complex pixel shaders, whereas its vertex pipes are largely no different (spec-wise) from those of Xenos. On paper alone, it looks like Xenos has an advantage in the expressive power of its shaders, largely attributable to the unified shader model. However, because the RSX allows a potential for so many simultaneous independent ops in its pixel shader units (2x vector4 + 2x scalar + 1 normalize), its performance on an individual pixel shader can potentially be quite high, which means that more shader power could possibly be used in practice. Of course, in practice, the chances to use wide co-issues may not be that frequent, and they will most likely hit in the earliest parts of a pixel shader where a lot of data is set up for further calculations. Either way, the focus of both units is obvious, it’s less about raw fillrate and processing huge polycounts and instead more about massive shader power -- i.e. smarter polygons instead of more polygons. On the whole, the GPUs are fairly even based on what we know at this time.

The fact that the real world difference in graphics may not be that big means that to a publisher, it makes a lot of sense to release next-gen games on multiple platforms since there won’t be many major reasons for a consumer to choose one SKU of a title over another beyond just platform loyalty. Cost of development will certainly go up, and releasing on multiple platforms decreases risk without a huge added development cost. In this aspect, Xbox360 has one advantage. If one were to look at the multi-core roadmaps for PC chipmakers like Intel and AMD, the next few years propose SMP-type designs, whereas CELL-like designs dominate the roadmap years later. For most anyone who has done any kind of multithreaded programming, SMP is a known quantity, which is probably the basis of MS’ argument that 360 is easier to program for. Referring to CELL as a “revolutionary concept that will change everything” is another way of saying there will be a learning curve. How gentle that curve is will be a matter of how good the development tools are.

Compared to the average toolset you’d otherwise see in game development, Microsoft’s developer tools have always been very good... when they work. With a few exceptions, they really don’t fail as often as the prior statement may make it sound, but like Murphy’s Law states, they necessarily fail when it is most inopportune and/or of a condition to maximize the levels of annoyance. I can’t even begin to count how many times an error that Visual Studio gives me was fixed by rebooting the machine. Sony’s tools for the PS2 are rather insipidly lacking. In that arena, I can’t even begin to count how often the compiler itself seg faults. For the first Playstation, it was also severely lacking in the beginning, but the system architecture was fairly straightforward for a lot of developers at the time. There will be hell to pay if Sony doesn’t provide decent tools this time around, though, because even more than the architecture, the poor tools and documentation was a highly reviled aspect by PS2 developers. Fortunately, IBM and nVidia have their hands in that pile, so it won’t entirely be a lost cause. If there’s anything IBM can do well, quite possibly better than Microsoft, it’s making a good compiler. After all, they make the hardware as well, so who would understand the specific challenges better? Actually, chances are good that IBM had their hands in the Xbox360 compiler as well, if for no other reason than the fact that Microsoft would have no reason not to use IBM’s input.

Sony’s efforts to provide good tools have always been... ummmm... well, uhhh.... How does one put this delicately? Mmmmmm... nope, can’t do it. Well, that aside, IBM generally makes good compilers, and assuming that Sony at least used IBM’s input, that probably at least says we won’t end up with compilers that produce complete trash. The only thing anybody outside the PS3 devnet really hears about for dev tools happens to be COLLADA. There’s usually a lot of confusion here because people keep comparing COLLADA to XNA, when they’re really not similar. XNA is a tools package mainly aimed at programmers, albeit an incomplete one at this stage. The promised miracle package doesn’t really exist yet, nor does Microsoft claim it’s complete. COLLADA is a file format. Its primary aim is really in unifying content formats to ease the art pipeline. For me as a programmer, XNA is what would concern me more, but for those in the studios who have to worry about cash flow and time management, COLLADA has a fairly important stance as well. Content creation and art pipeline are the primary driving cost factors in game development, because as much as we programmers might be loathe to admit it, the artists are the most important people on the team.

It’s doubtful whether COLLADA would do much to help improve the rate and cost of actual content creation, but it does mean that because of unified formats for storage, a common importer would work regardless of the source. It also means that studios may not have to worry about the packages that artists prefer, which in turn opens up possibilities for outsourcing. For in-house art, though, most, if not all, studios already have single-package art pipelines (exclusive MAX or exclusively Maya, etc.)

Personally, I’ve yet to see with my own eyes what actually comes with PS3 devkits, but most of the talk going around seems to suggest that it’s fairly decent. It could be considered a veritable 180 (no pun intended) from the PS2 tools, which were more or less, a complete farce. The general programming model for the PS3 rests greatly on automation of resource management, so the developer simply has to request any arbitrarily available SPE and deliver apulets to it should they find the need to use the SPEs. This, in reality, is actually easier than the Xbox 360’s SMP model which requires us to explicitly handle these matters of resource allocation ourselves. However, this can be a double-edged sword in that there’s no immediate guarantee of the quality of these libraries that Sony provides. Moreover, it may be very poor in early games, but generations of SDK updates may improve that aspect over time. In either case, the necessity of having to handle resources on your own with 360 is largely unavoidable because the needs for threading is likely to be completely different from one game to another. The fact that PS3’s CELL has a central “master” processor which can issue to several other vector processors means that having an automated resource allocation scheme is perfectly feasible because there is a known entry point for all code and the CPU is well-suited to short, fixed-function, repetitive mini-tasks. Of course, having the resources is still different from knowing precisely what to do with them, which is something that is a problem for both consoles. This is why a lot of PS3 developers speak of their demos running only on the PPE. while most people would think this is really impressive in that they’re producing the results they are with such minimal hardware utilization, it really says that the learning curve is very steep. The biggest advantage launch titles for PS3 will have is the fact that developers will have worked with the CELL much longer than 360 launch developers will have worked with the XeCPU.

As far as 360 is concerned, the tools that have been hyped beyond words is the indomitable XNA. Many of the claims about what it may provide are possibly true, although XNA is still vaporware for the moment. My main problem with XNA is that its goals are a bit misguided. If you remember the campaign that appeared about a year ago, everything seemed to suggest that XNA would decrease the amount of time spent on tech development and leave more time for the actual game logic and game content to be developed. Typically, unless you’re in a position like that of Half-Life 2 or Doom3, where brand-new tech was developed, tech development goes on in parallel with game development, and a game that is getting close to release gets branched off so that the only tech changes that go in will be bugfixes, many of which might be dirty hacks that are specific to that title. On top of that, the number of people in a given studio who are working on the core technology of an engine is pretty small. So even if you do cut down on the time of tech development, how much money in the cost of the development of a title has really been saved? Not too much, I’d imagine.

It’s one thing to argue that one of the consoles will be easier to program on than the other, but all too often you see ‘schmoozed’ developer comments saying that Xbox360 is so easy or PS3 is so easy. Any comments along those lines can be taken as boldfaced lies. The fact of the matter is that developers will necessarily have to optimize specifically for these new platforms. Multi-core, in-order, small caches, all adds up to a load of headaches no matter who it is. It also means that there may, at least at some point if not at launch, be a sizeable difference in visuals and gameplay between the exclusive titles and the multi-platform titles. Looking through a lot of the complaints developers have had about the next-gen hardware, they all point to one fundamental outlook. This next-gen is going to be one that separates the men from the boys.

Article Link (http://psinext.e-mpire.com/index.php?categoryid=4&m_articles_articleid=153)

Raijin
08-08-2005, 03:11 AM
Yeah I read this article just a few moments ago and while i don't understand everything (most tech stuff etc etc...), It's nice to see an unbiased article on these next-gen consoles.

I also noted that Sony is doing all what they can do to bring to the dev. good tools although seems there's still a lot of work to do this area. But at least, Sony is taking it seriously and now I understand they will spend less money on exclusive titles which gives more credits to Oda's rumors.

I would like to know who wrote this article? Is it a member of this forum or somene else? Well at least it's a programmer.

xbdestroya
08-08-2005, 03:21 AM
LOL, yes he's a forum member. http://forums.e-mpire.com/images/icons/icon12.gif

How else could this thread also serve as a Q&A? Anyway if you've had post exchanges with him before, it's probably not difficult to guess the author.

Raijin
08-08-2005, 03:32 AM
Ok I see... :D

Concretly, better tools for game development means better first gen title (I mean the game uses more efficiently the hardware)? Is that why we saw many crappy games on PS2 at launch? For example, RRV, Evergrace etc etc...?

Illmatic
08-08-2005, 03:36 AM
Great work cpiasminc http://forums.e-mpire.com/images/icons/icon14.gif

xbdestroya
08-08-2005, 03:52 AM
Great work cpiasminc http://forums.e-mpire.com/images/icons/icon14.gif

Indeed it was - either you guessed right or you read the RSX thread Vejita! :smoke:

Viper
08-08-2005, 03:59 AM
I posted this in the article comments section.



Most impressive. That should do well on the minds of all that read it.

I hope we all learned something today other than K. Parashar knows a hell of a lot more about consoles than we do.

Illmatic
08-08-2005, 04:03 AM
Indeed it was - either you guessed right or you read the RSX thread Vejita! :smoke:

I may have peeked into the RSX thread http://img.photobucket.com/albums/v729/Stillmaitik/wink.gif

rpgamer_2k5
08-08-2005, 06:10 AM
Excellent article, cpiasminc. I just like the very neutral and sound approach of this article; this will allowPSINEXT (and E-Empire) to become a premier source in the computer technology realm. :)

Once again, excellent piece!

Rukawa
08-08-2005, 10:06 AM
Great article Cpiasminc

Question , isnt Cell EIB run on half clock speed , i forgot the link

Hope you write the part2 after receive final dev kit of Xbox 360 and PS3

venomv
08-08-2005, 10:49 AM
I think that might have been cpiasminc when I read it the first time, awesome article even though I didn't read the stuff about the dev kits, tired of reading it by that point.

sif
08-08-2005, 01:46 PM
Great article Cpiasminc, am I right in inferring from your article that Cell is better at general purpose (therefore AI and other FLOPS unintensive stuff) than the Xenos in X360?

cpiasminc
08-08-2005, 02:26 PM
am I right in inferring from your article that Cell is better at general purpose (therefore AI and other FLOPS unintensive stuff) than the Xenos in X360?
I should certainly hope so, considering Xenos is the GPU... But yeah, overall, there's a possibility it will be better at it. It remains to be seen though, if the latency advantage will be all that significant when you've got twice as many cores making requests and the memory subsystem has to open new pages so many times. That's something that would only pop up once people are starting to use the SPEs, though.

sif
08-08-2005, 02:38 PM
I should certainly hope so, considering Xenos is the GPU... But yeah, overall, there's a possibility it will be better at it. It remains to be seen though, if the latency advantage will be all that significant when you've got twice as many cores making requests and the memory subsystem has to open new pages so many times. That's something that would only pop up once people are starting to use the SPEs, though.

Sorry my bad, I am always confusing Xenos, with Xenon. Wow, that is a bit of a kick in the nuts for a certain Mr Nelson....

Danji
08-08-2005, 03:17 PM
Wow, that is a bit of a kick in the nuts for a certain Mr Nelson....

...and yet not one person can honestly say they care about the certain Mr. Nelson.

Anyways, it's a wonderful article and a great read. It's the most unbiased article I think i've ever read about any console ever and I mean that. I would say Jon "Hannibal" Stokes from Arstechnica was unbiased but he seems to become biased for different things at different times. Still a great writer though.

Sif posted the article over at TXB and nothing except the usual has come of it. I would post a link but there really shouldn't be any discussion of that thread here (that's what that thread is for).

Keep up the good work CPI! :cheers:

mrBlue
08-08-2005, 05:38 PM
I've been coming her since ~February and I must say I always enjoy cpiasminc's posts. Great technical information and an all around kick ass article. Keep up the good work, sir.

cpiasminc
08-08-2005, 06:08 PM
Question , isnt Cell EIB run on half clock speed , i forgot the link
That is true, but I think the figure of "96 bytes" was normalized for that (i.e. it can actually transfer up to 192 bytes every other cycle).


Hope you write the part2 after receive final dev kit of Xbox 360 and PS3
Yeah, well... that'll be interesting. It'll be a ways off -- I actually think we won't get final hardware for 360 until after the console itself comes out. Since we're not doing a launch title, and we're 3rd party, we're not exactly a priority developer. Either way, I really don't have a clue what's going on with the PS3 situation, but for now, the PS2 and PSP is what's on my desk.

I'm still completely befuddled as to why the PSP kit has a foot pedal...??!???? It doesn't say why anywhere in the docs.

Viper
08-08-2005, 06:38 PM
the PSP kit has a foot pedalIt doubles as a piano. Didn't Sony tell you it was a multifunctional device?

Pistolero
08-08-2005, 07:11 PM
Cpiasminc : Have you had the chance of touching on with the PS3 Dev kit ?

NB : Great article by the way.

cpiasminc
08-08-2005, 07:23 PM
It doubles as a piano. Didn't Sony tell you it was a multifunctional device?
Since it only has the one pedal, our IT guy was joking that it would double as a sewing machine -- the antenna would serve as a bobbin holder. If I could actually use it as such, that would be nice. Currently, Sony sent us the kit and some docs and no tools (it's for evaluation)... So it's a paperweight for now.

Yo MaMa84
08-08-2005, 07:43 PM
Great article man....kinda long, but good.

Domination
08-08-2005, 07:53 PM
This isn't the norm that I would normally take an article from our front page and just post it here word for word, but this one stands out from the rest as being particularly relevant to some of the discussions we've had over the last couple of months. In particular it refutes some of the points made by Anand in his recent article and MajorNelson in his crazy blog, and in general it gives a very good insights into programming for these consoles.

And beyond the usual commentary, you can use this thread as a Q&A as well, since the author is staff of course.

Warning that the article is long! http://forums.e-mpire.com/images/icons/icon12.gif

Article Link (http://psinext.e-mpire.com/index.php?categoryid=4&m_articles_articleid=153)



Article Link (http://psinext.e-mpire.com/index.php?categoryid=4&m_articles_articleid=153)

Yeah, I read that the other day. It's a well put artical. While others things were no surprise to me, some were. A great piece indeed.

woundingchaney
08-08-2005, 08:49 PM
Very good read, Im rather impressed at your ability to put such technical info into "laymans" terms.

woundingchaney
08-08-2005, 09:05 PM
Not advertising here but they are having a discussion on the same topic over at TXB and it really is a mature and good discussion (one of the few I have seen there lately). :monster:


Other Consoles Forum

rpgamer_2k5
08-08-2005, 09:24 PM
Great article Cpiasminc, am I right in inferring from your article that Cell is better at general purpose (therefore AI and other FLOPS unintensive stuff) than the Xenos in X360?
When you say 'general-purpose' computing, you speak of fixed-point operations. AI does require the use of floating-point arithmetric because it can manage numbers of high magnitude and range. In fact all the studies in AI require the use of massive supercomputers with high floating-point performance. Any of the multimedia-related applications require very high floating-point performance hence the dedicated FPU in CPUs. However, if we're talking about running a spreadsheet then fixed-point arithmetric is only necessary. But even a PII 233Mhz could run a word processor as well as a 2Ghz P4 and the Cell is not that pathetic in fixed-point operations.

The problem with the Cell and AI is the fact it lacks branch predictors. Most would assume that now the programmers will have to do some very careful coding (that would be quite abstract) in order to get some performance out of the Cell. Artificial Intelligence is a field that is still not known so those that are researching AI will not go through a significant adjustment. As stated by PSINEXT AI expert, Arnaud_M, most of the AI techniques require branch prediction so they will go through the transition too. Many AI researchers are still excited about the Cell though because of its unmatched floating-point performance.

We'll have to wait a see. Current, most are predicting that the Cell will indeed be a AI beast. Even the latest Cell whitepaper states:

"Less traditional applications, like video surveillance, are a perfect fit for Cell processors. The video encoding capabilities, coupled with an Artificial Intelligence engine, might recognize problems and generate appropriate alerts."

axia777
08-09-2005, 12:00 AM
Like many members have said before me, this is the most unbiased article I have ever read on any next gen system. It was informative and well written. Technical yet easy to understand if one has a basic understanding of technology and console systems. I appealed the author. I think every fan of any next gen system should read this with an open mind. It sure opened mine in a lot of ways.

Considering I am planning on making games after I graduate from the AI this was very informative as to the over all problems a developer can possibly face with the new systems. And what ever Sony or Microsoft seem to be spewing about the "ease of development" for their prospective systems it really seems like it all comes down to seel developed middleware and development tools give to developers. Bad middleware, big ass head ache. Good middle, less of a head ache. This really brought a lot in to perspective for me personally. Like PS2 over the XB it will be PS3 over 360 for me, because of the games. That and the Nintendo Revolution, again for the games. But for development purposes for companies that I will work for it seems like their is not really that much of a difference in raw power of the systems themselve. It sure will be a fierce and exciting time for gamers in the next few years. I guess only time will tell all, no?

cpiasminc
08-10-2005, 02:40 PM
When you say 'general-purpose' computing, you speak of fixed-point operations. AI does require the use of floating-point arithmetric because it can manage numbers of high magnitude and range. In fact all the studies in AI require the use of massive supercomputers with high floating-point performance.
Well, you can substitute fixed-point for floating point almost anywhere, actually (look at the DS). In fact, if you know that you are range-bounded, fixed point can give you better precision in the same word size than floating point (it doesn't need to store an exponent since it's "fixed"). You just need to be wary of the fact that certain operations (multiplies/divides) can take you out of range of the word, but then floating point also does the same in hardware.

Game AI is still pretty far removed from the theoretical end of AI, though. Even though something like an ANN is really fast (to compute, anyway -- convergence rates are awful, but you don't want an optimal solution in-game). Most all game AIs are just finite state machines. Essentially, branch trees of several hundred nodes broken up into a handful of specialized classes. More than anything else, you're going to be jumping around in memory and flushing cache lines... And a smart prefetching will help you a lot more than a branch predictor there.

Floating point power in game AI will only be helpful when moving beyond a mere DFA or fuzzy DFA. As it is, though, it would certainly be attractive to researchers in the field.

Lumine
08-10-2005, 03:33 PM
In response to a technically inclined article, I will give an equally technically inclined response: w00t


Floating point power in game AI will only be helpful when moving beyond a mere DFA or fuzzy DFA. As it is, though, it would certainly be attractive to researchers in the field.

What does the DFA stand for? and ANN is some sort of Neural Net, right?

sousuke
08-10-2005, 07:01 PM
What does the DFA stand for? and ANN is some sort of Neural Net, right?
i think typing that in google or wikipedia would have been faster than typing it here :P
thats what i got:
DFA means democracy for america
and ANN means Arab News Network.
easy wasn't it? ;)


ok, now seriously:
ANN is probably Artificial Neural Network
DFA probably Deterministic Finite Automaton