Um...EME is tied specifically to the video tag. How in the world do you use a video to do all of the stuff you mentioned above? Show them a video and force them to type what's in the video??? That's why it's called Encrypted MEDIA Extensions.
And they want an internet for them, not you. Works both ways.
Put it this way, can you access the private portions of some government website without risk of getting charged with something criminal (assuming you're not a government employee/contractor/etc...)? Is that part open? No. Then why aren't you complaining about it? Oh, that's server-side you say. Then how about Netflix? You have to install Silverlight so they can protect their content (assuming it protects their content). I don't hear you complaining about that either. So what's the difference between you having to install a plug-in vs. it's built right into the browser? The end game is still the same: do you get access to the content or not, not whether this is open or not.
That's a fine way to think about it. But if you don't want it, doesn't mean others don't want it. And if you think it's so easy to crack, then why do you care? Just let the content owners have that false sense of security if you think it's so easy to crack.
I get your concern. But what's this "non-EME content" you're talking about? YouTube videos? Because that's the only thing that comes to mind (beyond vimeo, et al).
The average YT videos run on a viral + ad assumption. People won't pay for the average YT video. Sure, the owner of the average content may be deluded to think that he/she will make more money by turning on DRM, but I'm pretty sure they'll learn quickly. This is how capitalism works.
I think the argument that everything will turn EME-only work about as well as the argument that all apps on the app store are going to be paid content. Turns out most of them are freemium games nowadays. In YT, the ads are the in-app purchases.
If DRM is so bad, how is Netflix making money? How is YouTube making money? The point is, content providers provide a marketplace for content owners to show their work. If content owners believes that turning on DRM will help them make money, they will turn it on. If it turns out that it doesn't, they should turn it off. Isn't this how capitalism works (they also fail if they're stupid, of course)?
And as to your arrrrr issue, well, if they can keep the numbers below 1%, I doubt they'll ever care. It's not a black of white issue, and all of a sudden everyone on the planet flocks to the arrrrr site. It's all about the gradients, not some sort of 0/1 binary decision.
Of course you can. Fox example, Chrome does this with Chromium. All the DRM is stripped out of Chromium, but you can still build the Chromium browser and browse non-EME content with it.
If it's so laughable, then isn't it better to just have it? So instead of a world where content owners won't publish jack on HTML5 (you read that right, content owners of the content you're willing to pay for will never publish on HTML5 unless they have some sort of DRM), you get a world where content owners would and you can somehow mine the keys. I don't see how this is any worse.
Calm down, son. If you can't see from context of the thread or my paragraph that everyone in this thread is talking about Mantle and not hardware specs (i.e. brute forcing past the draw call issue), then there really is no hope or point in further educating you. The fact that you don't even understand that draw call limitations are CPU-bound and not (presently) GPU-bound shows how little you know of this subject. Now that you understand this is a CPU issue, where could you find a CPU that matched the computational throughput of a Cell processor or the SPU's guaranteed 5 cycle latency? Intel processors couldn't even come close at the time (the Core 2 was released in mid 2006, a few months before the PS3). Sure, the Core 2 could've done better than Cell in heavily branching code, but by many other measures (throughput, latency, etc...), the Cell is much better than the Core 2.
Anyway, it's clear that you don't understand even the basics of what's going on, I'll just leave this link for you to read over at Anandtech...if you know what's good for you.
Yeah, it's hard to believe. But we've done experiments and seen the result. It definitely depends on your engine setup. If everything is just one uber shader in a forward rendering engine, this isn't going to be as much of an issue since you can easily batch (although you're going to hit fragment shader limits in terms of registers/compute very fast, not to mention keeping all of the combinations manageable). On the other hand, if you have artist-made materials, multiple alpha transparency settings, etc..., you're going to see that increasing draw call performance is going to dramatically speed up your game. Batching only gets you more of the same, and game artists hate more of the same.
Also do note that modern games do multiple passes on the scene. Shadow maps, gloss generation, normal generation, etc...and each of them multiplies against the number of draw calls per single layer. These all get factored in, and none of them can be batched across passes.
And to respond to your question about the AC's post, if you carefully read what he/she says, you can see that those are valid concerns the gaming industry has as a whole. So it's pretty clear that the person has at least some fundamental knowledge of what he/she is talking about with respect to the state of the industry. And if you visit some of my previous posts (not that you'd necessarily have the time, I'm just offering other opinions), you'd see other game devs agreeing on the issue that OGL/DX are dramatic overheads to PC graphics.
Awesome, you just went ahead and showed off how ignorant you are and how much you're frothing at the mouth for your supposed PC Master Race "superiority". There are so many factual errors in your reply that it's going to take a while to respond to.
If you want to say that consoles are holding PC development back TODAY, sure, I can work with that. But if you weren't blind, you'd see that I said I can't find current day console ports that are limited on draw calls. After all, PCs have brute forced their way past consoles. On the other hand, when the current gen console games were first released (that is, 6+ years ago), there were definitely draw call limitations on their PC ports. For that matter, I'm not sure why you're railing so hard on modern day ports. Obviously the progression of time would've solved some issues. So you only need to look further than any of the PS3-only dev houses a few years back to realize none of those games could ever run on a PC at the time (pick any game out of Naughty Dog, Insomniac, Sucker Punch, Gorilla, etc... I'm sure there are X360 houses that work just as well). Your frivolous arguments against draw calls being an issue when next gen comes out (in two months) hold as much water as saying that that 640KB is enough for everyone.
Besides, let's face it, are the engineers at AMD clueless? Are PC/console game devs clueless? Are the guys who wrote LibGCM clueless? If you think they're smart, then AMD either wouldn't have released this or AMD would've been criticized for doing so (by devs and/or tech sites). Neither of this has happened. So there is only one conclusion we can draw: you think you're so smart that all other developers are idiots. In that case, please keep talking, because I think this is comedy goldmine for all the devs reading (PCs AND consoles).
The point you keep missing is hardware keeps moving forward, including consoles (albeit at a 7+ year interval now). When consoles catch up in hardware, the games are going to blast draw calls because of the availability of low level graphics libraries. When those games get ported to PCs (or co-developed), the PCs will be bottlenecked by draw calls if they keep using DX or whatever the high level gfx libs are for PS4. I think if hardware/software devs are as shortsighted as you, then PC ports will be unplayable. Just because PC games don't make a lot of draw calls now doesn't mean they won't in two months. Then again, maybe the point is that PCs are holding back consoles because they can't perform those draw calls.
And again, since you're of the PC Master Race, I'm sure all you think about is how to jack off to your dual Titan graphics cards + i7-4770...all the while forgetting that all but Crysis will target much lower hardware platforms. I.e. they will be much slower and will handle draw calls at much, much worse rates. Have you tried gaming on anything but enthusiast PCs? That's, they don't have any of the "massive underutilized power" that you so passionately claim.
As for you claiming that I didn't disproved what you said...well, I was never trying to disprove that the memory vs. CPU speed gap isn't a problem (and if you knew how to read, you would've seen this in point 4) two posts ago). The problem with all of your arguments is that you're missing the forest for the tree. The biggest problem that hinders even PC performance is draw calls; somewhere further down the list is your memory bandwidth/CPU disparity issues. It's clear you don't even know what Amdahl's law is -- you keep barking up the parallel tree when the biggest gains are going to come from optimizing the serial portions.
LOL, you're not fooling anyone with your arguments. You first talk about "Memory bandwidth has been the KEY factor in framerates." Then you move on to saying Epic cares about memory [size]. Then you jump to talking how none of that matters because all people care about are fun games. I love how you jump from point to point because you don't even know what you're talking about. Since you offer so little detail and like to quote Epic, I think it's pretty obvious to everyone here that you're a raving fanboy of the PC Master Race, and definitely not someone technical at all -- exactly the type of person that entertain us devs.
I think one thing you utterly failed to understand is that we engine devs only care about performance. We make our engine run fast so that our pals in the gameplay department can make the game fun and interesting. If our engines run slow, then their gameplay suffers because they can't have as many AI simultaneously, can't have as many enemies on screen (drawing, AI, physics, you name it), etc.... There are only a fixed number of cycles in a CPU every time delta; if we take one cycle, that's one less cycle for gameplay. If you can't understand that distinction, then I don't know what position you're in to argue. It's clear that "you know about this" in the sense you read some comments out of context on some random forum.
Here are a few other points:
* If you think that performance isn't an issue, why did you even bring up bandwidth numbers?
* If "There is this thing called 'good enough' and we've been there for the last 6-8 years." is true, then why do you complain about PS3/XBox360 holding PC gaming back? Afterall, they're from 6-8 years ago (and they were close to top-of-the-line back then).
* Yeah, I definitely can't find any current day console ports that are limited on draw calls, but that's because (if you read any of the articles on the tech sites about Mantle) video cards have brute forced their way out of the problem. But I'm sure if there was any console ports back in 2007 (or after LibGCM got released), they would benefit from it. Furthermore, you're asking for selective bias -- if a console game was draw call limited, the chances of it making to the PC world would decrease. So what you're asking for is just plain absurd. But now that the new generation is ahead of us? Yeah, the draw call issue will come to the forefront again.
Oh wow, you're vitriolic when you're proven wrong, aren't you?
1) Draw call overhead is a problem of CPU utilization and synchronization. On the CPU end, the drivers have to check a bunch of states before moving forward with the draw call (yes, like you said, this hits DRAM, but...!). During this check, the CPU may stall and stop handing instructions to the GPU until the GPU finishes with its current tasks (read: a sync), which stalls both the CPU and GPU. When you have 10000+ threads in flight, a pipeline flush is terrible for performance.
However, if you didn't have to check the states in the first place, there isn't such a problem, which is what Mantle allows. The problem with OpenGL (in the eyes of advanced developers) is exactly the safety net OGL provides for beginner developers. It's akin to an API function stubbornly checking its input parameters, even if you, the user of the API, already know that the inputs you provided to the API are valid.
2) Have you ever developed for Cell SPUs? The pros at doing so aren't complaining that the DRAM is too slow -- they're complaining that they don't have enough SPUs to do the wonderful things they can do with it. And since you're all up there quoting Itanium, you probably don't know the SPU only has 256KB (that's kilo, not mega or giga) of local store (i.e. local DRAM-thing). That and if you used Itanium as the counterexample, you just defined yourself out of the game development world.
3) If you understand the points in 1), then you'll realize that the reason for having the 10000+ threads in flight: to hide memory latency. When you flush all that (like what OGL and DX potentially do), you incur all of the memory latency again. The point of Mantle is to not have to flush nearly as often.
4) Yes, the CPU-memory gap is a valid problem. But in the game development world where most of the compute-intensive stuff already know ahead of time what portions of data the computations need to access, most of these problems are mitigated (e.g. latency hiding, prefetching, etc...). In other words, you're raising a problem that isn't even close to the biggest set of problems in the game development world. It's not like game developers are writing a huge database program that has no idea which part of main memory they're going to touch on the next request.
You are correct, and this is where a big chunk of work in graphics engines go into. But a lot of times, the batching just doesn't work well. For example, you can't batch well when you have custom materials written by artists (it used to work when there were only about 20 different materials -- you just set the textures and a few uniforms, and off you go). So having the flexibility of draw calls is definitely valuable here. Also, draw calls aren't the only performance bottlenecks imposed by DX/OGL.
I'm sorry, but you're the one who's clearly full of shit. GP clearly has some experience doing console/PC game programming. You clearly don't. Have you tried making 10k draw calls per frame on DX/OGL? Do the same in LibGSM, and you'll know the day-and-night difference (read: you can make hundreds of thousands of draw calls on the PS3, which is 6+ years old, without breaking a sweat). The point you don't understand is, the overhead isn't on the GPU -- it's on the CPU. Think Amdhal's law; the single threaded bottleneck is on CPU, and the speedup in PC graphics you see is from the parallel speedup in the GPU. The point of Mantle is to get rid of the CPU overhead, not somehow magically make the GPU faster.
3. Sorry, you're completely wrong. Try making 10k calls per frame (30fps) on a modern high-end PC (use the latest Haswell i7 + 7970/780 if you want), and your game will still slow down quite a bit due to single-threaded CPU overhead. On the PS3 (which is over 6 years old now?), you can make hundreds of thousands of draw calls per frame on libGSM and get away with it just fine. Why? Simple: every time you make a draw call on OpenGL/DX, you have to validate/potentially flush/sync all sorts of states. On libGSM (and to some extent, the special DX on the X360), it's a simple "write 4-byte value to command buffer, which is in CPU land". Yeah, semi-immediate/deferred mode 4TL.
And that's exactly the problem: good enough for you isn't good enough for everyone. So just like the other posters said, you lost all credibility when you think you're the only use case on this planet and went on to trash other users for something you admittedly knew nothing about.
While I'd like a citation as well, you make it seem like "no way in hell 1M people died". Ok, well, you tell me how many died (in the various forms of "died", e.g. list by radiation poisoning, cancer, etc...)? And can you back that up with citations as well? And while you're at it, please provide modest proofs of credibility of those who you cited.
Except you're the one being a total ass, as you were the one who asked gweihir for the proof (and by context, that would be Chernobyl; TMI, on the other hand, I'm sure you can Google). So now you do a 180 and say this is about Fukushima? Then why did you ask for proof in the first place? Oh wait, you're an ass, I forgot.
Exactly -- I am who I was. I would be fine waking up with my cognitive state slightly distorted...at least I'd still be "more or less" myself and feel that my existence continues.
Why do people have absolutely no imagination? If the future humanity can revive you through freezing you up like a frozen chicken, why would you assume that, by then, our future humanity haven't developed the technology to reconstruct your body to its 20 year old state? Hell, I'd wager that we'd develop the technology to keep us immortal through stem cells before we figure out how to thaw a frozen mouse and keep its cognitive abilities.
If anything, you are enforcing better modularization/encapsulation/organization. You're forced to not use anonymous namespaces, because then all the symbols clash. You HAVE to put everything into their own namespace.
And I'm not sure how you think this is a losing strategy. If you've worked on large projects, link time becomes a PITA partly because of the number of files involved. There are tools out there that took 30 minutes to link when there are a ton compiled files. When you drop that number down to 4, it links in mere minute or two. Also, compile time takes a dive (in a good way) -- instead of each.cpp and.h file opening up all their includes, you get just four.cpp opening up includes (can't avoid the.h includes). So instead of taking 2 seconds per file to compile 2000 files (plus a long link time), you take like 5 seconds per file to compile 4 files (plus a short link time). Any way you slice it, it was a boon to productivity for our team.
When I drive on the freeway and get stuck behind a slow moving car on the left lane, it's 50/50 that it's someone on the phone. Now, when I do a random sampling of people driving, I notice less than 20% on the phone. I think that says something?
Yeah, it's possible (I worked on AAA games with a few million lines of code). In VS, take your whole code base, flatten to one project, make 4 (or any small number) new.cpp files and alternately include all other SOURCE.cpp files into these (and disable all compiling on all other files in this configuration). Each file will take about 30 seconds to compile...but you have 4+ cores, so it takes 30 seconds to compile all 4 files. Linking is much faster too. This was done because linking on the PS3 used to take 20 minutes (this was within the first year of the console's release).
Slashdot Mirror
Um...EME is tied specifically to the video tag. How in the world do you use a video to do all of the stuff you mentioned above? Show them a video and force them to type what's in the video??? That's why it's called Encrypted MEDIA Extensions.
And they want an internet for them, not you. Works both ways.
Put it this way, can you access the private portions of some government website without risk of getting charged with something criminal (assuming you're not a government employee/contractor/etc...)? Is that part open? No. Then why aren't you complaining about it? Oh, that's server-side you say. Then how about Netflix? You have to install Silverlight so they can protect their content (assuming it protects their content). I don't hear you complaining about that either. So what's the difference between you having to install a plug-in vs. it's built right into the browser? The end game is still the same: do you get access to the content or not, not whether this is open or not.
That's a fine way to think about it. But if you don't want it, doesn't mean others don't want it. And if you think it's so easy to crack, then why do you care? Just let the content owners have that false sense of security if you think it's so easy to crack.
I get your concern. But what's this "non-EME content" you're talking about? YouTube videos? Because that's the only thing that comes to mind (beyond vimeo, et al).
The average YT videos run on a viral + ad assumption. People won't pay for the average YT video. Sure, the owner of the average content may be deluded to think that he/she will make more money by turning on DRM, but I'm pretty sure they'll learn quickly. This is how capitalism works.
I think the argument that everything will turn EME-only work about as well as the argument that all apps on the app store are going to be paid content. Turns out most of them are freemium games nowadays. In YT, the ads are the in-app purchases.
I fail to see your argument.
If DRM is so bad, how is Netflix making money? How is YouTube making money? The point is, content providers provide a marketplace for content owners to show their work. If content owners believes that turning on DRM will help them make money, they will turn it on. If it turns out that it doesn't, they should turn it off. Isn't this how capitalism works (they also fail if they're stupid, of course)?
And as to your arrrrr issue, well, if they can keep the numbers below 1%, I doubt they'll ever care. It's not a black of white issue, and all of a sudden everyone on the planet flocks to the arrrrr site. It's all about the gradients, not some sort of 0/1 binary decision.
Of course you can. Fox example, Chrome does this with Chromium. All the DRM is stripped out of Chromium, but you can still build the Chromium browser and browse non-EME content with it.
If it's so laughable, then isn't it better to just have it? So instead of a world where content owners won't publish jack on HTML5 (you read that right, content owners of the content you're willing to pay for will never publish on HTML5 unless they have some sort of DRM), you get a world where content owners would and you can somehow mine the keys. I don't see how this is any worse.
Calm down, son. If you can't see from context of the thread or my paragraph that everyone in this thread is talking about Mantle and not hardware specs (i.e. brute forcing past the draw call issue), then there really is no hope or point in further educating you. The fact that you don't even understand that draw call limitations are CPU-bound and not (presently) GPU-bound shows how little you know of this subject. Now that you understand this is a CPU issue, where could you find a CPU that matched the computational throughput of a Cell processor or the SPU's guaranteed 5 cycle latency? Intel processors couldn't even come close at the time (the Core 2 was released in mid 2006, a few months before the PS3). Sure, the Core 2 could've done better than Cell in heavily branching code, but by many other measures (throughput, latency, etc...), the Cell is much better than the Core 2.
Anyway, it's clear that you don't understand even the basics of what's going on, I'll just leave this link for you to read over at Anandtech...if you know what's good for you.
Yeah, it's hard to believe. But we've done experiments and seen the result. It definitely depends on your engine setup. If everything is just one uber shader in a forward rendering engine, this isn't going to be as much of an issue since you can easily batch (although you're going to hit fragment shader limits in terms of registers/compute very fast, not to mention keeping all of the combinations manageable). On the other hand, if you have artist-made materials, multiple alpha transparency settings, etc..., you're going to see that increasing draw call performance is going to dramatically speed up your game. Batching only gets you more of the same, and game artists hate more of the same.
Also do note that modern games do multiple passes on the scene. Shadow maps, gloss generation, normal generation, etc...and each of them multiplies against the number of draw calls per single layer. These all get factored in, and none of them can be batched across passes.
And to respond to your question about the AC's post, if you carefully read what he/she says, you can see that those are valid concerns the gaming industry has as a whole. So it's pretty clear that the person has at least some fundamental knowledge of what he/she is talking about with respect to the state of the industry. And if you visit some of my previous posts (not that you'd necessarily have the time, I'm just offering other opinions), you'd see other game devs agreeing on the issue that OGL/DX are dramatic overheads to PC graphics.
Awesome, you just went ahead and showed off how ignorant you are and how much you're frothing at the mouth for your supposed PC Master Race "superiority". There are so many factual errors in your reply that it's going to take a while to respond to.
If you want to say that consoles are holding PC development back TODAY, sure, I can work with that. But if you weren't blind, you'd see that I said I can't find current day console ports that are limited on draw calls. After all, PCs have brute forced their way past consoles. On the other hand, when the current gen console games were first released (that is, 6+ years ago), there were definitely draw call limitations on their PC ports. For that matter, I'm not sure why you're railing so hard on modern day ports. Obviously the progression of time would've solved some issues. So you only need to look further than any of the PS3-only dev houses a few years back to realize none of those games could ever run on a PC at the time (pick any game out of Naughty Dog, Insomniac, Sucker Punch, Gorilla, etc... I'm sure there are X360 houses that work just as well). Your frivolous arguments against draw calls being an issue when next gen comes out (in two months) hold as much water as saying that that 640KB is enough for everyone.
Besides, let's face it, are the engineers at AMD clueless? Are PC/console game devs clueless? Are the guys who wrote LibGCM clueless? If you think they're smart, then AMD either wouldn't have released this or AMD would've been criticized for doing so (by devs and/or tech sites). Neither of this has happened. So there is only one conclusion we can draw: you think you're so smart that all other developers are idiots. In that case, please keep talking, because I think this is comedy goldmine for all the devs reading (PCs AND consoles).
The point you keep missing is hardware keeps moving forward, including consoles (albeit at a 7+ year interval now). When consoles catch up in hardware, the games are going to blast draw calls because of the availability of low level graphics libraries. When those games get ported to PCs (or co-developed), the PCs will be bottlenecked by draw calls if they keep using DX or whatever the high level gfx libs are for PS4. I think if hardware/software devs are as shortsighted as you, then PC ports will be unplayable. Just because PC games don't make a lot of draw calls now doesn't mean they won't in two months. Then again, maybe the point is that PCs are holding back consoles because they can't perform those draw calls.
And again, since you're of the PC Master Race, I'm sure all you think about is how to jack off to your dual Titan graphics cards + i7-4770...all the while forgetting that all but Crysis will target much lower hardware platforms. I.e. they will be much slower and will handle draw calls at much, much worse rates. Have you tried gaming on anything but enthusiast PCs? That's, they don't have any of the "massive underutilized power" that you so passionately claim.
As for you claiming that I didn't disproved what you said...well, I was never trying to disprove that the memory vs. CPU speed gap isn't a problem (and if you knew how to read, you would've seen this in point 4) two posts ago). The problem with all of your arguments is that you're missing the forest for the tree. The biggest problem that hinders even PC performance is draw calls; somewhere further down the list is your memory bandwidth/CPU disparity issues. It's clear you don't even know what Amdahl's law is -- you keep barking up the parallel tree when the biggest gains are going to come from optimizing the serial portions.
LOL, you're not fooling anyone with your arguments. You first talk about "Memory bandwidth has been the KEY factor in framerates." Then you move on to saying Epic cares about memory [size]. Then you jump to talking how none of that matters because all people care about are fun games. I love how you jump from point to point because you don't even know what you're talking about. Since you offer so little detail and like to quote Epic, I think it's pretty obvious to everyone here that you're a raving fanboy of the PC Master Race, and definitely not someone technical at all -- exactly the type of person that entertain us devs.
I think one thing you utterly failed to understand is that we engine devs only care about performance. We make our engine run fast so that our pals in the gameplay department can make the game fun and interesting. If our engines run slow, then their gameplay suffers because they can't have as many AI simultaneously, can't have as many enemies on screen (drawing, AI, physics, you name it), etc.... There are only a fixed number of cycles in a CPU every time delta; if we take one cycle, that's one less cycle for gameplay. If you can't understand that distinction, then I don't know what position you're in to argue. It's clear that "you know about this" in the sense you read some comments out of context on some random forum.
Here are a few other points:
* If you think that performance isn't an issue, why did you even bring up bandwidth numbers?
* If "There is this thing called 'good enough' and we've been there for the last 6-8 years." is true, then why do you complain about PS3/XBox360 holding PC gaming back? Afterall, they're from 6-8 years ago (and they were close to top-of-the-line back then).
* Yeah, I definitely can't find any current day console ports that are limited on draw calls, but that's because (if you read any of the articles on the tech sites about Mantle) video cards have brute forced their way out of the problem. But I'm sure if there was any console ports back in 2007 (or after LibGCM got released), they would benefit from it. Furthermore, you're asking for selective bias -- if a console game was draw call limited, the chances of it making to the PC world would decrease. So what you're asking for is just plain absurd. But now that the new generation is ahead of us? Yeah, the draw call issue will come to the forefront again.
Oh wow, you're vitriolic when you're proven wrong, aren't you?
1) Draw call overhead is a problem of CPU utilization and synchronization. On the CPU end, the drivers have to check a bunch of states before moving forward with the draw call (yes, like you said, this hits DRAM, but...!). During this check, the CPU may stall and stop handing instructions to the GPU until the GPU finishes with its current tasks (read: a sync), which stalls both the CPU and GPU. When you have 10000+ threads in flight, a pipeline flush is terrible for performance.
However, if you didn't have to check the states in the first place, there isn't such a problem, which is what Mantle allows. The problem with OpenGL (in the eyes of advanced developers) is exactly the safety net OGL provides for beginner developers. It's akin to an API function stubbornly checking its input parameters, even if you, the user of the API, already know that the inputs you provided to the API are valid.
2) Have you ever developed for Cell SPUs? The pros at doing so aren't complaining that the DRAM is too slow -- they're complaining that they don't have enough SPUs to do the wonderful things they can do with it. And since you're all up there quoting Itanium, you probably don't know the SPU only has 256KB (that's kilo, not mega or giga) of local store (i.e. local DRAM-thing). That and if you used Itanium as the counterexample, you just defined yourself out of the game development world.
3) If you understand the points in 1), then you'll realize that the reason for having the 10000+ threads in flight: to hide memory latency. When you flush all that (like what OGL and DX potentially do), you incur all of the memory latency again. The point of Mantle is to not have to flush nearly as often.
4) Yes, the CPU-memory gap is a valid problem. But in the game development world where most of the compute-intensive stuff already know ahead of time what portions of data the computations need to access, most of these problems are mitigated (e.g. latency hiding, prefetching, etc...). In other words, you're raising a problem that isn't even close to the biggest set of problems in the game development world. It's not like game developers are writing a huge database program that has no idea which part of main memory they're going to touch on the next request.
You are correct, and this is where a big chunk of work in graphics engines go into. But a lot of times, the batching just doesn't work well. For example, you can't batch well when you have custom materials written by artists (it used to work when there were only about 20 different materials -- you just set the textures and a few uniforms, and off you go). So having the flexibility of draw calls is definitely valuable here. Also, draw calls aren't the only performance bottlenecks imposed by DX/OGL.
I'm sorry, but you're the one who's clearly full of shit. GP clearly has some experience doing console/PC game programming. You clearly don't. Have you tried making 10k draw calls per frame on DX/OGL? Do the same in LibGSM, and you'll know the day-and-night difference (read: you can make hundreds of thousands of draw calls on the PS3, which is 6+ years old, without breaking a sweat). The point you don't understand is, the overhead isn't on the GPU -- it's on the CPU. Think Amdhal's law; the single threaded bottleneck is on CPU, and the speedup in PC graphics you see is from the parallel speedup in the GPU. The point of Mantle is to get rid of the CPU overhead, not somehow magically make the GPU faster.
3. Sorry, you're completely wrong. Try making 10k calls per frame (30fps) on a modern high-end PC (use the latest Haswell i7 + 7970/780 if you want), and your game will still slow down quite a bit due to single-threaded CPU overhead. On the PS3 (which is over 6 years old now?), you can make hundreds of thousands of draw calls per frame on libGSM and get away with it just fine. Why? Simple: every time you make a draw call on OpenGL/DX, you have to validate/potentially flush/sync all sorts of states. On libGSM (and to some extent, the special DX on the X360), it's a simple "write 4-byte value to command buffer, which is in CPU land". Yeah, semi-immediate/deferred mode 4TL.
If they can make me immortal by watching ads, I'd gladly watch ads.
And that's exactly the problem: good enough for you isn't good enough for everyone. So just like the other posters said, you lost all credibility when you think you're the only use case on this planet and went on to trash other users for something you admittedly knew nothing about.
While I'd like a citation as well, you make it seem like "no way in hell 1M people died". Ok, well, you tell me how many died (in the various forms of "died", e.g. list by radiation poisoning, cancer, etc...)? And can you back that up with citations as well? And while you're at it, please provide modest proofs of credibility of those who you cited.
Except you're the one being a total ass, as you were the one who asked gweihir for the proof (and by context, that would be Chernobyl; TMI, on the other hand, I'm sure you can Google). So now you do a 180 and say this is about Fukushima? Then why did you ask for proof in the first place? Oh wait, you're an ass, I forgot.
Exactly -- I am who I was. I would be fine waking up with my cognitive state slightly distorted...at least I'd still be "more or less" myself and feel that my existence continues.
And when we finally achieve immortality, we'd only have to suffer through the ones who wishes not to live for ever.
Why do people have absolutely no imagination? If the future humanity can revive you through freezing you up like a frozen chicken, why would you assume that, by then, our future humanity haven't developed the technology to reconstruct your body to its 20 year old state? Hell, I'd wager that we'd develop the technology to keep us immortal through stem cells before we figure out how to thaw a frozen mouse and keep its cognitive abilities.
If anything, you are enforcing better modularization/encapsulation/organization. You're forced to not use anonymous namespaces, because then all the symbols clash. You HAVE to put everything into their own namespace.
.cpp and .h file opening up all their includes, you get just four .cpp opening up includes (can't avoid the .h includes). So instead of taking 2 seconds per file to compile 2000 files (plus a long link time), you take like 5 seconds per file to compile 4 files (plus a short link time). Any way you slice it, it was a boon to productivity for our team.
And I'm not sure how you think this is a losing strategy. If you've worked on large projects, link time becomes a PITA partly because of the number of files involved. There are tools out there that took 30 minutes to link when there are a ton compiled files. When you drop that number down to 4, it links in mere minute or two. Also, compile time takes a dive (in a good way) -- instead of each
When I drive on the freeway and get stuck behind a slow moving car on the left lane, it's 50/50 that it's someone on the phone. Now, when I do a random sampling of people driving, I notice less than 20% on the phone. I think that says something?
Yeah, it's possible (I worked on AAA games with a few million lines of code). In VS, take your whole code base, flatten to one project, make 4 (or any small number) new .cpp files and alternately include all other SOURCE .cpp files into these (and disable all compiling on all other files in this configuration). Each file will take about 30 seconds to compile...but you have 4+ cores, so it takes 30 seconds to compile all 4 files. Linking is much faster too. This was done because linking on the PS3 used to take 20 minutes (this was within the first year of the console's release).