I don't know. I just really can't see 160SPs matching current-gen, especially if some form of GPGPU is being used to make up for the pathetic CPU.
The same guy who gave us the CPU specs tell us that it is on par with xcpu in performance, probably able to cope with more flexible code too. And you even get a bit more of performance from what is offload to the DSP.
Still 160 SPUs would be about 170 gflops, that mean the Wii u best case scenario would be as powerfull as 60-70% Xenos, even if the real world performance of xenos is low, and ugpu is 100%, it is very hard to believe that any dev could make up for 30-40% of the others, that said may of the ports are even doing native 720p.
By "custom" I was thinking along the lines of "between 4xxx and 5xxx" with possibly some kind of GPU compute features added (like Xenos' memexport). But firmly rooted in the PC VLIW5 line of technology.
There is a lot of custom work, not only we cant find anything equal in other gpus (close but not equal), looking at this photo even the
best guess keeps 10+ blocks that no one knows what are doing, the neogaf thread that I put above have a lot of guess.
Anyway one of the advantages is that it looks like it can cope with more kinds of code allowing for more diverge engines.
Anyway some coments of Wii U devs
On Wii U you can take many different approaches to tackle a problem.
We didn’t have such problems. The CPU and GPU are a good match. As said before, today’s hardware has bottlenecks with memory throughput when you don’t care about your coding style and data layout. This is true for any hardware and can’t be only cured by throwing more megahertz and cores on it. Fortunately Nintendo made very wise choices for cache layout, ram latency and ram size to work against these pitfalls. Also Nintendo took care that other components like the Wii U GamePad screen streaming, or the built-in camera don’t put a burden on the CPU or GPU.
DSPs in current hardware are mainly used to take tasks away from the CPU. As we take audio in our games very seriously we were happy to see that the DSP can handle all the tasks we throw at it. We use it for 3D audio, lowpass filtering and many other things.
We can’t be too specific on the Wii U hardware but you can’t compare anyway an OpenGl/DirectX driver version to the actual Wii U GPU. I can only assure that the Wii U GPU feature set allows to do many cool things that are not possible on any current console. The Wii U has enough of potential for the next years to create jaw-dropping visuals. Also remember the immense improvement we saw on the PS3 and XBOX360 over the years. I’m really excited to see what developers will show on the Wii U in the years to come.
http://www.notenoughshaders.com/2012/11/03/shinen-mega-interview-harnessing-the-wii-u-power/
The Wii U GPU is several generations ahead of the current gen. It allows many things that were not possible on consoles before. If you develop for Wii U you have to take advantage of these possibilities, otherwise your performance is of course limited. Also your engine layout needs to be different. You need to take advantage of the large shared memory of the Wii U, the huge and very fast EDRAM section and the big CPU caches in the cores. Especially the workings of the CPU caches are very important to master. Otherwise you can lose a magnitude of power for cache relevant parts of your code. In the end the Wii U specs fit perfectly together and make a very efficient console when used right.
http://hdwarriors.com/wii-u-specs-f...gpu-several-generations-ahead-of-current-gen/
‘We only know that you need to treat the Wii U differently than other consoles, because of a very different and in our view more accessible architecture. There is a lot of power to unleash in the Wii U. Enough power for many years to come, at least from our point of view.
http://hdwarriors.com/wii-u-has-a-lot-of-power-to-unleash-power-for-years-to-come/
Tessellation itself is not resource heavy on recent GPUs but it depends on actual usage. Although even previous consoles had these features you saw it only very rarely used. People often think of it as an easy way to get free ‘level of detail’. That doesn’t work. It’s because of certain visual problems associated with adaptive tessellation
http://hdwarriors.com/shinen-on-the-practical-use-of-adaptive-tessellation-upcoming-games/
Given Monolith X I am ready to believe him, although I would still love to know more about it
I doubt that unless some dev leak some official documentation we will never know.
Whatever it does it is better, lower power and very very differently.
