Uh, no? You have to use Chrome because not a lot of people support this device. That's way different from "locking you to Chrome". In other words, once people write programs to support it, then you don't need to rely on Google anymore (other than buying the device in the first place, of course).
I know, such as project loon, autonomous self-driving vehicles, Chrome, or even Android. Maybe an organization doesn't have to strictly do one xor the other? Or perhaps everything can be tied to ads anyway so this is just a truism?
I'd buy newspapers if I see useful stories, not the same thing rehashed online. Say, tell me about the local economics, like housing prices, which parts of town are good. You know, do some legwork for me. Alternatively, tell me how all those international news affect my community. Such as how a declining Chinese consumption will affect the local furniture export.
I did some of those optimizations on PS3/X360...and I have to ask, what the hell do console optimizations have to do with the longevity of graphics cards? The two are completely separate topics. You can still easily play today's games with a GeForce 8800 at console graphics settings (sure, that card hasn't been out for a full 8 years, but I think 6.5 years is still pretty good). Now, if you want to play 4K resolution with 8X aniso and 16X AA...well, that's a different story -- but you're never going to get that even on next gen consoles anyway.
How about I don't quite give a shit about upgrading my car every 12 months when the latest model comes out. Paying 500 bucks for 8 years of horse and buggy use is good enough for me and most of the population the horse and buggy industry serves. The rest of you can waste your money. How about I don't quite give a shit about upgrading my cell phone every 24 months when the latest model comes out. Paying 200 bucks for 8 years of phone calling use is good enough for me and most of the population the cellphone industry serves. The rest of you can waste your money. How about I don't quite give a shit...
Funny the most complete answer is the one that isn't upvoted. Yes, the AC is correct: context switching, task switching so the OS can run itself, the GPU sync that happens when a DX command is issued even though you know it should be able to just queue, the ginormous overhead even if you render one triangle (try calling Draw() x5000 with one triangle, and you'll see your performance tank), etc, etc....
On the consoles, the OS is basically like a "library" rather than a "layer" the game sits on top. That and the OS doesn't constantly swap out your threads and trash registers/L1/L2 in order to run itself. This isn't really a secret.
I'd rather we scrap both and start anew. Both of these abstraction layers are wholly inadequate for modern GPU architectures. Just the fact that both of these APIs are architected on the idea of single-threaded CPU cores building out a single, final command buffer is completely antiquated (even with DX's addition for parallel command buffer building).
With respect to the original story, how is it loaded? What's the point of brining up AMD other than to be pedantic about the GP not being more specific, even though the original story IS about Intel? And in which case, I think you just answered his question: 0% when you upgrade processor generations.
What open personal computing part? You mean I can't install Linux on RMBP? Or I can't install Windows? Which part?
Oh, you mean the non-upgradability part? Given a self-contained unit that's thinner/lighter because of the lack of removable parts vs. one which is much heftier but has removable parts, I'd take the one that's thinner and lighter. After all, I don't see people complaining about non-upgradable motherboards on laptops, so why pick some arbitrary line and evaluate everything based on that?
That's a nicer way of saying: there are too many configs to support on the PC.
It's not just a matter of "low", "medium", or "high", though...the various hardware have lots of bugs in their drivers, different CPU options, etc.... I'm sure many here have seen patch notes saying "Fix for texture corruption on the [insert specific card model, not series, here]." It really does double the cost of development to support all these different configs...all for 200k more copies (even when these aren't crappy ports). To put that into perspective: it costs around 1M in sales to break even on one console (this is a really good contract for a AAA game, btw). Now double that for including PC support. Th economics of that choice becomes really clear. =(
Now think about that further: you're a gamer that really loves the games by some company X. They support PC and so they take 1.5 times as long to make their games.That means now you get to wait 3 years instead of 2 years to enjoy their games. I'd personally be thinking to myself: I'd just take the console version so they can make games 33% faster! Etc, etc.... (Obviously these numbers are all just rough estimates...some more precise than others.)
Almost every PS3 game I have is native 1080p, all the way up to Mortal Kombat.
Man you're a stupid one. Very likely under the age of 20 given the sheer lack of knowledge you possess, which is evident in your comment history.
Again, completely shows how LITTLE you know about making games on these machines (TBH, "little" is actually too much to describe the knowledge you have on this subject). Let me guess (like many others have): did you look at the top right of your TV and took that as the native rendering resolution of your games? LOLOLOLOLOLOLOLOLOLOLOLOLOLOL. PLEASE FAIL MOAR.
I think it's conclusive to everyone reading that you're a PS3 fanboy. Nothing wrong with being a fanboy, but you should know when to stop. And don't worry, I'll answer your question (if it wasn't clear enough from my comment history): I'm a dev who actually loves the strengths and weaknesses of each platform (yes, weaknesses too, because that forces us to innovate, such as using the SPU to do post processing!).
P.S. For anyone else who's bothering reading these posts, don't take the list as set in stone...even thought it's close enough, but it's still a few dozens of pixels off here and there (mainly due to memory alignment issues).
Pal, I've written RAW ASM for both GPUs seeing whether or not they would be useful in running some of the embarrassingly parallel computations my research facility would use in every-day tasks.
"You wrote code for the 7800 and the X1800."
Considering neither supported CUDA or OpenCL (wasn't out at the time) You're pretty stupid in assuming so.
I said "wrote code"...which includes any sort of language, including ASM. Yet you took that to mean CUDA or OpenCL, despite you yourself mentioning that you wrote ASM. In other words, you actually didn't write ASM (nor HLSL/GLSL, which was what many of the high perf computing guys did before CUDA or OpenCL came onto the scene). Therefore, you were just caught flat out lying. Good job. And don't bother cuting and pasting ASM here...we don't need you copying and pasting HLSL compiler outputs on/..
So, you said you wrote code for "both GPUs" (now I'm even more confused as to which GPUs you're referring to, since you couldn't have possibly written a single line of code on the RSX, Xenos, X1800, or the 7800), yet you didn't. And even if you did write CUDA or OpenCL, you wouldn't have written it for the above four GPUs, since they aren't supported. Let's not mention the fact that you couldn't have gotten your hands on the RSX or the Xenos (dev kits) to write your imaginary code (because MS/Sony don't sell devkits to research institutes), none of your supposedly experience has any relevance whatsoever to the original discussion about Xenos vs. RSX.
Please, keep arguing and making up BS. This is becoming a fun daily exercise!
Because all non-trivial PS3 games run at interactive rates at 1080p native, right? When did amount of pixels == quality of pixels? Good thing you work in research and not in gaming! You don't even understand the difference between quality vs. quantity!
Oh, in other words, you never wrote a single line for the RSX or the XENOS. You wrote code for the 7800 and the X1800. The fact you're confusing the PC versions of those chips with the console versions for those chips simply shows how little you actually know. Please fail moar.
I think the WiiU is more powerful than current gen in many respects...but not the CPU. Some games will benefit from much more GPU horsepower and RAM, while others will suffer from less CPU power. Which is probably one reason why the GP doesn't believe it's superior.
Huh? What are you talking about? This isn't about Sony's design decision biting them in the ass. It's about Bethesda deciding to use 360 as a lead platform and taking advantage of the shared memory structure without thinking about how it'd impact the PS3. Both systems have the same total amount of memory.
If you're complaining about Sony chosing a split memory design, let me ask you this: when was the last time someone seriously complained about split CPU/GPU memory like the PC?
I don't know about "calling" anything. If people are still complaining about the PS3's Cell, they really need to get over it or learn "how it's done" and stop being ignorant devs. The real limiting factor is actually memory or GPU, which is really a PITA.
At my work, we're limited by the 360's CPU more than the SPU. We're data optimized enough to say that we're afraid of how underpowered 360's CPUs are. If anything, when the Cell came out, it was wayyyy more compute capable than x86.
Then again, you're saying that both suck, so I don't know how your posting is relevant to to the GP's post (or the original story). That and it seems like the article you linked to is obviously written by someone who doesn't know programming. Afterall, said article uses the famous Burn The House Down as reference, which says (emphasis mine):
Gameplay code will get slower and harder to write on the next generation of consoles. Modern CPUs use out-of-order execution, which is there to make crappy code run fast.
While I can attest the parent poster did actually develop for the PS3, I am sadden by the fact that he/she didn't get a chance to learn the tips&tricks of PS3 SPU programming that will, in all honesty, apply to all sorts of performance optimization work. Now to the parent:
For one, if you're worried about SPU local store memory size, there are tricks to do double/tripple/etc... buffering. There are also libs doing software caching if you're inclined. At the end of the day, you just have to realize that local store latency to main memory isn't all that different from an L2 cache hit on a "normal" CPU - they're both around 500-1000 cycles. Only difference is that for SPUs, it's manual work to DMA it over from main memory and syncing. But really, that's only 4 extra lines of code that you can wrap up into two macros.
But I think the real trouble isn't the hardware architecture, but your project's data layout. If the code accessing data all over the place (e.g. "over long distances"), then you're getting crappy performance anyway. It's not like the CPU has great prefetching (that you can't unwrap and do in the SPU anyway) or any out-of-order execution. So if you're just getting L2 misses all over the place (in your PPU), you're just stalling the CPU for those 500-1000, plain and simple.
If anything, the SPUs make you VERY concious about your data layout. At the end of the day, you're going to get much, much more improvement in speeds via good data layout (as a first step anyway) than, say, doing super-low-level assembly programming. The L2 latency wayyyyy outweighs the 10 cycles you're going to save on your tight inner loop after going to ASM. The real benefit of ASM is if you have all your data laid out in a way that you don't stall, then the throughput really matters.
For reference, people at my workplace have done AI updates on the SPU. They've also done full screen SPU post processing, animation (like you said), physics, etc...and even pathfinding! I'll even take your example. Do you need all 256k? Can you not cull out data on the PPU that you know won't be needed off hand? If you already compartmentalized each cell, then you certainly have enough information to work for a while on one cell. Then you can grab the potential references to each adjacent cell as you path to them and stream them in as you continue working. You can even predict which cells you need ahead of time and prefetch them, and discarding them when it doesn't look like you'd need them as you process more of your current cell. It's not like your A* isn't operating on triangles anymore, so you always have a finite set of triangles that you have to compute through before you can do anything else.
Exactly. The mutual destruction endgame prevention scenario only applies to nations or groups of people with something to lose. Not everyone/group who have the means to get a nuke has something to lose....
The point is, an Apple store sales employee doesn't require much skills. They just stand there and people throw money at them. They don't even need to try and sell products to customers!
Slashdot Mirror
Uh, no? You have to use Chrome because not a lot of people support this device. That's way different from "locking you to Chrome". In other words, once people write programs to support it, then you don't need to rely on Google anymore (other than buying the device in the first place, of course).
I know, such as project loon, autonomous self-driving vehicles, Chrome, or even Android. Maybe an organization doesn't have to strictly do one xor the other? Or perhaps everything can be tied to ads anyway so this is just a truism?
I'd buy newspapers if I see useful stories, not the same thing rehashed online. Say, tell me about the local economics, like housing prices, which parts of town are good. You know, do some legwork for me. Alternatively, tell me how all those international news affect my community. Such as how a declining Chinese consumption will affect the local furniture export.
I did some of those optimizations on PS3/X360...and I have to ask, what the hell do console optimizations have to do with the longevity of graphics cards? The two are completely separate topics. You can still easily play today's games with a GeForce 8800 at console graphics settings (sure, that card hasn't been out for a full 8 years, but I think 6.5 years is still pretty good). Now, if you want to play 4K resolution with 8X aniso and 16X AA...well, that's a different story -- but you're never going to get that even on next gen consoles anyway.
How about I don't quite give a shit about upgrading my car every 12 months when the latest model comes out. Paying 500 bucks for 8 years of horse and buggy use is good enough for me and most of the population the horse and buggy industry serves. The rest of you can waste your money.
How about I don't quite give a shit about upgrading my cell phone every 24 months when the latest model comes out. Paying 200 bucks for 8 years of phone calling use is good enough for me and most of the population the cellphone industry serves. The rest of you can waste your money.
How about I don't quite give a shit...
Funny the most complete answer is the one that isn't upvoted. Yes, the AC is correct: context switching, task switching so the OS can run itself, the GPU sync that happens when a DX command is issued even though you know it should be able to just queue, the ginormous overhead even if you render one triangle (try calling Draw() x5000 with one triangle, and you'll see your performance tank), etc, etc....
On the consoles, the OS is basically like a "library" rather than a "layer" the game sits on top. That and the OS doesn't constantly swap out your threads and trash registers/L1/L2 in order to run itself. This isn't really a secret.
I'd rather we scrap both and start anew. Both of these abstraction layers are wholly inadequate for modern GPU architectures. Just the fact that both of these APIs are architected on the idea of single-threaded CPU cores building out a single, final command buffer is completely antiquated (even with DX's addition for parallel command buffer building).
With respect to the original story, how is it loaded? What's the point of brining up AMD other than to be pedantic about the GP not being more specific, even though the original story IS about Intel? And in which case, I think you just answered his question: 0% when you upgrade processor generations.
What open personal computing part? You mean I can't install Linux on RMBP? Or I can't install Windows? Which part?
Oh, you mean the non-upgradability part? Given a self-contained unit that's thinner/lighter because of the lack of removable parts vs. one which is much heftier but has removable parts, I'd take the one that's thinner and lighter. After all, I don't see people complaining about non-upgradable motherboards on laptops, so why pick some arbitrary line and evaluate everything based on that?
Detractors made similar claims when people wanted 2560x1600. Look where we're at now....
That's a nicer way of saying: there are too many configs to support on the PC.
It's not just a matter of "low", "medium", or "high", though...the various hardware have lots of bugs in their drivers, different CPU options, etc.... I'm sure many here have seen patch notes saying "Fix for texture corruption on the [insert specific card model, not series, here]." It really does double the cost of development to support all these different configs...all for 200k more copies (even when these aren't crappy ports). To put that into perspective: it costs around 1M in sales to break even on one console (this is a really good contract for a AAA game, btw). Now double that for including PC support. Th economics of that choice becomes really clear. =(
Now think about that further: you're a gamer that really loves the games by some company X. They support PC and so they take 1.5 times as long to make their games.That means now you get to wait 3 years instead of 2 years to enjoy their games. I'd personally be thinking to myself: I'd just take the console version so they can make games 33% faster! Etc, etc.... (Obviously these numbers are all just rough estimates...some more precise than others.)
Almost every PS3 game I have is native 1080p, all the way up to Mortal Kombat.
Man you're a stupid one. Very likely under the age of 20 given the sheer lack of knowledge you possess, which is evident in your comment history.
Again, completely shows how LITTLE you know about making games on these machines (TBH, "little" is actually too much to describe the knowledge you have on this subject). Let me guess (like many others have): did you look at the top right of your TV and took that as the native rendering resolution of your games? LOLOLOLOLOLOLOLOLOLOLOLOLOLOL. PLEASE FAIL MOAR.
I think it's conclusive to everyone reading that you're a PS3 fanboy. Nothing wrong with being a fanboy, but you should know when to stop. And don't worry, I'll answer your question (if it wasn't clear enough from my comment history): I'm a dev who actually loves the strengths and weaknesses of each platform (yes, weaknesses too, because that forces us to innovate, such as using the SPU to do post processing!).
P.S. For anyone else who's bothering reading these posts, don't take the list as set in stone...even thought it's close enough, but it's still a few dozens of pixels off here and there (mainly due to memory alignment issues).
Pal, I've written RAW ASM for both GPUs seeing whether or not they would be useful in running some of the embarrassingly parallel computations my research facility would use in every-day tasks.
"You wrote code for the 7800 and the X1800."
Considering neither supported CUDA or OpenCL (wasn't out at the time) You're pretty stupid in assuming so.
I said "wrote code"...which includes any sort of language, including ASM. Yet you took that to mean CUDA or OpenCL, despite you yourself mentioning that you wrote ASM. In other words, you actually didn't write ASM (nor HLSL/GLSL, which was what many of the high perf computing guys did before CUDA or OpenCL came onto the scene). Therefore, you were just caught flat out lying. Good job. And don't bother cuting and pasting ASM here...we don't need you copying and pasting HLSL compiler outputs on /..
So, you said you wrote code for "both GPUs" (now I'm even more confused as to which GPUs you're referring to, since you couldn't have possibly written a single line of code on the RSX, Xenos, X1800, or the 7800), yet you didn't. And even if you did write CUDA or OpenCL, you wouldn't have written it for the above four GPUs, since they aren't supported. Let's not mention the fact that you couldn't have gotten your hands on the RSX or the Xenos (dev kits) to write your imaginary code (because MS/Sony don't sell devkits to research institutes), none of your supposedly experience has any relevance whatsoever to the original discussion about Xenos vs. RSX.
Please, keep arguing and making up BS. This is becoming a fun daily exercise!
Because all non-trivial PS3 games run at interactive rates at 1080p native, right? When did amount of pixels == quality of pixels? Good thing you work in research and not in gaming! You don't even understand the difference between quality vs. quantity!
Oh, in other words, you never wrote a single line for the RSX or the XENOS. You wrote code for the 7800 and the X1800. The fact you're confusing the PC versions of those chips with the console versions for those chips simply shows how little you actually know. Please fail moar.
Oh you're one of those MOAR FLOPS == MOAR BETTAR people who haven't written a shred of real software for these platforms. Ok. =)
Cheaped out on the RAM how? You mean how the X360 has 512MB and the PS3 has 512MB? Or do you mean the bus to access said RAM?
Superior GPU? Have you even WORKED on a PS3 or X360 before? CPU definitely yes, GPU definitely no.
I think the WiiU is more powerful than current gen in many respects...but not the CPU. Some games will benefit from much more GPU horsepower and RAM, while others will suffer from less CPU power. Which is probably one reason why the GP doesn't believe it's superior.
Huh? What are you talking about? This isn't about Sony's design decision biting them in the ass. It's about Bethesda deciding to use 360 as a lead platform and taking advantage of the shared memory structure without thinking about how it'd impact the PS3. Both systems have the same total amount of memory.
If you're complaining about Sony chosing a split memory design, let me ask you this: when was the last time someone seriously complained about split CPU/GPU memory like the PC?
At my work, we're limited by the 360's CPU more than the SPU. We're data optimized enough to say that we're afraid of how underpowered 360's CPUs are. If anything, when the Cell came out, it was wayyyy more compute capable than x86.
Then again, you're saying that both suck, so I don't know how your posting is relevant to to the GP's post (or the original story). That and it seems like the article you linked to is obviously written by someone who doesn't know programming. Afterall, said article uses the famous Burn The House Down as reference, which says (emphasis mine):
Gameplay code will get slower and harder to write on the next generation of consoles. Modern CPUs use out-of-order execution, which is there to make crappy code run fast.
So yeah, crappy code will always be crappy code.
While I can attest the parent poster did actually develop for the PS3, I am sadden by the fact that he/she didn't get a chance to learn the tips&tricks of PS3 SPU programming that will, in all honesty, apply to all sorts of performance optimization work. Now to the parent:
For one, if you're worried about SPU local store memory size, there are tricks to do double/tripple/etc... buffering. There are also libs doing software caching if you're inclined. At the end of the day, you just have to realize that local store latency to main memory isn't all that different from an L2 cache hit on a "normal" CPU - they're both around 500-1000 cycles. Only difference is that for SPUs, it's manual work to DMA it over from main memory and syncing. But really, that's only 4 extra lines of code that you can wrap up into two macros.
But I think the real trouble isn't the hardware architecture, but your project's data layout. If the code accessing data all over the place (e.g. "over long distances"), then you're getting crappy performance anyway. It's not like the CPU has great prefetching (that you can't unwrap and do in the SPU anyway) or any out-of-order execution. So if you're just getting L2 misses all over the place (in your PPU), you're just stalling the CPU for those 500-1000, plain and simple.
If anything, the SPUs make you VERY concious about your data layout. At the end of the day, you're going to get much, much more improvement in speeds via good data layout (as a first step anyway) than, say, doing super-low-level assembly programming. The L2 latency wayyyyy outweighs the 10 cycles you're going to save on your tight inner loop after going to ASM. The real benefit of ASM is if you have all your data laid out in a way that you don't stall, then the throughput really matters.
For reference, people at my workplace have done AI updates on the SPU. They've also done full screen SPU post processing, animation (like you said), physics, etc...and even pathfinding! I'll even take your example. Do you need all 256k? Can you not cull out data on the PPU that you know won't be needed off hand? If you already compartmentalized each cell, then you certainly have enough information to work for a while on one cell. Then you can grab the potential references to each adjacent cell as you path to them and stream them in as you continue working. You can even predict which cells you need ahead of time and prefetch them, and discarding them when it doesn't look like you'd need them as you process more of your current cell. It's not like your A* isn't operating on triangles anymore, so you always have a finite set of triangles that you have to compute through before you can do anything else.
It really is all about the data, man.
Exactly. The mutual destruction endgame prevention scenario only applies to nations or groups of people with something to lose. Not everyone/group who have the means to get a nuke has something to lose....
The point is, an Apple store sales employee doesn't require much skills. They just stand there and people throw money at them. They don't even need to try and sell products to customers!