From cinemablend: wii u edram bandwidth could be 563.2GB/s or more

#52
^^^So what are macros, and how do they relate to the bandwidth of the memory?

you may consider macros as tiny memory module chips, like those you found in ram cards, like the wii u ram example about having 4 memory ddr3 module chips each 16 bits giving a total of 64nits bus and thus 12.8GB/s acconting the dpeed of 1600mhz(already accounted the data rate of 2 bits)
lile this


its like a block having more tiny blocks

for example, gamecube edram of 1MB was 512bits cause was formed by many block(mros) of 16bits each at 165mhz, and sicne there were 32 tiy blocks or macro chips hat gives you the 10.56GB/s

gamecube
32macros*16bits*165mhz/(8bits *1000)=10.56GB/s

here
http://www.eetimes.com/document.asp?doc_id=1227977
"
Both internal memory buffers have a sustained latency of under 5
nanoseconds. The frame and z-buffer memory is capable of 9.6
Gbytes/second of bandwidth. The texture buffer boasts an even faster
bandwidth of 12.8 Gbytes/s because it's divided into 32 independent
macros, each 16 bits wide for a total I/O of 512 bits
. This gives each
macro its own address bus, so that all 32 macros can be accessed
simultaneously, said Mark-Eric Jones, vice president of marketing for
Mosys.


"

the formula gives 10,56GB/s, those 12.8GB/s may be the bandwidth you would get if the gamecube flipper wouldnt have been dowclcoked from 200MHZ to 165mhz



not sure how many macros were there i the 2MB of framebuffer, but since it has like 7.68GB/s of bandwidth, then by rule of three you would get like 372bits, so you can see that even the ld gamecube edram was like 884bits for 3MB of edram, so why a technology more than 10 years later and at 40nm instead of 180nm and having 32MB would not have 8192bits or maybe doube of that?
 

Shoulder

Your Resident Beardy Bear
#53
I suppose that makes more sense. Now, just for future reference, and sorry for being the grammar nazi here, when you explain something as complicated as this, try and proofread what you say to make it easier to understand. I still understood what you said, but just a suggestion.
 
#54
I suppose that makes more sense. Now, just for future reference, and sorry for being the grammar nazi here, when you explain something as complicated as this, try and proofread what you say to make it easier to understand. I still understood what you said, but just a suggestion.
ok, next time will try to make it more short and understandable
 

Odo

Well-Known Member
#55
My Lord!!
This discussion is fantastic, but I can't follow you.
All you're talking about means that Wii U is better than Game Cube? If so, I'm happy :D

Well, seriously, I don't know if you talked about it, because I didn't read everything here, so I'd like to ask you if the technical improvement, considering it from Wii to Wii U, is that big. I've heard that Wii to Wii U improvement is much greater than GC to Wii or even SNES to N64. How great is this?
The other question is: N64 is 64 bits so how many bits does Wii U have? :D
 

Goodtwin

Well-Known Member
#56
My Lord!!
This discussion is fantastic, but I can't follow you.
All you're talking about means that Wii U is better than Game Cube? If so, I'm happy :D

Well, seriously, I don't know if you talked about it, because I didn't read everything here, so I'd like to ask you if the technical improvement, considering it from Wii to Wii U, is that big. I've heard that Wii to Wii U improvement is much greater than GC to Wii or even SNES to N64. How great is this?
The other question is: N64 is 64 bits so how many bits does Wii U have? :D
The 64 bits on N64 was actually just the memory bus, the graphics hardware itself was still 32 bit.

Wii U is a well thought out piece of hardware from the perspective of price, size, and power consumption. Its still by far the weakest new console. With that said, I played Knack the other day, and it showed me how much more the team and budget matter these days, because Knack looks like a PS3 game at best. I played through the demo, and there is no question that Wonderful 101 is definately the better looking, and more technically impressive game. There was nothing impressive about Knack, textures were mediocre, limited number of characters on screen, geometry was kept rather simple, and the camera kept a pretty fixed position. It made me realize that to any developers outside of the AAA big budget developers, hardware performance is less of a hurdle these days. For many games the budget will be the limiting factor.
 
#58
So someone want to consolidate all this entire discussion into a concise and nicely written article? Is it even worth it?
we could resume this like saying that there are proves out there that point out that wii u edram is a beast on bandwidth, could have 563.GB/s to 1 terabyte of bandiwdth depending on the bus width per macro of the 8 it has, xbox 360 had 4 macros and 1024 bits each one giving you 256GB/s of bandwidth at 500mhz, since wii u edram is made by the same guys who made the gamecube and xbox 36 edram then obviously the least you can expect is 1024bits per macro(more than 7 years old design) or 2048 bits giving us the 563.2GB/s or more than a terabyte of bandwidth for 8 macros at 550mhz

this accomplishment isnt hard to believe since gamecube already packed ike 512 bits for 1MB of edram, so wii u edram packing a bus width of either 1024bits or 2048bits for each 4MB block doesnt sound crazy at all

wii u has lots of bandwith but that doesnt make it powerful, but it is very important for pefromance like tesselation and other graphica tricks besides framebuffer


recent gps like the hd4000 to hd7000 have no problems handing that bandwidth, the hd4000 for example have like 1 terabyte of bandwidth for each local data share memory for each simd core and like 480GB/s for each l1 texture cache and each texture unit has a l1 texture cache. HD 5000 goes byond this and has like 2 terabytes of bandwidth for each local data share that each simd core has and 1 terabyte of bandwidth for each l1 txture cache, and hd5000 are basically using the same old rv770 from the hd4000 with some minor changes and optimizations

problem is that those internal memories on the gpu are super small, each local data share is only 16kb to 32kb each and each l1 texture cache only 8kb to 16kb each so obviously even accounting all hese meories at must you will get something only near the 1MB with a high end gpu, so this is where the edram from wii u comes in handdy, its lik a super big global data share(global data share is only 64kb on the amd gpus)


one example of the problems tat xbox 360 port to wii u introdces is that xbox 360 edram cant be used for vertex texture fetches as its ocked for only framebuffer, the wii u edram can be used for fetch data since its not used only by the rops but by other components on the wii u gpu, but since the 360 game port uses the main ram for vertex texture fetch data then so does the wii u port, this of course introdces a lot of decrease in performance
 

EvilTw1n

Even my henchmen think I'm crazy.
Moderator
#59
We were going to do a big tech article on the minutiae of the Wii U's hardware awhile back, but decided against it. Mainly because it's dense, and if you're even a little bit wrong, you're going to have people jumping down your throat.
The 64 bits on N64 was actually just the memory bus, the graphics hardware itself was still 32 bit.

Wii U is a well thought out piece of hardware from the perspective of price, size, and power consumption. Its still by far the weakest new console. With that said, I played Knack the other day, and it showed me how much more the team and budget matter these days
, because Knack looks like a PS3 game at best. I played through the demo, and there is no question that Wonderful 101 is definately the better looking, and more technically impressive game. There was nothing impressive about Knack, textures were mediocre, limited number of characters on screen, geometry was kept rather simple, and the camera kept a pretty fixed position. It made me realize that to any developers outside of the AAA big budget developers, hardware performance is less of a hurdle these days. For many games the budget will be the limiting factor.
Mmm hmm. If you're an indie dev, you may have the talent and ability to max out new hardware, but you likely won't have the budget and manpower to actually do it (or to even max out 360-level specs). And then there are practical considerations - COD may be a AAA-budgeted game, but the devs in the past have worked on a strict 2-year schedule, so it's not like they were always making the best possible visual feast.

It's not to say visual improvements won't be made or that hardware power doesn't matter. But budgets, release schedules, and diminishing returns are all real factors. Does it make sense for a developer like Frozenbyte to double their manpower for Trine 3 for a few visual flourishes that most people will miss?
 

Shoulder

Your Resident Beardy Bear
#60
Conducting a technical article is simply a matter of how much in laymen's terms it can be done. Ideally, you want to explain it in a way your mother can understand. Explain to them what does bandwidth mean, and how it relates to the performance of a video game. There's also the matter of bits and bus, which at times I've been sketchy on. I know bits and bytes are the same thing (byte is simply by eight, so 8 bits is 1 byte). There's also the notion of what tesselation is, and how it relates to the overall look of a game. And this is before you get into the talk about architecture and how the entire system is put together. Latency, power consumption, performance, etc, all these things needs to be addressed, and explaining them in a language that most people will understand is the difficult part.
Ultimately, this business of 563.2GB/sec of bandwidth needs to be put in terms that most people can understand. What difference does it make if it's 70GB/sec, 140GB/sec, 1TB/sec, etc. How does the bandwidth relate to the game itself and does it allow a game developer to do? These are all things that should be addressed.
 
#61
Conducting a technical article is simply a matter of how much in laymen's terms it can be done. Ideally, you want to explain it in a way your mother can understand. Explain to them what does bandwidth mean, and how it relates to the performance of a video game. There's also the matter of bits and bus, which at times I've been sketchy on. I know bits and bytes are the same thing (byte is simply by eight, so 8 bits is 1 byte). There's also the notion of what tesselation is, and how it relates to the overall look of a game. And this is before you get into the talk about architecture and how the entire system is put together. Latency, power consumption, performance, etc, all these things needs to be addressed, and explaining them in a language that most people will understand is the difficult part.
Ultimately, this business of 563.2GB/sec of bandwidth needs to be put in terms that most people can understand. What difference does it make if it's 70GB/sec, 140GB/sec, 1TB/sec, etc. How does the bandwidth relate to the game itself and does it allow a game developer to do? These are all things that should be addressed.

it would be difficult for me to expain so i searched and found this good article
http://www.openglsuperbible.com/2014/01/24/memory-bandwidth-and-vertices/
"
Memory Bandwidth and Vertices


Posted on January 24, 2014 by graham 1




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
Code:
memcpy). Such a GPU might have a bandwidth of around 320  [url=http://http://www.openglsuperbible.com/2014/01/24/memory-bandwidth-and-vertices/#note-194-1][sup]1[/sup][/url] 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[/b]

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 [code]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[/code] 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.

"
 
#62
Ahh, one of my favorite sites. OGLSB. The last four words of the summary are quite true. Just because a certain console has a load of GDDR5 bandwidth doesn't mean it's all an open highway... Fairly effective for marketing to the uninformed, though...
 

Goodtwin

Well-Known Member
#63
This is a good article that shows just how important it is to have sufficient memory bandwidth, it can limit GPU capabilities significantly.



As you can see from the chart, Graphics cards with the same Gflop rating, made by the same manufacture even, can have significantly different scores. The GPU dye anylsis along with leaked developer info suggest that the Wii U's GPU has 160 stream processors, making it a 176Gflop GPU, less than the PS3 and X360. We know that the VLIW5 steam processors should be more efficient, but its still been hard to accept when we know developers are seeing quite a bit more performance from the Wii U's GPU than previous gen consoles. I think it has to do with this. Unlike the edram in the 360 that was only available for rasteration, the Wii U's edram is available for all operations. Now its still limited to the 32MB of space, so the assets will still be constrained to the 12.8GB/s from the main memory. Thanks to the increased efficiency coupled with what I believe must be enough bandwidth for the GPU to operate at full tilt thanks to the sufficient memory bandwidth, this is how a 176Gflop GPU is able to outperform the older 240Gflop GPU of the 360. There is a ton of other features that also add up as well, early Z termination, various compression techniques, much better texture caches and so on.
 

Shoulder

Your Resident Beardy Bear
#64
Also, unlike the Xbox 360, the Wii U's CPU and GPU are essentially on the same die, in the form of the MCM, so latency is reduced by a good margain, so less resources/cycles are needed to achieve the same results. Between that, the extra bandwidth of the EDRAM, and the CPU cache, the Wii U should be plenty capable, but it still lacks the raw horsepower of the PS4 and X1. Think of it as the difference between the old British sports cars of the 60's and the American muscle cars of the day.
 

Laer_HeiSeiRyuu

Well-Known Member
#65
Also, unlike the Xbox 360, the Wii U's CPU and GPU are essentially on the same die, in the form of the MCM, so latency is reduced by a good margain, so less resources/cycles are needed to achieve the same results. Between that, the extra bandwidth of the EDRAM, and the CPU cache, the Wii U should be plenty capable, but it still lacks the raw horsepower of the PS4 and X1. Think of it as the difference between the old British sports cars of the 60's and the American muscle cars of the day.
Nah. Think of it more as a BMW 350 series vs a muscle car with a v8 engine.
 

EvilTw1n

Even my henchmen think I'm crazy.
Moderator
#66
Think of it more like a Porsche Cayman versus a Porsche 918 Spyder.

Or a BRZ/86 versus a 911.

Or Keira Knightley versus Christina Hendricks.

Or something.
 
#67
This is a good article that shows just how important it is to have sufficient memory bandwidth, it can limit GPU capabilities significantly.
As you can see from the chart, Graphics cards with the same Gflop rating, made by the same manufacture even, can have significantly different scores. The GPU dye anylsis along with leaked developer info suggest that the Wii U's GPU has 160 stream processors, making it a 176Gflop GPU, less than the PS3 and X360. We know that the VLIW5 steam processors should be more efficient, but its still been hard to accept when we know developers are seeing quite a bit more performance from the Wii U's GPU than previous gen consoles. I think it has to do with this. Unlike the edram in the 360 that was only available for rasteration, the Wii U's edram is available for all operations. Now its still limited to the 32MB of space, so the assets will still be constrained to the 12.8GB/s from the main memory. Thanks to the increased efficiency coupled with what I believe must be enough bandwidth for the GPU to operate at full tilt thanks to the sufficient memory bandwidth, this is how a 176Gflop GPU is able to outperform the older 240Gflop GPU of the 360. There is a ton of other features that also add up as well, early Z termination, various compression techniques, much better texture caches and so on.


176gigaflops is impossible and makes no sense at all, ports rom 360 wouldnt even work since it doesnt matter how efficient and moern is wii u, the moment you port and tell the system to do things the way the older system does is going to limit your new system, not to mention that things like vetex texture fetches are likely strored on the main ram instead of the edram since thats how the 360 does things so now you have another big perfromance issue on your port, and a quick port done by deveopers who dont have much experience with wii u and also are using a engine that has not been tailored and optimized for wii u will also be a concern

for games to work on a weaker system you would have to be doing a ground up game, but for ports is another story,
specially accounting other issues like lazy work, developers not fa,miliar with the new system, the system not hving ven a year on the market, poo engines that are not optimized for wii u, etc

just look at assensis creed 4 for ps4

isnt ps4 about 7.5x more powerful then 360?

then why developers struggled to even accomplish 1080p 30fps and had the game running on 900p before the patch?
,
why 30fps and not 60 fps if ps4 is about 7.5 more powerful than 360 and for having the game at 1080p 60fps you would only need about 3.5x more power than 360 and lets not forget that just like wiiu, ps4 is more modern and efficient and also easier to develop for thanks to the x86 environment and also no edram to deal with just main gddr5 ram with both good amount and good bandwidth?


the same goes with bayoneta

which console is more powerful ps3 or xbox 360?
which version of bayo is better and which one looks bad and has half the framerate?
which one is the port and which one is the ground up game?


the same thing applies for wiiu, ports dont take profit of the system and if a console that is more powerful modern and easier to develop for than the other seems to require about double the power of the other one to render the same game at same resolution and framerate (assesisn creed 4 ps4 v 360 resources) then why wii u would do any miracles with less power than the other one in ports?


so no, 176 gigaflops wont do at all for prots, maybe for gound up games but not ports, fo that you need at least a system more powerful than the other one by a bit to even get your game running smoothlyWiiu should be about 400 to 550 gigaflops just by seeing how ports run without much of an effort using poor engines, few time development and develpers not used to the systemwe can also conclude this seeing that a redwood xt also at 40nm can pack like 400 stream cores, 20 tmus and 8 rops in 104mm2(not measured with a precise photo like chipworks so could actually be less like 94mm2), wii u gpu even without edram and other components like the DSP or ARM cores is about 96mm2, so obviously you can fit as much components as lik the redwood xt in there

also if you read the artlicle bandwidth is important for vertex processing, so why would nintendo put so much bandwidth if the system wouldnt pack enough vertex power for it?

nintendo makes balanced systems, they aint gonna put bandwidth that will go to waste, even at 1080p framebuffer you just require the bandwidth that 16MB of edram provide, so we still have another 16MB and obviouly at 720p framebuffer would have even more so makes no sense to have tht much bandwidth with a gpu with just 176gigaflops


that report of the 176 gigaflops was made at neogaf speculating that the once thought tmus were actually interpolators reducing the sream cores from 320 to 176
seriously?, interpolators?

didnr amd mention that those things were limiting the harwdar an thats why they removed them from the rv770 for the rv870 to handle interpolation with the simd cores?
dont forget that from rv770 to rv870(hd5000) there is not much differenc ei architecture, is basically the same gpu with minor upgrades here and optimizations there

remove the interpolators and put simd cores there and tell me how many stream cores we have now?


in neogaf also speculate bandwidth numbers that dont make sense like 70GB/s, come one, even xbox 360 required a lot bandidth like 256B/s for framebuffer, so how wiiu can hold a framebuffer of 1080p in 16MB with xxbandwidth if 360 needs all the 10mb FOR 720p?

you think bandidth isnt importnat for framebuffer?
here
http://www.ign.com/articles/2005/05/20/e3-2005-microsofts-xbox-360-vs-sonys-playstation-3?page=3
"


E3 2005: Microsoft's Xbox 360 vs. Sony's PlayStation 3

With Sony's specs out, Microsoft has sent us its a comparitive analysis. What's the outcome?



by Douglass C. Perry
May 20, 2005







Submit
Tweet
Share
+1
Share


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.


HDR, alpha-blending, and anti-aliasing require even more memory
bandwidth
. This is why Xbox 360 has 256 GB/s bandwidth reserved just for
the frame buffe
r. This allows the Xbox 360 GPU to do Z testing, HDR,
and alpha blended color rendering with 4X MSAA at full rate and still
have the entire main bus bandwidth of 22.4 GB/s left over for textures
and vertices.




"
 

Goodtwin

Well-Known Member
#68
This is why you get banned in forums, you dont make your own post, but copy and paste articles that you think help your own conclusion, one that no technical forum on the internet supports. Not everything is coded specific to the hardware. Developers dont have to code for things like early Z termination, the hardware just does it. Try writing you own post once in a while without spamming shit you dug up on google. The reality is that yes, a 176gflop gpu from 2011 could outperform a 240gflop gpu from 2005. Flops dont scale perfectly across different architectures. Look at Nvidia vs AMD for example, a much lower Gflop Nvidia card can outperform higher Gflop AMD graphics cards.
 
#69
This is why you get banned in forums, you dont make your own post, but copy and paste articles that you think help your own conclusion, one that no technical forum on the internet supports. Not everything is coded specific to the hardware. Developers dont have to code for things like early Z termination, the hardware just does it. Try writing you own post once in a while without spamming shit you dug up on google. The reality is that yes, a 176gflop gpu from 2011 could outperform a 240gflop gpu from 2005. Flops dont scale perfectly across different architectures. Look at Nvidia vs AMD for example, a much lower Gflop Nvidia card can outperform higher Gflop AMD graphics cards. still better than assumming an speculation as a fact

and why assume such a bad speculation of 176gigaflops instead of specualtions like 50% more powerful?
seriously, you sure are nor a troll?

numbers are numbers, even if its customized the basics are the basics, you dont put bandwidth just for putting it, you cant run a game of a ore powerful system on a weaker one if its a port, only a ground up game, thats no speculation, hats a prove that games have demostrated like bayo or asseins creed 4 which developers had at 900p 30fps despite that ps4 is more modern and 7.5more powerful in raw power than 360 and still couldnt run the game at 1080p60fps which requires less than half that power, and also is more effcient, has better performance and easy to develop for, so what whats going on?


a system of 2011 may outperform a system from 2005 and may run its games but only, only if we are talking about a ground up game, not a quick port with incoenients like
:

develeprs not used t the hardwrae
few time for porting it
engines not optimized for the new system
porting issues like having your fetch data sotored in main ram instead of edram cause thats how 360 does it and so will the wii u quick port
etc

is also a fact that wii u gpu die size is on par with a redwood xt and how many stream cores does a redwood xt has?

its a fcat that amd mentioned that interpolators limit performance and were removed and that neogaf previously had 320 stream cores and later had half of that beacuse they supposdly mistook the tmus for interpolators


do interpolators resemble texture units to be confused in the first place?

and about banning, sorry i dont get banned everywhere, do you homework, i ony got banned at byond3d, which everybody knows is no place for nintendo cause are a bunch of nintendo haters and everybody knows that, you are lucky if not get banned if you put good info about wii u hardware

facts come before speculation
:
* wii u gpu die size on par with redwood xt is a fact
* wii u running ports despite that they are lazy must of the times and that developers are not used to the harwdare and using engines not optimized for the system and also few budget on the port is another fact
* ports hurting the performance of the system you port it is also a fact, bayoneta and assesins creed 4 are good examples
* it matter not if the system is more efficient if that efficiency and performance is bottlneck by the port that taes no profit of the new harwdare characteristics cause the port comes from a directx9 hardwrae and obviously was made for the other harware characteristics in mind is also a fact
* bandwidth is important not just for framebuffer but also for vertex and pixel shaders is a fact not comming from me but from reliable sources like ign and others
* developers not complaining at all about the bandwidth of the system and even some of them like shinen say that the edram has plenty of high bandwidth and also the manufacturer of the edram quoting that wii u edram uses latest technolies is also a fact
*wii u having more than enough bandwidth for 1080p framebuffer with just half the 32MB of edram is a fact, so if the rest of the edram doesnt go for framebuffer, then for what it is?
 
#71
FYI, the 176 number was invented by someone with little technical knowledge on neogaf in the middle of a guessing game. It has no relation to the actual performance of the Wii U console.
 

Laer_HeiSeiRyuu

Well-Known Member
#72
FYI, the 176 number was invented by someone with little technical knowledge on neogaf in the middle of a guessing game. It has no relation to the actual performance of the Wii U console.
http://media.247sports.com/Uploads/Assets/971/770/770971.gif
 

Goodtwin

Well-Known Member
#73
Not totally, BGassassin had developer documentation supporting those numbers. Apparently they checked out with the moderators at gaf. Not sure how much that matters. Honestly I dont know why I got back into the specs, the only thing that matters to me is the performance developers are seeing. There is actually a very good article with naughtydog about optimizing software for ps4. A lot of it is relevant for the Wii U, simply because you know the majority of that stuff isnt done for ports to Wii U. Especially when talking about optimizing the caches.
 

Laer_HeiSeiRyuu

Well-Known Member
#74
Not totally, BGassassin had developer documentation supporting those numbers. Apparently they checked out with the moderators at gaf. Not sure how much that matters. Honestly I dont know why I got back into the specs, the only thing that matters to me is the performance developers are seeing. There is actually a very good article with naughtydog about optimizing software for ps4. A lot of it is relevant for the Wii U, simply because you know the majority of that stuff isnt done for ports to Wii U. Especially when talking about optimizing the caches.
It was still unfounded bs in the end. ( go check gaf again)
 

Shoulder

Your Resident Beardy Bear
#77
I'm still in the 352GFlop boat, personally. I suppose it's not impossible for it to be 176GFlops, but given what sort of performance the Wii U can manage for a game such as Bayonetta 2, >176GFlops seems more likely. However, Flops don't tell the whole story when it comes to performance. It's like saying the car with the most horsepower will always win the race, and that has been shown to not always be the case.
 
#78
Not totally, BGassassin had developer documentation supporting those numbers. Apparently they checked out with the moderators at gaf. Not sure how much that matters. Honestly I dont know why I got back into the specs, the only thing that matters to me is the performance developers are seeing. There is actually a very good article with naughtydog about optimizing software for ps4. A lot of it is relevant for the Wii U, simply because you know the majority of that stuff isnt done for ports to Wii U. Especially when talking about optimizing the caches.
BG is the same reason why i gave any credence to the 176flops number as well. It's just that number just seems way too when you consider the fact the we know the Wii U tools were crap until around launch, yet developers still managed to make ports that were close enough to the 360/PS3 versions and better in some cases at launch. The 352 flops conclusion reached by gaf sounded more reasonable because of the overhead you have to help with the bad tools and lack of optimization. People will say that the newer architecture is what is allowing the Wii U to be able to keep up with or slightly overtake the last gen. That sentiment is likely true, but the fact Xbox One's Gpu is like 500% more capable than last gen on paper (before you even factor in the newer architecture) and is running games like Call of Duty Ghosts with a mere %50 increase in resolution is a good enough reason for me to believe that the Wii U is probably being held back substantially by last generation game development. We don't have any fully detailed specs for Wii U all we have to go on are the games and some dev comments, both of which paint Wii U as being marginally better than last gen. Imagine how much the worse the situation for Xbox One would be if we didn't have the spec information and games like Ryse, Battlefield 4, and NBA 2K14 would have never been shown or looked significantly worse because of developmental issues. Nintendo just needs to show one game that makes the best looking games of last gen look notably dated in comparison (Zelda HD LAWD!!!), if Mario Kart and X ran at 1080p i think that would be enough for most people to say that the Wii U is significantly more capable than last gen while still not being a next gen leap.
 
#79
I didnt see anything that debunked BGassassins info. You have a link?
Yes, some of it was admitted by himself to be off at least to an extent, and the whole place including himself went to look for another possiblenumber. On a side note, I also happen to know where he got some of his info before he told others...
 
#80
I didnt see anything that debunked BGassassins info. You have a link?
dont see the need for something that anybody can debunk with simple analisis but here its is
http://nintendoenthusiast.com/news/wii-u-downgrade-rumor-summarily-shot-shinen-twitter/"Wii U Downgrade Rumor Summarily Shot Down by Shinen on TwitterPosted on on November 7, 2013Shinen Games was just asked on Twitter about apparent rumors that Nintendo had downgraded the: rgb(17, 17, 17);">Wii U. True to form, they point out the dev kits were upgraded from when they first received it.
The rumor comes from this NeoGAF post examining the system’s base specs, which has not been publicly disclosed by Nintendo, but is speculated here at 160 ALUs, 8 TMUs, and 8 ROPs. The poster then tried to collect information from older interviews to clarify how they got to these specs. Taking tidbits from another forum thread about earlier Wii U prototypes, an interview with Vigil Games, and the Iwata Asks on the Wii U, the poster came to the conclusion that Nintendo must have lowered the system’s power specs to fit a smaller case.

Unfortunately, considering the process of making launch games for new consoles is a secretive and difficult process, I think there is too little information publicly available to really make these kinds of calls. Even if we take into account developers breaking NDAs, each group involved with a system launch really only has a limited amount of information. Developer kits themselves are expected to get tweaked as the specs get finalized, and the only people who would really know are too far up in the industry to say anything.
@VagelisVala Our devkits replacements got faster.

— Shin’en Multimedia (@ShinenGames) November 7, 2013
So, obviously, Shinen has eviscerated the rumor, and we hope they elaborate on this later, but this does raise new questions about the system’s design. Can Nintendo be convinced to release more information on its power and specs? Did 3rd parties have as hard a time making Wii U launch games as they did making PS4 and Xbox One games? Maybe we can have another Iwa
ta Asks so that they can clarify all this and clear up doubts about the system’s capabilities."
 

Shoulder

Your Resident Beardy Bear
#81
Shin'en are where I've gotten most of my information on the Wii U's capabilities, because they are so willing to give people a good idea on the system's power. And after I first saw that article concerning dev kits getting faster, I suspect the early kits had HD4**** GPU (hence where those rumors came from), but then a 5000 or 6000 series was put in along with a more finalized CPU, since developers had issue initially getting the hang of the CPU itself, and were in some cases only using one or two cores.
Also, as Shin'en has mentioned, utilizing the eDRAM, AND the CPU Cache is crucial to getting the necessary performance out of the Wii U, or you will lose a lot of performance in the process. This I suspect is why many ports and multiplats at first were only on par or even slightly worse performing comapred to the 7th gen twins.
 
#82
Shin'en are where I've gotten most of my information on the Wii U's capabilities, because they are so willing to give people a good idea on the system's power. And after I first saw that article concerning dev kits getting faster, I suspect the early kits had HD4**** GPU (hence where those rumors came from), but then a 5000 or 6000 series was put in along with a more finalized CPU, since developers had issue initially getting the hang of the CPU itself, and were in some cases only using one or two cores.
Also, as Shin'en has mentioned, utilizing the eDRAM, AND the CPU Cache is crucial to getting the necessary performance out of the Wii U, or you will lose a lot of performance in the process. This I suspect is why many ports and multiplats at first were only on par or even slightly worse performing comapred to the 7th gen twins.


you are right in that, actually after that statement i started to look inside the xbox 360 characteristics like the memory export and such and discovered one of the biggest performance drops you can have on wii u when you do a port, here
http://hdwarriors.com/forums/topic/how-an-xbox-360-port-makes-wii-u-under-perform/

"


Well, in the thread “How an xbox 360 port makes Wii U under perform
part 1″ we pretty much covered must of the things that happen in the
porting that make the Wii U system under perform and waste its
potential. But now we are gonna focus on one of the biggest bottlenecks,
the “Memory Export”


Review:

In the thread “How an xbox 360 port makes Wii U under perform part
1″ we saw that since the xbox 360 only has 1 mega of cache and only 10
megabytes of Edram , the source code from xbox 360 game only considers
those specs and so all the things that could have been fitted on the
extra cache and extra edram of the Wii U goes directly to the main RAM.
Also, xbox 360 has no DSP for sound so the game uses one of the xbox 360
cpu cores for that, meaning that the port to Wii U will likely also use
one of the Wii U cpu cores for sound instead of the DSP, and that cpu
core could have been placed for another task to speed up things so there
would be no frame rate issues



Now lets see the Memory Export of xbox 360 GPU and how it affects Wii U ports


So, what the Memory Export?




Well, to put it simple, is a feature that lets the gpu to export data to the Main RAM(System Memory) from within any shader
.
That may be good for Xbox 360 since doesnt pack enough Edram for fetch
instructions but is not good for WII U since it could be using the Edram
for this(since we are talking about a port from 360 to Wii U the edram
is wasted and instead WII U is forced to use MAIN RAM for fetch data),
in fact, the xbox Edram is only enough to hold either 720p with double
buffering or sub-hd+Antialaising+ z buffer, but Wii U packs enough Edram
Mmeory and bandwidth for resolution+msaa+z buffer+ fetch data. The
limitations of the xbox 360 Edram are not just a comment from Shin’en,
Microsoft themselves admit this limitation


http://msdn.microsoft.com/en-us/library/bb464139.aspx



Predicated Tiling

Other Versions 0 out of 1 rated this helpful – Rate this topic

Describes predicated tiling in Xbox 360 development.

The Xbox 360 has 10 MB (10×1024×1024) of fast embedded dynamic RAM (EDRAM) that is dedicated for use as the back buffer, depth stencil buffer, and other render targets. Depending on the size and format of the render targets and the antialiasing level, it may not be possibleto fit all targets in EDRAM at once. For example, 10 MB ofEDRAM is enough to hold two 1280×720 32-bit surfaces with no multisample antialiasing (MSAA) or two 640×480 4× MSAA 32-bit surfaces.
However, a 1280×720 2× MSAA 32-bits-per-pixel render target is
7,372,800 bytes. Combined with a 32-bit Z/stencil buffer of the same
dimensions, it becomes apparent that 10 MB might not be sufficient.






Note: double buffering for 720p refers to two
1280×720 32-bit surfaces, the part that says “a 1280×720 2× MSAA
32-bits-per-pixel” does not have double buffering.




As you may know, Shin’en already said that the Wii U Edram(embedded
directly on the same die with the GPU) only needs about 16 MB for 1080p
with double buffering, which for 720p with double buffering would be
about 7.11 MB. Since the Wii U packs 32 MB of Edram + 2 MB of faster
Edram + 1 MB of SRAM, there is plenty of memory left for other stuff
besides resolution, msaa, z buffer, etc.


So, since the Xbox 360 Edram is not used for fetch instructions like
texture fetch data, the 360 GPU has to export this data to the slower
Main RAM. Even though the Wii U has enough Edram for resolution, msaa, z
buffer and fetch instructions(even more if nintendo sticks with 720p),
since we are talking about a port from 360 to Wii U, the source code
from 360 adapted to Wii U tells the system to use the slower Main RAM
for the fetch instruction instead of using the Edram
.
The slowdown is
tremendous since the Edram is super fast and has plenty of bandwidth
while the Main RAM is a lot slower and has few bandwidth, so the GPU
capabilities and power are being bottleneck by forcing it to use the
Main RAM instead of using the Edram to accomplish the vertex texture
fetch instructions.



Fetch Instructions are more important than what they sound, with them
you can do a particle system, fluid simulations, displacement maps,
tessellation, etc



here a little overview on texture fetch data


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



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.







What proof do I have that developer arent usingn the xbox 360
Edram for fetch instructions besides Microsoft admiting this
themselves?


well, here you have an example (check pages 8 and 9)


.pdf" rel="nofollow">http://www.cse.chalmers.se/~uffe/xjobb/ParticleSystemSimulationAndRenderingOnTheXbox360GPU.pdf




Particle System Simulation and Rendering on

the Xbox 360 GPU


Another unique feature of the Xbox 360 GPU is that it has 10 MB of very

fast (256 GB/s) embedded DRAM where render targets are stored. This

memory can not be used as the source of any fetch instructions
. There are

many reasons for why this is a good feature of the Xbox 360 GPU (e.g. very

cheap anti aliasing) but since it is not possible to use the EDRAM as the

source for any fetches, a copy-back to main memory is needed (called a

“resolve”, which occurs at a rate of 8 pixels per clock cycle) before it can be

used in a shader. This extra cost is one of the reasons for why we do not use

render-to-texture for our particle simulation (though the benefits of using

another method, memory export, are the primary reason).


The Xbox 360 can fetch 32 bytes of data per fetch instruction, and uses

an 8KB cache for vertex data, and 32KB of (16-way set associative) cache

for texture data(3).


Perhaps the most revolutionary feature of the Xbox 360 GPU is the

shader memory export. Using this it is possible to export data to system

memory from within any shader
. This can be done in an arbitrary fashion

(i.e. it’s not restricted to outputting data in a stream, like with DirectX 101

(4), but supports full scattered memory writes) and can even be the sole

purpose of a shader (a vertex shader does not need to have output passed on

to the rasterizer – it could do its work entirely through memory export). We

shall make heavy use of memory export, both for simulation (exploiting

primarily the fact that we can use it in arbitrary shaders, and thus can run

our simulation at the same time as the rendering) and for sorting (exploiting

the scattering support to do proper compare-and-swap operations, and avoid

the redundant copying inherent in the “ping-ponging” of render-to-texture

based approaches)







Well, hope you now see why a port fro 360 to Wii U will make the new
hardware to bottleneck by forcing it to use Main RAM for things that
could be placed on cache and Edram
. What developers have to do after
porting is to rework the source code of the game and reallocate
reallocate resources from MAIN RAM to cache or Edram, but that takes
time and effort so must of them dont bother in optimizing the source
code and prefer to just do some patches here and there, they may use the
edram and cache for this, but that wont make the port to do miracles as
the important stuff to speed up the game still resides on the MAIN RAM
.
And lets not forget that the DSP is also being wasted in must of the
occasions and one of the cpu cores is being used for sound instead of
using it for another task that could speed up things and so alleviate
frame rate issues(the extra cache and the L3 cache with edram is also
important for 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 changesAll 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


besides, the wii u gpu die size is big even without edram+dsp+arm, the gpu alone is about 96mm2 which is similar to a redwood xt of 104mm2 but this gpu might actually be as small as 94mm2 just by looking at the die sizes that anadtech reported and chipworks reported for the wii u gpu, so, if 94mm2 can obviously fit on 96mm2 obviously you can fit as much as 400 stream cores, 20 tmus and 8 rops
, we also have to consider that nintendo might have removed paets that are not needed like the crossfire controller(unless they wanted to provide something like an expansion gpu accessory which seems unlikely by seeing the wii u exterior). Plus, many state that there are only 16 tmus when you can fit 20 of them, so obviously either nintendo could have put more stream cores or even dedicate that space of the 4 tmus for their fixed function harwdare part, after all the tmus are big and occuppy large area
 

Goodtwin

Well-Known Member
#83
Gawd, I think I am actually leaning with you guys a bit, mostly towards 320 SPU's, but no more than that, mainly because power draw does come into play. I read through a ton of post over at Beyond3D today, going back pretty far. It does seem that the idea of 160 SPU's was never really more than a theory, its just one they ended up accepting based on the fact that so many Wii U ports have underperformed, with their basis being that a HD5550 (320 SPU's 550mhz) easily outclasses the 360 even in the PC environment so why in a closed box is it not doing so. I think a few possible reasons, one being that the GPU in the Wii U does not use the straight forward GDDR5 memory approach, and we can see with the X1 how developers just love managing their memory. Not only that, but benchmarks for GPU's are almost always paired with a nice powerful I7 CPU to make sure the CPU isnt bottlenecking the GPU in any way. So basically, no one has been able to find a perfect match to compare it to the Wii U GPU dye photo, I guess everyone should have listened when Jim Morrison from Chipworks said doing so would be pointless. I guess what has really changed my opinion on their theory is looking how X1 performs with its even more modern 1.2 Tflop GPU. They acted as if a 352 Gflop GPU should be doing things that the 1.2 Tflop GPU powering the X1 isnt doing. I also think they are underestimating just how much work the big developers offload to the Xenon and Cell, those CPU's could easily tighten up the gap between the older 240 Gflop Xenos the newer 352Gflop Latte. I am starting to lean back towards the idea that 50% more GPU power could easily be wasted with bad SDK's and port teams that simply arent there to improve the game in any way shape or form.

@nintendoman

I know you cant disclose much, but are you able to elaborate at all on that?
 

EvilTw1n

Even my henchmen think I'm crazy.
Moderator
#84
I guess what has really changed my opinion on their theory is looking how X1 performs with its even more modern 1.2 Tflop GPU.

And that's with some goosing.
http://www.gamechup.com/microsoft-has-increased-xbox-one-gpu-speed-by-53mhz-to-853mhz/

I guess everyone should have listened when Jim Morrison from Chipworks said doing so would be pointless.
Which is why we have shied away from posting very elaborate tech articles, or ones that try to draw definitive conclusions. You can listen to 10 different internet message board experts and have your mind changed by each of 'em, and none of them really know what they're talking about, anyways, because they're not working with the hardware.
 
#85
No matter how the guy in the cinemablend article chooses to spin it, the fact of the matter is that the Wii U less powerful than the Xbox 360 and PS3.
Batman Arkham Origins Wii U is running at a lower frame-rate. BLOP2 was the same on Wii U in comparison to PS3/360. Mass Effect 3 has Special Edition had low resolution shadowmaps. And many more examples.
Maybe when Nintendo shows at least 1 game that can put PS3 to shame people will believe Wii U is next-gen, but until then, it's safe to say it doesn't hold a candle to what the PS4 can do.
PlayStation 4 is the future and the future is PlayStation 4.
 

Laer_HeiSeiRyuu

Well-Known Member
#86
No matter how the guy in the cinemablend article chooses to spin it, the fact of the matter is that the Wii U less powerful than the Xbox 360 and PS3.
Batman Arkham Origins Wii U is running at a lower frame-rate. BLOP2 was the same on Wii U in comparison to PS3/360. Mass Effect 3 has Special Edition had low resolution shadowmaps. And many more examples.
Maybe when Nintendo shows at least 1 game that can put PS3 to shame people will believe Wii U is next-gen, but until then, it's safe to say it doesn't hold a candle to what the PS4 can do.
PlayStation 4 is the future and the future is PlayStation 4.
Lol sarcasm
 
#87
No matter how the guy in the cinemablend article chooses to spin it, the fact of the matter is that the Wii U less powerful than the Xbox 360 and PS3.Batman Arkham Origins Wii U is running at a lower frame-rate. BLOP2 was the same on Wii U in comparison to PS3/360. Mass Effect 3 has Special Edition had low resolution shadowmaps. And many more examples.
Maybe when Nintendo shows at least 1 game that can put PS3 to shame people will believe Wii U is next-gen, but until then, it's safe to say it doesn't hold a candle to what the PS4 can do.
PlayStation 4 is the future and the future is PlayStation 4.


is a new system, is expected that performance wont reach is peak at its first year, neither the ps4 and xbox one are doing it and seem to underperform worse in ports acuase despite being 500% more powerful or 750% more powerful and almost a decade more modern they still cant output 1080p 60fps on port from 360 and ps3 when about 300% of power is required for that and they have tons more than that, and also they perfrom as bad as being just 720p like call of duty ghosts for xbox one or 900p30fps for the assesins creed 4 on ps4

we already know that wiiu is more powerful than 360 and ps3 not just thanks to the comment on developers, but also beacuse the die size of the wi u gpu is on par with a redwood xt at 40nm, so obvoulsy there is space enough t fit 400 sream cores, 20 tmus and 8 rops

if you want to know the real reason why there is not much support for wii u you can red this
"

http://nintendoenthusiast.com/inter...zzygames-shares-experiences-developing-wii-u/

"

Open Book Developers: FuzzyWuzzyGames Shares Their Experiences Developing for the Wii U and Views of Nintendo Today




Posted on on January 15, 2014

Armillo

Release Dates





Both Nintendo
and its enthusiasts have been on quite the roller coaster since
Nintendo’s latest home console was revealed back at E3 2011. They had a
lot to be excited about after viewing the Wii U announcement trailer, the third-party support reel, and the subsequent showings of the Zelda HD Experience and Japanese Garden
(extended version) Wii U
tech demos. By showing what they had at that conference, Nintendo had
effectively promised three things: full investment of the Wii U GamePad,>strong third-party support in an effort to appeal to a wider gaming audience, and a capable platform.Unfortunately, a different reality played out shortly after enjoying a stronger launch than its seventh generation competitors. Support from
Nintendo and its partners quickly became scarce, causing the Wii U to
achieve a record-setting quarterly low
in sales. With the only explanation being that they had underestimated
the transition from standard definition to high-definition, there are
still a lot of questions left unanswered. We hope to address all of
these via the accounts of named developers who have worked hands-on with
the system and Nintendo.


And so, because accountability matters, Open Book Developers is a new
series that Nintendo Enthusiast is kicking off, where we focus
front-and-center on contents, discontents, and mild pleasures with the
way Nintendo operates both as a hardware and software manufacturer. By
documenting these experiences, we hope minimize the confusion behind the
developmental side of the industry from content creators









“In terms of performance, I had to down-res Armillo on the XNA build to
around 580p to get it to run smoothly on the 360. On the Wii U, I’ve
left it at 720p and it also has more post-processing and lighting
effects going on. I’m sure the PS4²⁵/Xbox One²⁶ are quite a bit more
powerful in terms of pixel pushing, but the Wii U’s GPU feature set is
also a lot closer to the PS4/Xbox One rather than Xbox 360 and PS3²⁷.
I’d say it’s good enough for us indies.”






GoldMetalSonic:
How
different is the game on Wii U than the planned Xbox 360²⁸ version? In
fact do you have any screens of the Xbox 360 version when it was as far
as it gotten?
28. Xbox 360:
Developed by Microsoft, Xbox 360 is the first entry to the 7th
generation of video game consoles, as the successor to the original
Xbox. Launch: November 22, 2005.

FWG:
“Biggest change would be the
port to Unity²⁹. Most of the code was re-written in this process so
that the development workflow works much better with Unity itself. I’d
say the core game is nearly the same (controls, model assets, level
layouts, etc.), but everything else around it changed. Unity made
development a lot easier – tweaking and tuning the game ended up being
way faster.”

GoldMetalSonic:
Since
you said Wii U’s GPU feature set is closer to PS4/Xbox One than
PS3/Xbox 360, can you comment on what possible features Wii U shares
with PS4/Xbox One that PS3/Xbox 360 don’t have? Certain graphical
effects?

FWG:
“It supports DirectX 11³¹ type features. I can’t really
discuss too much about this personally (NDA stuff), plus I’m not that
experienced as a graphics programmer. But you can find some nice details
on it from various sites on the web.”

Laer_HeiSeiRyuu (Follow Up): Wii U supports the majority of the features outright, so if you were porting, it should be a relatively smooth process, yes?FWG: “Somewhat, especially when you’re porting from a PS4/Xbox
One/PC game. There are still a couple of issues around it making it not
exactly a trivial task.

One is that each console has their own SDK and interfaces. So a game
company will need to wrap their code around a new SDK which can take a
lot of time. This one isn’t an issue if a cross-platform engine is used
such as Unity or Unreal³³.”



Goodtwin³⁴:
I guess more so
than asking questions about the hardware, how about a breakdown of the
game itself? Shaders, lighting, particle effects, what do you have going
on. Also, are you able to write low level code, or are you limited by
the toolset? I think we would be interested to know what effects this
Wii U build is getting that would have been either impossible or
undesirable on the 360.

34. Goodtwin: Active forum member at Nintendo Enthusiast.

FWG:
“Shaders – I’d say nothing
too elaborate here. I haven’t worked on anything that can’t be supported
beyond the shader 3.0 model. But I’ve recently got some help from a
technical artist who is trying out an energy conserving shader and HDR
in our game and it’s looking really nice so far. We’ll have to see how
far we can get this and how well it works on the Wii U.

Lighting – We’re using a mix of dynamic lighting and light maps on some levels. Again, nothing too elaborate here.


Particle Effects – I’d say here is where the Wii U version will shine
over the 360′s XNA version, mainly because on the 360 version, I had
coded a rough limited custom particle system engine that is hard coded.
Now on the Wii U, I’m using Unity and using the FX Maker plugin, which
makes life so much easier. Takes minutes to create, tune, and spawn a
new particle effect and it looks way nicer.

Low level code? Yep, it’s possible through Unity’s plug-in system.”In
an attempt to explain why Wii U might not be seeing support from
third-party publishers in the future, the anonymous developer published
their accounts working with the Wii U pre-launch date. They cited a
frustrating developer kit costing them valuable time, an underpowered
CPU, and an alarmingly incomplete network infrastructure among other
details.

The following are FuzzyWuzzyGames’ personal opinions on the matter via
their own accounts working with Nintendo, not to dismiss the accounts of
the anonymous developer, but to provide a different angle to the story
from a developer with a name.

"…I haven’t heard of a single [console launch] that wasn’t problematic in many ways during [pre-launch] period.

FWG:
“Just some background
information about me, I’ve worked on the professional industry for 8
years as a programmer. I’ve never touched PS4 or Xbox One development so
I can’t comment much on those. I also don’t have any experience with
the pre-launch Wii U development, but one thing is that I’ve been through a number of other pre-launch console development and talked to anumber of developers with their experience on many of them, and I haven’t heard of a single one that wasn’t problematic in many ways during that period.
It’s just the reality of development – they provide you with the tools
and hardware before anything is finalized, you’ll get lots of things
that just doesn’t work because lots of things are still changing. Tech
support is super busy because they’re dealing with a new system that
they’ve just learned about
. I’ll bet chances are that you can probably
write a similar article for many other platforms like this talking about
how terrible developing their hardware was during the pre-launch
days.This is also the time when the console development team is the
busiest where they have to not only create a ton of new software,
drivers, etc. for this new console, but also work on fixing bugs,
supporting development teams, and working with new hardware revisions.


So even on other console platforms, it wasn’t unusual to see a major
hindering bug and not have it patched for a month or so. It almost
sounds like the person who wrote the article never worked on other
consoles pre-launch – I hope that’s not the case otherwise it’ll signal
an unfair bias towards the Wii U.

"Support is fast and they keep coming up with new tools to make things easier.


Under NDA, I can’t reveal anything specific. But generally speaking,
working on post-launch development on the Wii U, I’d say development
environment is pretty good and stable. Support is fast and they keep
coming up with new tools to make things easier.


I also think the CPU is fine even though it’s slower than the 360,
although I’m sure that will be more challenging to AAA developers
compared to indie developers.

It’s the difference between code that has been through the hands of 1-3
developers versus 50-200 developers, which leads to a lot of code
overheard with a lot more people working on it. I’ve worked as an
optimizer for various commercial games. I
always find that no
matter what, there will always be room for cpu optimizations – it all
depends on how much effort you put into it (like that article says, he
wished he had more time to do some optimizations). There’s a good chance
that not as much effort is being placed on the Nintendo platforms here
due to sales forecast, so we’re seeing games that are slower than other
platforms like CoD: Ghosts.


"It’s the difference between code that has been through the hands of 1-3 developers versus 50-200 developers…


But the thing that I agree on is that most AAA developers are dropping the system more due to their sales figures
. But
what I disagree on is the other points where the games are not
appearing due to development teams being put off due to the poor tool
chain, hardware, and technical support – in big game companies, the
developers rarely have a say on this. But it’s generally the higher
ups/execs who decide whether the games get canned. Sadly, it’s rarely
about the development process, but more of what money it can make the
company.”
"













"

580p in 360?
mm, maybe they were a little lazy on this port, besides tey mention that wii u has more post processing and lighting, so since 360 has been around 7 years with new optimized tools and engines and wii u only 1 year, well i would have expected more from 360 if wii u wanst more powerful than it
 
#88
Much power is still left untapped. A large a portion of that is actually the fault, either directly or indirectly, of Nintendo themselves. The pro-Nintendo devs are only telling half the story and something else Nintendo did wasn't so nice to devs.

Electronic voice: PlayStation

p.s.: Stop while you're ahead, magafenix
 
#90
Did you just own me with my own article?
Armillo is just an indie game.

PlayStation 4 is the future and the future is PlayStation 4

so what?does that change the fact that runs better on wii u and at 720p with better post processing and lighting and xbox 360 is at 580p despite that xbox 360 has been around for more than 7 years and that the tools and engines are more optimized for it and that wii u has been just 1 year around with tools and engines that are just getting better over the time as the developer mentioend?

other port games also are better on wii u and not necessarily indies
need for speed
trine 2
asesins creed 4 looks better on wiii u but still little framerate issue
and who can forget the Deus Ex: Human Revolution — Director's Cut
etc

want to see them?
here
http://www.youtube.com/watch?v=DW_GvYQKgP4


or this
https://www.youtube.com/watch?v=gZeDsbZfTMk






Wii U:
not saying wii u is at xbox one or ps4 level ,packs almost the same new features wth its custom api that can do shader model 5 things, but in brute force of course is behind, wii u even if it was 450gigaflops or even 600gigaflops at must still is far behind the 1.2 teraflops or the 1.8 teraflops of the other new consoles, bt since they are aiming for 1080p, with the power that wii u packs shoul be enoug for 720p
 

Goodtwin

Well-Known Member
#91
Your overreaching Megefenix. You cant just add up dye space and declare that it has enough room for this or that, not with any credibility anyway. I think the fact that the Wii U's chip is manufactured by Renasas throws a wrench in trying to compared it directly to other dye photos, since they wouldnt be manufactured by Renasas. Density can be different from manufacture to manufacture. Since we know the maximum power draw for any Wii U game is around 35 watt, and the components other than the GPU would pull at least 10w, its safe to assume the GPU is working with 15w. Perhaps we will see this go up a bit as developers learn to really push the hardware, but as of right now its reasonable to assume the GPU pull less than 20w max, so guesstimating 500 Gflops isnt very realistic. 352Gflop with 15-20w is pretty damn impressive.
 
#92
I'm sure they could have eeked more out of the PS3 and 360 versions of those games if more dev time was given to them. In the end, Nintendo screwed up. They bet too much on Mario when they should have seen that the Wii was a fluke. I honestly believe their next system will be out by 2016. But at least Wii U owners are getting quality games.

PlayStation 4 is the future and the future is PlayStation 4
 
#93
Your overreaching Megefenix. You cant just add up dye space and declare that it has enough room for this or that, not with any credibility anyway. I think the fact that the Wii U's chip is manufactured by Renasas throws a wrench in trying to compared it directly to other dye photos, since they wouldnt be manufactured by Renasas. Density can be different from manufacture to manufacture. Since we know the maximum power draw for any Wii U game is around 35 watt, and the components other than the GPU would pull at least 10w, its safe to assume the GPU is working with 15w. Perhaps we will see this go up a bit as developers learn to really push the hardware, but as of right now its reasonable to assume the GPU pull less than 20w max, so guesstimating 500 Gflops isnt very realistic. 352Gflop with 15-20w is pretty damn impressive.

yea, it the way they can fit components can vary since renesas is doi g the manufacturation, but doubt its going to be that much, and it doesnt necessarily mean less components, it can also be the other way

about the 35watts, well, remeber that the aticle provides proof that the wii u power supply is class a level 5, and thats no speculation, that comes from the department of energy of the eua, you can check out the link and see for yourself. Since i fact that wii u external power supply can have a efficiency of 85% or vyond then that means that there could be a maxium draw of 63.75 watts or more of those 75 watts of the external power supply of the wii u, current ports only draw abut 33 watts, even by considering the 4 usb 2.0 ports(2.5 watts each one) and the sdhc port(0.73 watts or bit more) then thats means that wii u could draw as much as 53 watts or a bit more for agmes and yea sicne the ports use 33 watts i already ccounted the dvd drive and other components that are on load

so 53 watts-33 watts means like 20 watts that port games dont use, the cpu obviously wont draw to much, just look at the 476fp which only draws like 1.6 watts at 1,6ghz per core, the main ram also doesnt use to much energy, i have found benchmarks of less than 2 watts for ddr3 and edram is just some few miliwats. Just considering that wii u gpu could draw like 15 watts of those 20 and the rest goes for the rest of the components, thats still plenty. e6760 has a performance of 16.5 gigaflop per watt., wii u gpu could have an aproximation to that, just do the math and you can see there are still plenty of ggafops that are not currently used in many ports

this is why i say that wii u could be like 450gigaflops or 500 gigaflops

shouldnt come as a surprise, cause developers are not putting to much effort n their ports and the eary dev tools and engines could also be the cause
 
#94
I'm sure they could have eeked more out of the PS3 and 360 versions of those games if more dev time was given to them. In the end, Nintendo screwed up. They bet too much on Mario when they should have seen that the Wii was a fluke. I honestly believe their next system will be out by 2016. But at least Wii U owners are getting quality games.

PlayStation 4 is the future and the future is PlayStation 4


even if develoeprs put more time on the wii u, that doesnt change the fact that is a port and that the other sysem have been around for years and developers are more used to them and also have better dev tools and more optimized engines than in wii u. dont forget those issues, and still wii u ports sometimes are better, that tell that obviously is more powerful, and these issues also tell us why xbox one despite being more modern and powerful doenst run a port like call of duty ghosts byond the 720p or why assesins creed 4 for ps4 isnt 1080p60fps and even was 900p30fps before the patch, and the patch only renders it at 1080p30fps despite ps4 is more than powerful enough to run i at 1080p60fps by the numbers in the paper. you cant say developers didnt put tme on the ps4 version cause they even patched it later, something that doenst happen on wiiu versions
 

Laer_HeiSeiRyuu

Well-Known Member
#95
Much power is still left untapped. A large a portion of that is actually the fault, either directly or indirectly, of Nintendo themselves. The pro-Nintendo devs are only telling half the story and something else Nintendo did wasn't so nice to devs.

Electronic voice: PlayStation

p.s.: Stop while you're ahead, magafenix
Whats the something else?
 
#96
I'm sure they could have eeked more out of the PS3 and 360 versions of those games if more dev time was given to them. In the end, Nintendo screwed up. They bet too much on Mario when they should have seen that the Wii was a fluke. I honestly believe their next system will be out by 2016. But at least Wii U owners are getting quality games.

PlayStation 4 is the future and the future is PlayStation 4

wow, first killzone wants 1920x1080p but 960x1080 at 50fps with a variable framerate that can drop to the 30s, now ifmamous second son has recieved a tremendous downgrade 1080p 30fps wasnt enough, whats next sony?



http://www.youtube.com/watch?v=12N-SgebCKs&feature=player_embedded





what the?

o my god, is this for real?







now ps4 seems a step back of what they are promoting
 

Goodtwin

Well-Known Member
#97
Yes the Wii U's power supply can deliver that much power, but it doesnt mean the Wii U hardware is designed to draw that much power. The original Wii's power supply was capable of delivering way more power than the Wii ever demanded. You always have an oversize power adapter, they never cut it all that close.

Yes, Sony and many other lied about how their games would look. It is funny how they pimped everyone with KZ Shadowfall, its rendering less pixels than a true 720p and in the process convinced everyone that the PS4 is a monster, a true next gen 1080p machine. LOL I guess not, not if you want to push the fidelity. All of a sudden Ryse on X1 seems a little more impressive.

I will be honest, although I dont agree with a lot of Megefenix theories, it has brought to my attention that the tech experts were making far to many assumptions based on how the ports were performing. Developers complained about the CPU, not the GPU, and yet it was still targeted as the reason why ports were running worse on Wii U. It took a lot of reading over at Beyond3D, but thats truly the foundation behind the argument. Its the main reason the assumption moved from 320 SPU's to 160 SPU's. When you factor in just how much developers leveraged the VMX unit on the Xenon and the SPE's in the Cell for graphics processing, its not really a shocker that the Wii U doesnt blow them away with a more modern 352Gflop GPU, the Expresso is a good general purpose CPU for running traditional CPU code, but it cant even come close to matching the SIMD performance of the VMX unit in the Xenon or the SPE's in the Cell. So far, I honestly cant say I have seen a Wii U game that really surpasses games like Killzone 3 and the Last of Us, so I am inclined to believe that the RSX+Cell combo is most likely at least as capable as the Wii U's GPU. Keep in mind, the Cell can manipulate data to perform high level DX effects.
 

Laer_HeiSeiRyuu

Well-Known Member
#98
Yes the Wii U's power supply can deliver that much power, but it doesnt mean the Wii U hardware is designed to draw that much power. The original Wii's power supply was capable of delivering way more power than the Wii ever demanded. You always have an oversize power adapter, they never cut it all that close.

Yes, Sony and many other lied about how their games would look. It is funny how they pimped everyone with KZ Shadowfall, its rendering less pixels than a true 720p and in the process convinced everyone that the PS4 is a monster, a true next gen 1080p machine. LOL I guess not, not if you want to push the fidelity. All of a sudden Ryse on X1 seems a little more impressive.

I will be honest, although I dont agree with a lot of Megefenix theories, it has brought to my attention that the tech experts were making far to many assumptions based on how the ports were performing. Developers complained about the CPU, not the GPU, and yet it was still targeted as the reason why ports were running worse on Wii U. It took a lot of reading over at Beyond3D, but thats truly the foundation behind the argument. Its the main reason the assumption moved from 320 SPU's to 160 SPU's. When you factor in just how much developers leveraged the VMX unit on the Xenon and the SPE's in the Cell for graphics processing, its not really a shocker that the Wii U doesnt blow them away with a more modern 352Gflop GPU, the Expresso is a good general purpose CPU for running traditional CPU code, but it cant even come close to matching the SIMD performance of the VMX unit in the Xenon or the SPE's in the Cell. So far, I honestly cant say I have seen a Wii U game that really surpasses games like Killzone 3 and the Last of Us, so I am inclined to believe that the RSX+Cell combo is most likely at least as capable as the Wii U's GPU. Keep in mind, the Cell can manipulate data to perform high level DX effects.
Its more of a money and time thing I believe
 
#99
Whats the something else?

Something that happened some time before launch. I don't want to start more speculation on this subject. Let it be for now.
Its more of a money and time thing I believe
Story of Wii U porting by large pubs.
 

Shoulder

Your Resident Beardy Bear
Yes the Wii U's power supply can deliver that much power, but it doesnt mean the Wii U hardware is designed to draw that much power. The original Wii's power supply was capable of delivering way more power than the Wii ever demanded. You always have an oversize power adapter, they never cut it all that close.

Yes, Sony and many other lied about how their games would look. It is funny how they pimped everyone with KZ Shadowfall, its rendering less pixels than a true 720p and in the process convinced everyone that the PS4 is a monster, a true next gen 1080p machine. LOL I guess not, not if you want to push the fidelity. All of a sudden Ryse on X1 seems a little more impressive.

I will be honest, although I dont agree with a lot of Megefenix theories, it has brought to my attention that the tech experts were making far to many assumptions based on how the ports were performing. Developers complained about the CPU, not the GPU, and yet it was still targeted as the reason why ports were running worse on Wii U. It took a lot of reading over at Beyond3D, but thats truly the foundation behind the argument. Its the main reason the assumption moved from 320 SPU's to 160 SPU's. When you factor in just how much developers leveraged the VMX unit on the Xenon and the SPE's in the Cell for graphics processing, its not really a shocker that the Wii U doesnt blow them away with a more modern 352Gflop GPU, the Expresso is a good general purpose CPU for running traditional CPU code, but it cant even come close to matching the SIMD performance of the VMX unit in the Xenon or the SPE's in the Cell. So far, I honestly cant say I have seen a Wii U game that really surpasses games like Killzone 3 and the Last of Us, so I am inclined to believe that the RSX+Cell combo is most likely at least as capable as the Wii U's GPU. Keep in mind, the Cell can manipulate data to perform high level DX effects.

Both and Cell and Xenon were powerhouses when it came to running games, but hardware technlogy has changed a lot in the last few years. More processes can be rendered or outright calculated using the GPU due to General Processing capabilities in modern GPUs, so the role of the CPU has been dwindling slightly, and I think this is why Nintendo went with a more enemic, yet still capable CPU. With the GPU able to do more that the CPU normally would do, it reduces the need for the CPU in the first place, and unfortunately most developers have become so used to designing their engines for systems like the PS3 and 360, so that heavy role of the CPU is prominent. The Wii U, PS4 and X1 all have CPUs that are designed to not have as much of a role in game design because the GPU is able to do a lot more these days.
It would not surprise me if someday the CPU is ousted entirely, and the GPU will handle everything. In fact, some game demos/prototypes have already been designed to work only with the GPU. There should be vids on Youtube about it.
 
Top