""

Er, the amount of "Gigaflops" has absolutely ZERO correllation with Tessellation performance, Tessellation does not and will not rely on the shader hardware to actually be performed.

GPU's have fixed function hardware that is dedicated to doing tasks such as Tessellation.
However, the thing with the WiiU is that it's using AMD's 6th generation Tessellator, which is woefull in it's geometry performance.

""

seriously?

you realize that tesselation must be used in conjuction with dispalcement right?

here

https://developer.nvidia.com/content/vertex-texture-fetch

"

Vertex Texture Fetch

"

you relize that vertex fetches are related to power right?

here

http://moodle.technion.ac.il/pluginfile.php/126883/mod_resource/content/0/lessons/Lecture7.x4.pdf

"

"

never heard of tesselation stages right?

vertex and pixel shaders, and how does amd handle the vertex and pixel shaders?

tthough the SIMD CORES, and simd cores have stream processors and at certain clock speed that gives us?

gigaflops

bandwidth is also related to shader power, if there is not enough bandwidth you cant handle the shader power, you think nintendo would put so much bandwidth for 176gigaflops?

no

here

http://www.openglsuperbible.com/2014/01/24/memory-bandwidth-and-vertices/
"

Memory Bandwidth and Vertices

Memory bandwidth is a precious commodity. As far as graphics
cards are concerned, this is the rate at which the GPU can transfer data
to or from memory and is measured in bytes (or more likely, gigabytes)
per second. The typical bandwidth of modern graphics hardware can range
anywhere from 20 GB/s for integrated GPUs to over 300 GB/s for
enthusiast products. However, with add-in boards, data must cross the
PCI-Express bus (the connector that the board plugs into), and its
bandwidth is typically around 6 GB/s. Memory bandwidth affects fill rate
and texture rate, and these are often quoted as performance figures
when rating GPUs. One thing that is regularly overlooked, though, is the
bandwidth consumed by vertex data.

Vertex Rates

Most modern GPUs can process at least one vertex per clock cycle.
GPUs are shipping from multiple vendors that can process two, three,
four and even five vertices on each and every clock cycle. The core
clock frequency of these high end GPUs hover at around the 1 GHz mark,
which means that some of these beasts can process three or four billion
vertices every second. Just to put that in perspective, if you had a
single point represented by one vertex for every pixel on a 1080p
display, you’d be able to fill it at almost 2000 frames per second. As
vertex rates start getting this high, we need to consider the amount of
memory bandwidth required to fill the inputs to the vertex shader.

Let’s assume a simple indexed draw (the kind produced by glDrawElements)
with only a 3-element floating-point position vector per-vertex. With
32-bit indices, that’s 4 bytes for each index and 12 bytes for each
position vector (3 elements of 4 bytes each), making 16 bytes per
vertex. Assuming an entry-level GPU with a vertex rate of one vertex
per-clock and a core clock of 800 MHz, the amount of memory bandwidth
required works out to 12 GB/s (16 * 800 * 10^6). That’s twice the
available PCI-Express bandwidth, almost half of a typical CPU’s system
memory bandwidth, and likely a measurable percentage of our hypothetical
entry-level GPU’s memory bandwidth. Strategies such as vertex reuse can
reduce the burden somewhat, but it remains considerable.

High Memory Bandwidth

Now, let’s scale this up to something a little more substantial. Our
new hypothetical GPU runs at 1 GHz and processes four vertices per
clock cycle. Again, we’re using a 32-bit index, and three 32-bit
components for our position vector. However, now we add a normal vector
(another 3 floating-point values, or 12 bytes per vertex), a tangent
vector (3 floats again), and a single texture coordinate (2 floats). In
total, we have 48 bytes per vertex (4 + 12 + 12 + 12 + 8), and 4 billion
vertices per-second (4 vertices per-clock at 1 GHz). That’s 128 GB/s of
vertex data. That’s 20 times the PCI-express bandwidth, several times
the typical CPU’s system memory bandwidth (the kind of rate you’d get
from memcpy). Such a GPU might have a bandwidth of around 320 ¹ GB/s. That kind of vertex rate would consume more than 40% of the GPU’s total memory bandwidth.

Clearly, if we blast the graphics pipeline with enough raw vertex
data, we’re going to be sacrificing a substantial proportion of our
memory bandwidth to vertex data. So, what should we do about this?

Optimization

Well, first, we should evaluate whether such a ridiculous amount of
vertex data is really necessary for our application. Again, if each
vertex produces a single pixel point, 4 vertices per clock at 1 GHz is
enough to fill a 1080p screen at 2000 frames per second. Even at 4K
(3840 * 2160), that’s still enough single points to produce 480 frames
per second. You don’t need that. Really, you don’t. However, if you
decide that yes, actually, you do, then there are a few tricks you can
use to mitigate this.

• Use indexed triangles (either GL_TRIANGLE_STRIP or GL_TRIANGLES).
  If you do use strips, keep them as long as possible and try to avoid
  using restart indices, as this can hurts parallelization.
• If you’re using independent triangles (not strips), try to order
  your vertices such that the same vertex is referenced several times in
  short succession if it is shared by more than one triangle. There are
  tools that will re-order vertices in your mesh to make better use of GPU
  caches.
• Pick vertex data formats that make sense for you. Full 32-bit
  floating point is often overkill. 16-bit unsigned normalized texture
  coordinates will likely work great assuming all of your texture
  coordinates are between 0.0 and 1.0, for example. Packed data formats
  also work really well. You might choose GL_INT_2_10_10_10_REV for normal and tangent vectors, for example.
• If your renderer has a depth only pass, disable any vertex attributes that don’t contribute to the vertices’ position.
• Use features such as tessellation to amplify geometry, or techniques
  such as parallax occlusion mapping to give the appearance of higher
  geometric detail.

In the limit, you can forgo fixed-function vertex attributes, using
only position, for example. Then, if you can determine that for a
particular vertex you only need a subset of the vertex attributes, fetch
them explicitly from shader storage buffers. In particular, if you are
using tessellation or geometry shaders, you have access to an entire
primitive in one shader stage. There, you can perform simple culling
(project the bounding box of the primitive into screen space) using only
the position of each vertex and then only fetch the rest of the vertex
data for vertices that are part of a primitive that will contribute to
the final scene.

Summary

Don’t underestimate the amount of pressure that vertex data can put
on the memory subsystem of your GPU. Fat vertex attributes coupled with
high geometric density can quickly eat up a double-digit percentage of
your graphics card’s memory bandwidth. Dynamic vertex data that is
modified regularly by the CPU can burn through available PCI bandwidth.
Optimizing for vertex caches can be a big win with highly detailed
geometry. While we often worry about shader complexity, fill rates,
texture sizes and bandwidth, we often overlook the cost of vertex
processing — bandwidth is not free.

"

or maybe you prefer this explanation

http://www.ign.com/articles/2005/05/20/e3-2005-microsofts-xbox-360-vs-sonys-playstation-3?page=3

"

Bandwidth
The PS3 has 22.4 GB/s of GDDR3 bandwidth and 25.6 GB/s of RDRAM bandwidth for a total system bandwidth of 48 GB/s.

The Xbox 360 has 22.4 GB/s of GDDR3 bandwidth and a 256 GB/s of EDRAM bandwidth for a total of 278.4 GB/s total system bandwidth.

Why does the Xbox 360 have such an extreme amount of bandwidth?

Even the simplest calculations show that a large amount of bandwidth is consumed by the frame buffer. For example, with simple color rendering and Z testing at 550 MHz the frame buffer alone requires 52.8 GB/s at 8 pixels per clock. The PS3's memory bandwidth is insufficient to maintain its GPU's peak rendering speed, even without texture and vertex fetches.

The PS3 uses Z and color compression to try to compensate for the lack of memory bandwidth. The problem with Z and color compression is that the compression breaks down quickly when rendering complex next-generation 3D scenes.

"

you see?

bandwidth is important also fro cmpute power, why would nintnedo put so much bandwidth if the system wouldnt require it?

why ports run in wiiu if its less powerful and even accounting the more efficient architecture you still have the issue that is a port not a ground up game, the port is lazy, developers not ued to the new hardware and using a engine that wasnt optimized for wiiu just made compatible. you can clearly see how much a port hurts performance in bayoneta of ps3 and assesins creed 4 for ps4, wii u i no different

developers already mentioend that wii u is about 50% ore powerful than 360 and ps3 and thats was based on an early dev kit cause the final one came out in 2012 and the article was made at the middle of 2011

crytek already said that wii u power is on par with the 360 and ps3

shinen mentioend that wii u is powerful machine more than 360 and ps3

and so goes

the moment bayo for ps3 had half the framerate than 360 because was a port and the fact that develoeprs struggled to achieve 1080p 30fps in assesins creed 4 for ps4 and previously had it at 900p also tells you hat no matter how modern is the new harwdare and more powerful, alway making a port from an older machne will limit your new system, and ps4 is more modern  and easy due to the x86 and having no edram for developers to have hard times in development and still runned at 900p 30fps eventhough ps4 is 7.5x mor powerful than xbox 360 and for 108060fps you would require less than half that power to achieve 1080p 60fps and even with the patc is running at 1080p 30fps

if the performance of the ps4 was hurt due to those issues with the port, then why would wii u would be so diferent?

sorry dude, you already lost the argument, nintndo makes balanced systms, they aint gonna put bandwidth going to waste

563.2GB/s or a terabyte of bandwidth isnt impossible, already gamecube had 512bit of bus width with 1MB of edram, so why wii u being more than a decade more modern could not pack 1024bits(563.2GB/s for the 8 macros) or 2048bits(more than a terabyte for 8 macros) in a block of 4MB?

do the math

Not surprisingly... All of those "slides" and everything you posted has zero to do with the Tessellation block on a GPU.

Vertex Texture Fetch is also an entirely seperate issue, the implementation you outlined from nVidia has long been superseeded. - nVidia were talking about the Geforce 6 GPU's back in 2004, over a decade ago.
In-case you didn't know, nVidia didn't have a hardware Tessellation/Geometry block untill the Geforce 400 series, 5+ years after that document.
Vertex Shaders were also dropped and implemented in a unified shader design starting with the Geforce 8000 series and massive architectural changes were made between those two (Geforce 8000 And Geforce 6) architectures, comparing them is laughable.

This is how a Cayman GPU would look like:


As you can see the Tessellation units are an individual fixed function part of the GPU.


How you assume it has any relevence, beats me.

As for the GFLOP issue.
A prime example is... The Radeon 5870 vs Radeon 6970.
The Radeon 5870 has MORE "Gigaflops" than the Radeon 6970, but guess what? It's also slower than the Radeon 6970.

Or hows about the Radeon 2900XT and Radeon Radeon 3850? The 2900XT has more Gigaflops but it's slower than the Radeon 3850.
Again, Gigaflops REALLY is not that important, especially so if your design is bottlenecked by another unit. (And every GPU design always has a bottleneck somewhere but you need to make concessions in order to prevent exploding the transister counts.)


Orange = Radeon 6970.
Blue = Radeon 5870.
http://www.anandtech.com/bench/GPU14/815
http://en.wikipedia.org/wiki/List_of_AMD_graphics_processing_units

megafenix said:   or maybe you prefer this explanation http://www.ign.com/articles/2005/05/20/e3-2005-microsofts-xbox-360-vs-sonys-playstation-3?page=3 " Bandwidth The PS3 has 22.4 GB/s of GDDR3 bandwidth and 25.6 GB/s of RDRAM bandwidth for a total system bandwidth of 48 GB/s. The Xbox 360 has 22.4 GB/s of GDDR3 bandwidth and a 256 GB/s of EDRAM bandwidth for a total of 278.4 GB/s total system bandwidth. Why does the Xbox 360 have such an extreme amount of bandwidth? Even the simplest calculations show that a large amount of bandwidth is consumed by the frame buffer. For example, with simple color rendering and Z testing at 550 MHz the frame buffer alone requires 52.8 GB/s at 8 pixels per clock. The PS3's memory bandwidth is insufficient to maintain its GPU's peak rendering speed, even without texture and vertex fetches. The PS3 uses Z and color compression to try to compensate for the lack of memory bandwidth. The problem with Z and color compression is that the compression breaks down quickly when rendering complex next-generation 3D scenes. " you see? bandwidth is important also fro cmpute power, why would nintnedo put so much bandwidth if the system wouldnt require it? why ports run in wiiu if its less powerful and even accounting the more efficient architecture you still have the issue that is a port not a ground up game, the port is lazy, developers not ued to the new hardware and using a engine that wasnt optimized for wiiu just made compatible. you can clearly see how much a port hurts performance in bayoneta of ps3 and assesins creed 4 for ps4, wii u i no different   developers already mentioend that wii u is about 50% ore powerful than 360 and ps3 and thats was based on an early dev kit cause the final one came out in 2012 and the article was made at the middle of 2011 crytek already said that wii u power is on par with the 360 and ps3 shinen mentioend that wii u is powerful machine more than 360 and ps3 and so goes the moment bayo for ps3 had half the framerate than 360 because was a port and the fact that develoeprs struggled to achieve 1080p 30fps in assesins creed 4 for ps4 and previously had it at 900p also tells you hat no matter how modern is the new harwdare and more powerful, alway making a port from an older machne will limit your new system, and ps4 is more modern  and easy due to the x86 and having no edram for developers to have hard times in development and still runned at 900p 30fps eventhough ps4 is 7.5x mor powerful than xbox 360 and for 108060fps you would require less than half that power to achieve 1080p 60fps and even with the patc is running at 1080p 30fps if the performance of the ps4 was hurt due to those issues with the port, then why would wii u would be so diferent?   sorry dude, you already lost the argument, nintndo makes balanced systms, they aint gonna put bandwidth going to waste 563.2GB/s or a terabyte of bandwidth isnt impossible, already gamecube had 512bit of bus width with 1MB of edram, so why wii u being more than a decade more modern could not pack 1024bits(563.2GB/s for the 8 macros) or 2048bits(more than a terabyte for 8 macros) in a block of 4MB? do the math

Using the PS3 and Xbox 360 is ironic.
The Playstation 3 has less theoretical bandwidth, yet the better "graphical" games are found on that platform (Last of Us, Uncharted etc') than the Xbox 360, thus you proved my point in the process.

Now, you are misreading what I have stated.
I am not denying the WiiU has significant amounts of eDRAM bandwidth and low latency, but I am saying it's usefullness is limited compared to other approaches. (I also do firmly beleive the WiiU is 50% or more, faster than the HD twins, but it's still clearly not on next-gen levels.)
Bandwidth isn't some magical number that's going to make games better on one platform than another, it's usefullness can be limiting if your compute hardware is stuck years in the past.

To use your example of the Xbox 360's multiple times more bandwidth compared to the Playstation 3 is the perfect example of why eDRAM bandwidth doesn't always mean better graphics.

Pemalite said: megafenix said:   "" Er, the amount of "Gigaflops" has absolutely ZERO correllation with Tessellation performance, Tessellation does not and will not rely on the shader hardware to actually be performed. GPU's have fixed function hardware that is dedicated to doing tasks such as Tessellation. However, the thing with the WiiU is that it's using AMD's 6th generation Tessellator, which is woefull in it's geometry performance. ""   seriously? you realize that tesselation must be used in conjuction with dispalcement right? here https://developer.nvidia.com/content/vertex-texture-fetch "   Vertex Texture Fetch DOWNLOAD FILE DESCRIPTION SIZE Vertex_Textures.pdf With Shader Model 3.0, GeForce 6 and GeForce 7 Series GPUs have taken a huge step towards providing common functionality for both vertex and pixel shaders. This paper focuses specifically on one Shader Model 3.0 feature: Vertex Texture Fetch (PDF). It allows vertex shaders to read data from textures, just like pixel shaders can. This additional feature is useful for a number of effects, including displacement mapping, fluid and water simulation, explosions, and more. The image below shows the visual impact of adding vertex textures, comparing an ocean without (left) and with (right) vertex textures. "   you relize that vertex fetches are related to power right? here http://moodle.technion.ac.il/pluginfile.php/126883/mod_resource/content/0/lessons/Lecture7.x4.pdf " " never heard of tesselation stages right?   vertex and pixel shaders, and how does amd handle the vertex and pixel shaders? tthough the SIMD CORES, and simd cores have stream processors and at certain clock speed that gives us? gigaflops Not surprisingly... All of those "slides" and everything you posted has zero to do with the Tessellation block on a GPU. Vertex Texture Fetch is also an entirely seperate issue, the implementation you outlined from nVidia has long been superseeded. - nVidia were talking about the Geforce 6 GPU's back in 2004, over a decade ago. In-case you didn't know, nVidia didn't have a hardware Tessellation/Geometry block untill the Geforce 400 series, 5+ years after that document. Vertex Shaders were also dropped and implemented in a unified shader design starting with the Geforce 8000 series and massive architectural changes were made between those two (Geforce 8000 And Geforce 6) architectures, comparing them is laughable. This is how a Cayman GPU would look like: As you can see the Tessellation units are an individual fixed function part of the GPU. How you assume it has any relevence, beats me. As for the GFLOP issue. A prime example is... The Radeon 5870 vs Radeon 6970. The Radeon 5870 has MORE "Gigaflops" than the Radeon 6970, but guess what? It's also slower than the Radeon 6970. Or hows about the Radeon 2900XT and Radeon Radeon 3850? The 2900XT has more Gigaflops but it's slower than the Radeon 3850. Again, Gigaflops REALLY is not that important, especially so if your design is bottlenecked by another unit. (And every GPU design always has a bottleneck somewhere but you need to make concessions in order to prevent exploding the transister counts.) Orange = Radeon 6970. Blue = Radeon 5870. http://www.anandtech.com/bench/GPU14/815 http://en.wikipedia.org/wiki/List_of_AMD_graphics_processing_units megafenix said:   or maybe you prefer this explanation http://www.ign.com/articles/2005/05/20/e3-2005-microsofts-xbox-360-vs-sonys-playstation-3?page=3 " Bandwidth The PS3 has 22.4 GB/s of GDDR3 bandwidth and 25.6 GB/s of RDRAM bandwidth for a total system bandwidth of 48 GB/s. The Xbox 360 has 22.4 GB/s of GDDR3 bandwidth and a 256 GB/s of EDRAM bandwidth for a total of 278.4 GB/s total system bandwidth. Why does the Xbox 360 have such an extreme amount of bandwidth? Even the simplest calculations show that a large amount of bandwidth is consumed by the frame buffer. For example, with simple color rendering and Z testing at 550 MHz the frame buffer alone requires 52.8 GB/s at 8 pixels per clock. The PS3's memory bandwidth is insufficient to maintain its GPU's peak rendering speed, even without texture and vertex fetches. The PS3 uses Z and color compression to try to compensate for the lack of memory bandwidth. The problem with Z and color compression is that the compression breaks down quickly when rendering complex next-generation 3D scenes. " you see? bandwidth is important also fro cmpute power, why would nintnedo put so much bandwidth if the system wouldnt require it? why ports run in wiiu if its less powerful and even accounting the more efficient architecture you still have the issue that is a port not a ground up game, the port is lazy, developers not ued to the new hardware and using a engine that wasnt optimized for wiiu just made compatible. you can clearly see how much a port hurts performance in bayoneta of ps3 and assesins creed 4 for ps4, wii u i no different   developers already mentioend that wii u is about 50% ore powerful than 360 and ps3 and thats was based on an early dev kit cause the final one came out in 2012 and the article was made at the middle of 2011 crytek already said that wii u power is on par with the 360 and ps3 shinen mentioend that wii u is powerful machine more than 360 and ps3 and so goes the moment bayo for ps3 had half the framerate than 360 because was a port and the fact that develoeprs struggled to achieve 1080p 30fps in assesins creed 4 for ps4 and previously had it at 900p also tells you hat no matter how modern is the new harwdare and more powerful, alway making a port from an older machne will limit your new system, and ps4 is more modern  and easy due to the x86 and having no edram for developers to have hard times in development and still runned at 900p 30fps eventhough ps4 is 7.5x mor powerful than xbox 360 and for 108060fps you would require less than half that power to achieve 1080p 60fps and even with the patc is running at 1080p 30fps if the performance of the ps4 was hurt due to those issues with the port, then why would wii u would be so diferent?   sorry dude, you already lost the argument, nintndo makes balanced systms, they aint gonna put bandwidth going to waste 563.2GB/s or a terabyte of bandwidth isnt impossible, already gamecube had 512bit of bus width with 1MB of edram, so why wii u being more than a decade more modern could not pack 1024bits(563.2GB/s for the 8 macros) or 2048bits(more than a terabyte for 8 macros) in a block of 4MB? do the math     Using the PS3 and Xbox 360 is ironic. The Playstation 3 has less theoretical bandwidth, yet the better "graphical" games are found on that platform (Last of Us, Uncharted etc') than the Xbox 360, thus you proved my point in the process. Now, you are misreading what I have stated. I am not denying the WiiU has significant amounts of eDRAM bandwidth and low latency, but I am saying it's usefullness is limited compared to other approaches. (I also do firmly beleive the WiiU is 50% or more, faster than the HD twins, but it's still clearly not on next-gen levels.) Bandwidth isn't some magical number that's going to make games better on one platform than another, it's usefullness can be limiting if your compute hardware is stuck years in the past. To use your example of the Xbox 360's multiple times more bandwidth compared to the Playstation 3 is the perfect example of why eDRAM bandwidth doesn't always mean better graphics.

not saying that gigaflops s everything, just quoting your stating that are not related to tesselation, but you can clearly see that shading power is related in the tesselation stages, and as we all know wii u packs lots of bandwidth with edram so obviously sicne only 16MB are rquired for the 1080p framebuffer, whats the rest of the edram bandwidth going to be used for?

of course is for vertex and texture fetches and other things,

and its not just that

already developers mentioned 50% more power than 360 and ps3 based on an early dev kit of 2011 and the final one came at 2012

already shinen mentioned that wiiu edram packs high bandwidth and only equires 16MB for 1080p of that when 360 requires the whole 10mb OF EDRAM FOR 720p

renesas already said that wi u edram uses the best technologies from them

gamecube already had 512bits wide bus with 1MB of edram so why a more modern edram made at 40nm and not 180nm and obviously cheaper would not be able to hold 1024bits or 2048bits per macro of 4MB?

as i already demostrated, ports hurt the performance of he system where you are porting cause the game as made in mind with the specifications of other system, plus developers are no fmiliar with the new system and have at their disposal engines that are not optimized for it. porting from 360 to wii u you are having al those problems besides the fact that 360 uses main ram for storing vertex texture fecth data(through the memory export) and not edram, so of course wii u port will use the main ram for that isntead of usng the edram, thats a big performance hit, so obviously al those constranits wont allow a port from 360 to wii u work at all if wii u had less pwer, wii u has at least 400 stream cores just like the redwood xt

It's because it's not.

The game/software/app sends the necessary information to the API, the API then sends it to the drivers, the drivers then send it to the command processor, the command processor will then send geometric data that is required to be tessellated to the Tessellator(s).
Then once that is completed and depending on the data set, it is sent to the vertex or geometry assemblers which assembles the data sets to be used in a 3D scene, once that's done it's sent to the dispatch/schedulars.
All the mathematical calculations and set-ups required to Tessellate something isn't done in the shaders and depending on the type of data, doesn't even touch the vertex's.

Thus by extension, you could have a 10gflop GPU and have a Tessellator far more powerfull than you can get out of four Radeon 290X's.

As for eDRAM it's always been used for more than just the framebuffer. - Developers are fit to use it however they wish, whatever you *think* it's strictly going to be used for is thus by default, incorrect as that's not going to be the standard that *every* developer will utilise it for.
Most however will probably use it for some framebuffer tasks and render targets as it makes the most logical sense.

If you cared to read my posts, I never even attempted to dispute that and the latter half I didn't even mention it.

If you cared to read my posts, I actually agree with you on the rough performance estimations of the WiiU vs last generation consoles.
Even if it was at the same amount of "gflops" as the Xbox 360, it's still a massively more efficient design, it can simply do more work per flop.

As for memexport, that's a very very very old function, I remember using that in OpenGL on the Geforce 4. (13 GPU generations ago.)
It's still relevent today and is still used today, so the WiiU isn't unique in this regard.

As for the WiiU's GPU, nothing is concrete, except for a couple of things.
It's 40nm and has roughly 880 million transisters.
Redwood xt is a 627 million transister design.

Thus with 253 million transisters you need to spend it on: 3 PowerPC cores (With extra Cache and OoO), eDRAM, Memory Controllers, Audio and varying other controllers, which to be honest, I don't see happening.
You are probably looking at a 160-240 VLIW5 shader design. (Which also fits in with the TDP envelope.)

Basically, regardless if it has 160-400 shaders, it's strictly super low-end, VLIW5 is not as efficient as GCN, so I would personally choose a 256 shader GCN core over a 400 shader VLIW5 core, although VLIW can be more transister efficient, but it is far weaker in compute. (I.E. Physics.)

sorry dude, ps4 and xbox one are also more efficnet and more modern and despite that cant even do 1080p 60fps in their ports even with all those adventages and even surpassing the raw power required for that, so why would you expect wii u to do any better with 160 stream cores?

wii u die size also is like 96mm2 even without edram and other stuff and thats enough to hold 400 stream cores, 20 tmus and 8 rops just like the redwood xt which could be like 94mm2 with a chipworks photo instead of the 104mm2 reported by anadtech cause the wii u gpu die size was reduced from 156mm2 reported from anadtech to 146mm2 by chipworks photo

all that efficiency goes to waste on a port, already shinen explained that your engine layout has to be different for wii u or you lose a lot performance hit, emaning that your 176gigaflops also go even lower due to this

The memory export, the issue about no DSP on 360 and that uses one core dedicated for sound and wh knows if many ports from 360 to wiiu also do it this way isntead of changing the code so that the DSP does this, changes like the addition of geometry shaders also are wasted when porting simply because xbox 360 dosnt support it as its a directx10 or shader model 4 hardware addition and since you are porting from a directx9 hardwre you also likely going to waste this new feature unless you rework the source code and add these changes

All these things  point out that 176gigaflops or just 160 stream processors wouldnt be enough for a lazy port to even work on wiiu, hell even one of the secret developers admitted that despite wiiu having the capability of compute shaders with an early dev kit they didnt use the feature, that much tells you how lazy they are being so obviuosly all tht perfromance and modern architecture is going to waste when you port from an older system in must of the cases, and we expect the console to do miracles witth just 160 stream cores when not even xbox one and ps4 can do 1080p 60fps from ports of the older generation eventhough being more modern, efficient and also exceeding the raw power needed for that?, of course not. And its not just the problem that comes when porting or that developers are lazy, but also the fact that the development tools and engines were in their baby steps when the first wii u ports came out, and still the games worked fine, so summing all that up and the examples of xbox one and ps4 ports and the ps3 worst version of bayonetta due to being a port also point this out

its not only bayo 1 for ps3 being bad for being a port comapred to 360 and having half the framerate, its not just ps4 assesins creed 4 version which despite ps4 being more modern, efficent and easier to developr for cant run it at 1080p60fps and was running at just 900p30fps before the patch of 1080p30fps despite having all the adevnatge of modern hardware and being 750% more powerful than 360 in paper, we also have many other examples, ave you forgotten call of duty ghosts for xbox one? and xbox one is more modern, more effient and also 500% more powerul in paper, so why its running at just 720p?

besides, havent you heard that that rumor was already debunked by shinen?

here

The PS4 and xbone versions of older generation games are generally enhanced visually, higher frame rates, higher resolution and most reviews have stated a huge improvement although not reaching the heights of PC versions running on a capable PC.

Always factor in the external memory speed of 12.8GB/s. You still have to bring in data from main memory. This is less than the bandwidth of ps3 and 360. If the wii u is a balanced design then eDRAM speed won't need to be ridiculously fast but even if it is for most games weaknesses in other parts of the wii u design prevent it running many old generation games well.

We are a long way in now and still the wii u shows itself to be a very weak console for a modern design with frame rate issues and missing graphic detail. This high bandwidth eDRAM has been used from day one and the games are weak. Terrible main memory bandwidth, weak cpu and a modern low performance gpu probably of 176gflops approx is frankly exactly the spec of the console you expect when you actually look at game performance.

Still capable of punching above 360/PS3 when it comes to games that have low cpu requirements though but only really current gen in name only and not close to the performance of xbone or ps4.

no it hasnt, why do you think developers like shinen state that in order to make a good wii u looking game you have to take profit of the edram and the huge cache on the cpu?

shouldnt the cache help on the framerate?, cause 360 has only 1MB and wii u has 3, so even if its slower, if the develoeprs take profit of the extra 2MB of cache there should be no framerate issues, plus one of the secret develpers at eurogamer admitted that they were being lazy, like saying that compute shaders were there but they didnt bother using them, sum that to the fact that 360 uses one core for sound, so obviously the port on wii u will do instead of using the DPS if the developers dont put effort into changing the code, not just adapting it, your geomety shaders also go to waste cause 360 doenst support them and thus the port will not do unless the deveopers change it, but they didnt bither with the compute shaders, why would they with the geometry shaders and other new stuff for better performance?

* wii u having 400 to 500 gigaflps is approx of what the system is capable of, already games on xbox one and ps4 unerpeforming despite the brute force and the more modern architexture because of the lazy ports is proof of that

* already the die size of the gpu on wii u tells us that is possible to fit 400 stream cores, 2 tmus and 8 rops, and you could even take off 4 tmus to make it 16tmus and use the rest of the die space for your fix funcion hardware

* already some developers told us that wii u is 50% more powerful than 360 and ps3 and that was with an early dev kit

* already shinen explained us why ports suck,

* already there are articles that say that bandwidth its important for shaing power and you can actually confirm it by just asking yoursef why there would be local data shares wit such extreme bandwidth for the simd cores, so why would nintendo put so much bandwith fif there wouldn be any use for it by the shaders and other stuff?

* already ign artice on xbox 360 vs ps3 explained us that massive bandidth is required for framebuffer and wii u can hold double buffering of 1080p framebuffer with half the 32MB, and xbox 360 requires the whole 10MB of 256GB/s for 720p double buffering

* already the theory of the 176gigaflops by bgassin was debunked by shinen

* already chipworks reported 320 stream cores giving like 356gigaflops and with still half the gpu undetermined of what it had

*already amd explaiend that interpolators were causing the rv770 to underpeform and they remove them and instead moved the interpolation to the stream cores, so why neogaf points out interpolators there?, if i remove the interpolators and put sream cores obviously i would get like 350 or 400 stream cores, hell nintendo is about performance, why keep a 2008 technology that was making the gpu udnerperform?, and sicne wii u supports diectx11 features via thier opengl implementation, obviously the gpu is on par iwht the hd5000 or the hd6000, and none of them have interpolators

etc

Shin'en is the last example to use in any of those arguments. They've always developed exclusively for Nintendo hardware (never made a single game for any non Nintendo platforms). So taking their words as gospel is very short sighted. If they had made ports for one system to a Nintendo console, their words would have some weight, but they have never done that. So, forgive me if I don't take them as seriously as some of you do.

so its beter to listen to an unkown guy of neogaf that even said at ign that green hills and at software were not related at all?

and i can prove that

that guy is an obvious troll, 176gigaflops wont do any magic i your ports no matter how efficient the system is cause is a port not a ground up game, and also was made by developers unfamiliar with the new system using early dev tools and engines not optimized for the new hardware, so if even the new consoles that also are more modern and far surpass the power of the 360 and ps3 by 5 to 7x, then why the ports are so bad and dont hit the 1080p60fps and even one of them like call of duty ghists is just 720p?

and its not just shinen, we also have many others, like the guys of armillo, the ones who made the giana sister game, etc

if you dont trust any of them, then why trust this bgassin guy?

i only trust numbers, and numbers tell that 176gigaflops is not enough for last geenration ports to work on your system, and also issues like the fact that developers are being lazy, not used to the system and using early dev tools and engines that obviously dont max out the system point that out

numbers also tell that the die size o the wii u gpu even without edram+dps+arm core+etc is enough to hold 400 stream cores+20tmus and 8 rops, and could even pack more things if they remove unecessary parts like the crossfire controller

You keep going back to that same old trench everytime you can't come up with any valid argument.

The PS4 doesn't struggle to run those ports, unlike what you believe. Those cross-gen games run with improved visuals, higher native resolution, higher framerate, improved and/or added vfx, in many cases they include ambiant occlusion, different lighting systems, higher-res textures, improved geometry, etc...

You really don't seem to understand the words you're copy pasting.