PS3 vs. Xenon CPU performance
- Thread starter Shifty Geezer
- Start date
Let me see...the last time ATi bought ArtX was about the same time with the launch of the Gamecube.They are now probably aiming to merge or buy out a company which can further strenghten their position and help them out with their projects with MS and Nintendo.What company do you guys think fits in the picture for ATi?The MS next console also involves SIS right?Would XGI be a likely candidate?I remembered ArtX did help SIS during their earlier days didn't they?What would XGi contribute?
hugo said:
They did recently purchase MediaQ.
hugo said:
Highly unlikely they would go there. If they are looking to strengthen anywhere right now it looks like the consumer end of their business - take a look at todays purchase of their Cable Modem technology purchase.
MfA said:
Whether the data is current or old isn't the issue, it's where it's located.
You have two choices, you can store a copy of all state related to the environment that affect the entity in the entity itself, or you can query the environment or the info. The former requires a potentialy large amount of replicated data, since an entity in the environment could affect many other entities, the later requires querying a potentially large dataset.
There is actually some middle ground here, but it's somewhat complex to orchestrate.
If were just talking about the usual state machines that only care about minimal environmental data and the hardest problem they solve is bad pathfinding, then to be honest it isn't really much of an issue.
Come now ERP, it is possible to run a scripting language in less than 256k. 
Now, shoehorning Perl, Python, TCL, etc into your engine probably won't result in heap optimality.
But a domain specific AI language, not meant to be general purpose, could probably be quite small, possibly not even context-free.
Alot of other algorithms, like bayesian nets, neural nets, decision trees, etc can be updated in a streaming manner if you do it right.
Traversing the environment is the big issue IMHO, but sufficiently localized datastructures could solve it. After all, when humans are pathfinding, we can't see through walls and around corners like some AI pathfinding algorithms.
Now, shoehorning Perl, Python, TCL, etc into your engine probably won't result in heap optimality. But a domain specific AI language, not meant to be general purpose, could probably be quite small, possibly not even context-free.
Alot of other algorithms, like bayesian nets, neural nets, decision trees, etc can be updated in a streaming manner if you do it right.
Traversing the environment is the big issue IMHO, but sufficiently localized datastructures could solve it. After all, when humans are pathfinding, we can't see through walls and around corners like some AI pathfinding algorithms.
People talking about re-working everything to fit a particular hardware design reminds me of GPGPU. Maybe it's just me, but I think we have enough power to spend some on making our lives easier.
DemoCoder said:Come now ERP, it is possible to run a scripting language in less than 256k.
But a domain specific AI language, not meant to be general purpose, could probably be quite small, possibly not even context-free.
Alot of other algorithms, like bayesian nets, neural nets, decision trees, etc can be updated in a streaming manner if you do it right.
Traversing the environment is the big issue IMHO, but sufficiently localized datastructures could solve it. After all, when humans are pathfinding, we can't see through walls and around corners like some AI pathfinding algorithms.
Sure I can build a scripting language that would work, although I loath to design another language, but most developers seem to be using Lua or Python these days, neither of which will run well in that sort of space.
Your thinking too locally, relatively speaking pathfinding is trivial to make parallel, simply because the underlying graph is spacially coherent which always maps well to blocks of data. Yes you may have issues as you cross block boundaries, but it wouldn't kill you.
The lack of locality I'm talking about about is the interaction between entities in the environment, especially when the distribution of said entities is not permanently spacially coherent.
In my world an entity is anything that an "actor" can interact with, or has an effect on an actor. Basically its a datagathering problem, and in real problem cases accesses are not trivially localised.
One work around is to have extra data gathering entities that pool spacially local data to be queried by the "actors", but this is much harder to orchestrate than it sounds.
DemoCoder said:
Wouldn't know never tried to solve the problem.
Let me try rephrasing.
Given a dataset, that is spacially varying, you have to inspect a subset of the dataset. That subset is varying, and is temporally coherent.
In general It's for the most part spacially coherent frame to frame but changes significantly over time, so either you move the data in memory so you can DMA the chunks or you build something that maintains a spatially local version of the data (i.e. caches it). I can't see how you would implement the first solution without significant overhead and the later solution is more efficient, but none trivial to implement.
FWIW with gen2 and gen 3 games I think you will start to see more general purpose code run on the SPU's, I just don't think they will be as efficient at it as a more general processor. But as I pointed out earlier, efficiency of a single task isn't an indicator of parallel performance.
Panajev2001a
Veteran
ERP, how do you like a dual-issue, SMT design with 512 KB of L2 cache (and nice L1... they mention 32 KB, but am I right assuming it is 32 KB I-Cache and 32 KB D-Cache [Harvard architecture] or maybe 16 KB I-Cache and 16 KB D-Cache ? If the total L1 cache is 32 KB then I'd go for the 16+16 set-up, I cannot think they are going for a unified L1 cache... it would be rather odd) and high frequency of operation (better for scalar code unless the branch prediction scheme of the PU is very poor [I remember that on SPU's you are adviced to do if-then-else conversion kind of like you do on IA-64 CPU's]... oh gosh, now I have to check if the PU has a branch predictor scheme at all ) ?
I'd imagine that it should be a nice jump (an amazing leap if you ask me) over the R5900i core in the EE.
Sorry for the formatting.
) ?I'd imagine that it should be a nice jump (an amazing leap if you ask me) over the R5900i core in the EE
.Sorry for the formatting
.To me the conventional core in Cell is it's saving grace, it's not crippled and it will have good general performance. That means that initial development should be pretty painless, treat the SPU's as vertex shaders or VU's and just proceed as normal.
I think the fact that it is a good general purpose processor in and of itself points much more to datacentric algorythms being run on the PPC core and the more obvious Graphics/computationally heavy stuff being run on the SPU's.
To be honest I'm still not convinced that the balance is right, how many Flops do you really need to vertex shade? What percentage of an overall game is dependant of FP performance vs Integer performance?
Now given that PS3 will use some form of this it might drive the balance to change who knows.
All of the interesting speculation I've heard on how to effectively use Cell like processors has bee in terms of graphics algorythms. Personally I think it's a cop out, games already look good (Yes they can and will obviously look better).
I've personally done some work on parallel large scale AI, but it's going to be hard to leverage the SPU's for the general portions of that task.
I think the fact that it is a good general purpose processor in and of itself points much more to datacentric algorythms being run on the PPC core and the more obvious Graphics/computationally heavy stuff being run on the SPU's.
To be honest I'm still not convinced that the balance is right, how many Flops do you really need to vertex shade? What percentage of an overall game is dependant of FP performance vs Integer performance?
Now given that PS3 will use some form of this it might drive the balance to change who knows.
All of the interesting speculation I've heard on how to effectively use Cell like processors has bee in terms of graphics algorythms. Personally I think it's a cop out, games already look good (Yes they can and will obviously look better).
I've personally done some work on parallel large scale AI, but it's going to be hard to leverage the SPU's for the general portions of that task.
Panajev2001a
Veteran
ERP said:
Well, I was under the impression from the patents, the details posted by SiBoy here and from the presentations slides from ISSCC that the SPU's could do Integer as well as Floating-Point math at roughly the same speed (the Integer MADD takes only 1 cycle more than the FP MADD). They mention that SPU's registers are not specifically FPR, but they can hold Integer values as well as Floating-Point values.
And what about physics? That's heavily vectorized. Kinematics and dynamics are expensive vector operations. There's tesselation too. Simple vertex shading is going to be done on the GPU. I expect the SPU's to generate the vertices programmatically sometimes.
And sound processing could be extended away from the crappy CreativeLabs reverb model into full-blown wave-tracing.
And sound processing could be extended away from the crappy CreativeLabs reverb model into full-blown wave-tracing.
