5 ms·

Fun excerpt - "It would have been easier and more natural to just connect the CPU and GPU with a high-bandwidth, low-latency internal connection, but that would

by dman 16y ago

Fun excerpt - "It would have been easier and more natural to just connect the CPU and GPU with a high-bandwidth, low-latency internal connection, but that would have made the new SoC faster in some respects than the older systems, and that's not allowed."

jdc 16y ago
"Given the unique requirement of consoles -- the system must perform exactly like the original Xbox 360"
- dman 16y ago
  I just found it amusing as a design spec requirement. Usually newer systems have to go faster and do more things. Looks like they went out of their way to develop an on chip fsb like interface to slow things down.
  - _delirium 16y ago
    Yeah, it's an interesting design challenge. It seems like "design a SoC that performs exactly like discrete chips connected by a bus" is a task that'd have a lot of sneaky pitfalls. Partly depends on how close "exactly" has to be.
    - jdc 16y ago
      Though I'm far from an expert, I would think they could even out performance in software to some extent.
anigbrowl 16y ago
Well, figure that game publishers will have some of their animation/game timing routines keyed to the specifications of the original model. If the new one has more juice and programmers start taking advantage of it, Microsoft would probably get the blame for those titles' failure to run well on the older models. I was actually surprised at how smoothly Sony managed to phase out the ps/2 backward compatibility (to lower costs) from the PS3 after the first year or two. i guess it helps that you can pick up the older console for something ridiculous like $75 if there's some classic old title you can't give up. Incidentally, word is that development has already begun on PS4 games, so you know what to ask Santa for in 2012.
- jacquesm 16y ago
  > figure that game publishers will have some of their animation/game timing routines keyed to the specifications of the original model. Any game programmer worth his salt will stay away from that though. Platforms change over time and the raw speed of a platform should not be something you tie your animations to. That will already backfire when there's more or less active objects in the game. A more common approach is to tie the animation to the display frame rate by locking to the vertical refresh.
  - andrewf 16y ago
    Even if people think they've done everything right in theory, the code will never have run (let alone gone through QA) on models with different timing, and publishers wouldn't be keen on having to go back and fix flaws. Going back some years, AFAIK, you didn't necessarily have developers or build infrastructure for a title that shipped a few months ago. I don't know whether online gaming and the need to patch bugs/vulnerabilities has changed this.
- dman 16y ago
  I buy my consoles when theyre being phased out. The hardware is cheap and more importantly the catalog for the console actually exists and is usually significantly discounted too. No point buying a console early on when there are barely any games out for it. So in 2012 I will probably pick up a PS3 for ~$129.
- malkia 16y ago
  No they don't. First of all, we all run different compilation modes - debug, release, ship, etc. A lot even do LTCG (Link-Time Compile Generation) - e.g. full global opt. So there is no such thing as relying. If templates/inline members are heavily used, the difference between debug and optimized code can go somewhere between 5..10 slower. Normally for straight "C" code is only x2-x3 times, unless AltiVec is used (but only in few tight places - skinning, dsp processing, etc.) So no one ties anything to CPU. It's unreliable. Don't forget that it's not only your stuff that's running. If you are on Dolby Digital, then there would be some kind of encoder running with you. If you are doing multi-player game, then it could be that you are the one running the server (obviously made such way that no one else knows). If you are running in different resolution - same applies - different timings. If you are doing splitscreen - yup.. Another change And if you want to do real 3D - one more.... And many more (HDD presence or not - e.g. caching on the HDD or not). At the end of the day, you try to get 30fps or 60fps, and some other internal frame for the server (if multiplayer game). If you get that you are just fine. No one relies on what you've just said. That was done only on the really old machines, where you had to synchronize each horizontal scan line so you get some special effects (more colors, or more stuff being drawn). Almost anything since 1996 is not like that. Even the PS1 had different speeds, and it was TRC violation to rely on that, because Sony were smart and knew they had to emulate that in future, and exact proper emulation is not always easy.

by dman 16y ago

jdc 16y ago

"Given the unique requirement of consoles -- the system must perform exactly like the original Xbox 360"

dman 16y ago
I just found it amusing as a design spec requirement. Usually newer systems have to go faster and do more things. Looks like they went out of their way to develop an on chip fsb like interface to slow things down.
- _delirium 16y ago
  Yeah, it's an interesting design challenge. It seems like "design a SoC that performs exactly like discrete chips connected by a bus" is a task that'd have a lot of sneaky pitfalls. Partly depends on how close "exactly" has to be.
  - jdc 16y ago
    Though I'm far from an expert, I would think they could even out performance in software to some extent.

anigbrowl 16y ago

Well, figure that game publishers will have some of their animation/game timing routines keyed to the specifications of the original model. If the new one has more juice and programmers start taking advantage of it, Microsoft would probably get the blame for those titles' failure to run well on the older models. I was actually surprised at how smoothly Sony managed to phase out the ps/2 backward compatibility (to lower costs) from the PS3 after the first year or two. i guess it helps that you can pick up the older console for something ridiculous like $75 if there's some classic old title you can't give up. Incidentally, word is that development has already begun on PS4 games, so you know what to ask Santa for in 2012.

jacquesm 16y ago
> figure that game publishers will have some of their animation/game timing routines keyed to the specifications of the original model. Any game programmer worth his salt will stay away from that though. Platforms change over time and the raw speed of a platform should not be something you tie your animations to. That will already backfire when there's more or less active objects in the game. A more common approach is to tie the animation to the display frame rate by locking to the vertical refresh.
- andrewf 16y ago
  Even if people think they've done everything right in theory, the code will never have run (let alone gone through QA) on models with different timing, and publishers wouldn't be keen on having to go back and fix flaws. Going back some years, AFAIK, you didn't necessarily have developers or build infrastructure for a title that shipped a few months ago. I don't know whether online gaming and the need to patch bugs/vulnerabilities has changed this.
dman 16y ago
I buy my consoles when theyre being phased out. The hardware is cheap and more importantly the catalog for the console actually exists and is usually significantly discounted too. No point buying a console early on when there are barely any games out for it. So in 2012 I will probably pick up a PS3 for ~$129.
malkia 16y ago
No they don't. First of all, we all run different compilation modes - debug, release, ship, etc. A lot even do LTCG (Link-Time Compile Generation) - e.g. full global opt. So there is no such thing as relying. If templates/inline members are heavily used, the difference between debug and optimized code can go somewhere between 5..10 slower. Normally for straight "C" code is only x2-x3 times, unless AltiVec is used (but only in few tight places - skinning, dsp processing, etc.) So no one ties anything to CPU. It's unreliable. Don't forget that it's not only your stuff that's running. If you are on Dolby Digital, then there would be some kind of encoder running with you. If you are doing multi-player game, then it could be that you are the one running the server (obviously made such way that no one else knows). If you are running in different resolution - same applies - different timings. If you are doing splitscreen - yup.. Another change And if you want to do real 3D - one more.... And many more (HDD presence or not - e.g. caching on the HDD or not). At the end of the day, you try to get 30fps or 60fps, and some other internal frame for the server (if multiplayer game). If you get that you are just fine. No one relies on what you've just said. That was done only on the really old machines, where you had to synchronize each horizontal scan line so you get some special effects (more colors, or more stuff being drawn). Almost anything since 1996 is not like that. Even the PS1 had different speeds, and it was TRC violation to rely on that, because Sony were smart and knew they had to emulate that in future, and exact proper emulation is not always easy.