The issue was feature support. And it is supported.
MS didn't. I don't get what you want to say here.
What do you want? Proof, that there is code out there, where the added features of SM5 are not needed? That's basically a given fact.
This makes sense. You want a quality experience. Trying to get 1080p on a launch title means running the risk of inconsistent framerates. 720p will preserve the Nintendo consistent framerate standard for the first titles while devs learn how to best develop for the machine. Remember, Nintendo's 1st party developers have zero experience with a modern architecture. Their programming experience and knowledge of architecture is a dozen years out of date.
I'm not tight on all the rumours, but I think we have eDRAM on both processors. There's eDRAM on the GPU as you'd expect. We're also told by IBM that there's eDRAM on the CPU. This could just be a smaller amount for cache, rather than be related to the GPU. eDRAM shared between GPU and CPU doesn't make sense to me, and would be an added cost for no benefit.
Compute shaders are very useful for graphics rendering as well. If you can perform some graphics rendering steps more efficiently using compute shaders, you are naturally going to do it. In addition to speeding up existing processing steps, compute shaders allow completely new graphics algorithms to be implemented. Current pixel shader based rendering pipelines rely heavily on brute force rendering (huge regular sampling grid, etc). Compute shaders allow more clever algorithms to be implemented instead. In many cases you also want to run some algorithm steps on GPU because GPU->CPU->GPU latency roundtrip is too long.
I do not agree with this. Since PS3.0 you have been able to do basically anything you wanted in pixel shader. PS4.0 and 5.0 didn't bring any features that allowed anything radically new, except for maybe integer support. And you can emulate 24 bit integers with 32 bit floating point values very well (I have been doing for example image compression / bit packing in pixel shaders using floating points as integers on consoles, and the performance is good).
Modern GPUs have significant advantage in both raw flops and memory BW compared to modern CPUs. For example top of the line Ivy Bridge peak = 8*2*4*3.5GHz = 224 GFLOP/s. Top of the line Radeon 7970 (GHz edition) peak = 4300 GFLOP/s. That's near 20x difference.
No it wasn't. Go back and look at where I started this. I said it was "weird/wasteful". Wasteful meaning inefficient to implement on 10.1-level hardware.
And as long as you don't hit some limit of the shader model, it is very well possible to run the shaders efficiently. Btw., that is a very general statement. It applies to all shader types. Or are you also claiming that with pixel shader model 4 you can't run them efficiently so it does not make sense to use them and one absolutely needs SM5 to run pixel shaders well?
What do you want? Proof, that there is code out there, where the added features of SM5 are not needed? That's basically a given fact.
Remember, that people already did compute wrapped in pixel shaders before the advent of compute shaders?
I don't understand your point.
Nintendo's developers have been working on fixed-pipeline Gamecube hardware for over a decade. They don't do multiplatform so have no experience with modern hardware. Ergo it's going to be harder for them to eek out performance from day one, just as it was devs experienced using EE+GS switching to Cell+RSX. That Nintendo's RnD can build a short tech demo utilising modern techniques on modern hardware doesn't change the situation with their many studios. There's no reason to expect Nintendo's developers to transition to new hardware better than any others, and no reason to expect them to get more performance from their hardware from day one than any other developers. That flies in the face of reason.I don't understand your point.
I don't understand your point.
If you're making a game, you're working on the hardware targets. Their coders would be working their days writing GC and Wii code while those were the platforms being targeted rather than spending time writing GPU code on PC. A shift to a new hardware mean those coders move from one architecture to another with zero experience on the new hardware. They'll have various RnD, but they are no different to every other developer AFAIK. Which means new hardware means a whole load of new lessons, and the more different the hardware, the longer it's gonna take to make the most of the new hardware - affected also by the ease of the hardware and development tools. Efficient hardware usage can't be learnt with two weeks training. Training teaches how to get the hardware to render some graphics. Experience (and shared experience) teaches how to understand the hardware at a lower level and make the most of it.
But it was still well below what the machine was capable of! Launch titles on any console aren't a patch on what it can do further down the line. I'm not in any way belittling Nintendo's developers here - all devs are in the same boat. MS's first party, and Epic, went from shader-based graphics to shader-based graphics, so for them the transition was easier. To next-gen, they'll hit the floor running. Well, jogging. Sony's devs went from simple PlayStation code to the impenetrable wall of PS2 which took them forever to work out (isn't the reference anecdote several weeks just to get a triangle to draw for the first time?), to the complexities of Cell and the unknowns of GPU shaders. Nintendo's devs had the luxury of the same hardware from GC to Wii, meaning no learning to do. But that also means no experience with modern systems, and they'll be hitting a major learning wall. Modern hardware is easy to use. Clever developers with a copy of GPU Gems can produce a decent looking demo in a short time. But making the most of the hardware, doing things efficiently, is going to take a lot of experience. Thus us makes sense not to try to produce a fifth-year quality game, but aim for a launch-title quality game for launch, which means setting more realistic goals.
