Who decides what is 'best'? I've seen AI running on a 386SX that looks more intelligent than much of the crap you see in 360 games. I think what you really mean is, "which piece of electronic kit is capable of handling the most instructions per second", and even that has little effect on the end games because it's unlikely programmers will ever reach the full potential of a modern machine. New systems will come out long before people get to that point. It's a pointless metric. Don't waste your life arguing about it.

not to mention microsoft releasing XNA tools so you can do homebrew on the XBox360. Fair enough you gotta pay to use it but still, it's a nice idea

Quote:Original post by TomokkaSo i meant which platform will have games with the best graphics a.i and all that stuff. Not which game will be the most fun or anything like that.

I'm sure you had your reasons to dicuss those questions, but playing games just because of graphics and AI seems dumb. Last time I checked people usually play games to have fun. Graphics and AI might add to that, but they're secondary, so for me deciding for a console will never be a question of horsepower.

Quote:Original post by CAMongrel

Quote:Original post by TomokkaSo i meant which platform will have games with the best graphics a.i and all that stuff. Not which game will be the most fun or anything like that.

I'm sure you had your reasons to dicuss those questions, but playing games just because of graphics and AI seems dumb. Last time I checked people usually play games to have fun. Graphics and AI might add to that, but they're secondary, so for me deciding for a console will never be a question of horsepower.

It seems that many people have misunderstood what i meant. This was my fault for not being clear. I personally think system shock 2 is the best game ever created to this day and i personally dont think graphics make a game good. I arqued my friend about which console can deliver the best graphics, a.i and things like that. This post was not about which games will be the most fun or the best, but which games will have the best graphics and such.

Quote:Original post by Anonymous Poster
Yes, the PS3 has two memory pools, 256MiB system memory and 256MiB vram. While that might seem like a downside initially, it actually does work out in a lot of ways because the GPU can be merrily grinding through a bunch of stuff in vram while the CPU is grinding through data in system memory, and there's little to no bus contention getting in the way of everything getting on with its work. On the 360 the CPU and GPU share a bus and generally the biggest bottleneck in games is going to be memory bandwidth.

The Cell CPU is an appallingly bad design for games. The SPE/SPUs can only get to their tiny on-chip local memory, if they want to access any data in main memory they have to kick off a DMA to pull that data in and then work on it. It's a truly horrible programming model to work with, especially when you're trying to fit general AI type tasks on there. The SPUs would be really good as vertex shader units or audio mixing units, or basically anything that's inherently a stream in/stream out sort of task, but for general processing they are a pain in the ass.

You're looking at it from the wrong perspective. If the SPEs had direct access to main memory you would have the same problem you have on the 360, bus contention for main memory, compounded since now you have 9-10 processors contending for the same bus as opposed to 4 on the 360.

Instead, you have to partition your problem such that each SPE can grab a chunk of data, do something meaninful with it, and forward the results somewhere, as opposed to constantly dipping into a globally shared data structure and not only contending on the bus, but also contending on the data itself. In exchange you get access to a very fast local memory, and you have very good bandwidth to main memory and other SPE memory even if all SPEs have DMAs in progress, thanks to the ring bus interconnect. That's the trade off: more parallel branches of computational power at the expense of appropriately partitioning your work.

Whether or not it is appallingly bad design for games is debatable. There's 20-something years of commercial game development centered around the familiar single thread of execution. At best people are using extra threads for asynchronous work but still relying on a shared, centrally administered state machine. Neither is appropriate for the CBE.

Maybe the problem is that game programmers are (at the moment) appalingly bad designers for distributed multiprocessors.

One thing i would like somebody to explain to me. From what i gathered from peoples post on this threath the gpu:s of these consoles are prity mutch the same, but when i look at the specs it seems that the xenos is more powerfull in everyway. It can do more shader ops per sec, it can do more triangles and it has the 10mb of edram. If you believe the specs the xenos has a lot more raw power than the other gpu. So what does the other gpu have that makes it as powerfull as the xenos?

Quote:Original post by outRider
Whether or not it is appallingly bad design for games is debatable. There's 20-something years of commercial game development centered around the familiar single thread of execution. At best people are using extra threads for asynchronous work but still relying on a shared, centrally administered state machine. Neither is appropriate for the CBE.

Maybe the problem is that game programmers are (at the moment) appalingly bad designers for distributed multiprocessors.

Bear in mind a lot of fault lies with the languages, which were typically designed for sequential single-process use, and with the tools and libraries that were designed to work with those languages. On top of that, I personally am of the opinion that real-time simulations (which most games can be classified as) do not intrinsically parallelise well anyway, due to the fact that you typically produce output based on the whole simulation once per frame, as opposed to applications like databases or web servers that typically have separate inputs, outputs, and data sets allowing each part to operate largely independently.

Quote:Original post by Kylotan

Quote:Original post by outRider
Whether or not it is appallingly bad design for games is debatable. There's 20-something years of commercial game development centered around the familiar single thread of execution. At best people are using extra threads for asynchronous work but still relying on a shared, centrally administered state machine. Neither is appropriate for the CBE.

Maybe the problem is that game programmers are (at the moment) appalingly bad designers for distributed multiprocessors.

Bear in mind a lot of fault lies with the languages, which were typically designed for sequential single-process use, and with the tools and libraries that were designed to work with those languages. On top of that, I personally am of the opinion that real-time simulations (which most games can be classified as) do not intrinsically parallelise well anyway, due to the fact that you typically produce output based on the whole simulation once per frame, as opposed to applications like databases or web servers that typically have separate inputs, outputs, and data sets allowing each part to operate largely independently.

You seem to know what you are talking about :). Can you tell me your opinion which console is the most powerfull one. I dont mean which console has the most peak performance or theoretical power but which console can deliver the most power to games.

Quote:Original post by Kylotan

Quote:Original post by outRider
Whether or not it is appallingly bad design for games is debatable. There's 20-something years of commercial game development centered around the familiar single thread of execution. At best people are using extra threads for asynchronous work but still relying on a shared, centrally administered state machine. Neither is appropriate for the CBE.

Maybe the problem is that game programmers are (at the moment) appalingly bad designers for distributed multiprocessors.

Bear in mind a lot of fault lies with the languages, which were typically designed for sequential single-process use, and with the tools and libraries that were designed to work with those languages. On top of that, I personally am of the opinion that real-time simulations (which most games can be classified as) do not intrinsically parallelise well anyway, due to the fact that you typically produce output based on the whole simulation once per frame, as opposed to applications like databases or web servers that typically have separate inputs, outputs, and data sets allowing each part to operate largely independently.

I don't completely agree with your opinion on the potential parallelism of games, but that's another discussion altogether.

Assuming I did however, I would say that it would be a problem for any multiprocessing scheme, regardless of whether it's symmetric/shared (360/PC) or asymmetric/distributed (PS3). The cost of distributing and recombining the state machine makes it a little more involved on distributed systems, and the memory constraints of the Cell SPEs also don't help, but if you can solve the problem on 360 you can solve it on PS3. To that end, I don't think the Cell is a bad design at all, I think it's an excellent design provided you don't try to use it like a single processor or symmetric multiprocessor with shared memory.

Quote:Original post by outRider

Quote:Original post by Kylotan

Quote:Original post by outRider
Whether or not it is appallingly bad design for games is debatable. There's 20-something years of commercial game development centered around the familiar single thread of execution. At best people are using extra threads for asynchronous work but still relying on a shared, centrally administered state machine. Neither is appropriate for the CBE.

Maybe the problem is that game programmers are (at the moment) appalingly bad designers for distributed multiprocessors.

Bear in mind a lot of fault lies with the languages, which were typically designed for sequential single-process use, and with the tools and libraries that were designed to work with those languages. On top of that, I personally am of the opinion that real-time simulations (which most games can be classified as) do not intrinsically parallelise well anyway, due to the fact that you typically produce output based on the whole simulation once per frame, as opposed to applications like databases or web servers that typically have separate inputs, outputs, and data sets allowing each part to operate largely independently.

I don't completely agree with your opinion on the potential parallelism of games, but that's another discussion altogether.

Assuming I did however, I would say that it would be a problem for any multiprocessing scheme, regardless of whether it's symmetric/shared (360/PC) or asymmetric/distributed (PS3). The cost of distributing and recombining the state machine makes it a little more involved on distributed systems, and the memory constraints of the Cell SPEs also don't help, but if you can solve the problem on 360 you can solve it on PS3. To that end, I don't think the Cell is a bad design at all, I think it's an excellent design provided you don't try to use it like a single processor or symmetric multiprocessor with shared memory.

If the cell is well designed for games then why cannot we get the cell prosessor for pc yet? I mean its obvious thats where ibm wants to go with the cell.