By using this site, you agree to our Privacy Policy and our Terms of Use. Close
jake_the_fake1 said:
megafenix said:
jake_the_fake1 said:
megafenix said:
fatslob-:O said:
megafenix said:
fatslob-:O said:
Darc Requiem said:
drkohler said:
Oh look, it's MisterXMedia all over again. Didn't know there is such a moron in the WiiU camp, too..
And yes, 550MHz*1024bit is 560 gigaBITS/s, NOT gigaBYTES/s....


I thought something was fishy. According to his calculations wouldn't the bandwith of the Wii U's EDRAM be 74GB/s ?

It is but when you have liars like megafenix spreading misinformation to the ill informed this happens ...

 

liers ike youself right?

t official source abput the 256gb/s besides the ones i mentiond?

how about someone from micro itself?

http://www.cis.upenn.edu/~milom/cis501-Fall08/papers/xbox-system.pdf

 

when we have trollers like you this place stink

Like I said, "interconnect bandwidth means jack shit". What part do you not understand ? 

 

bandwidth is important more than you think, if not why would AMD and nvidia increase the internal bandwidth of the gpu  generation?

is imprtant for many things like vertext texture fetches and other things, and i dot say this, its expert people on the topic, like people from nvidia

 

but if you at least read the whole article from gaming blend you will see that he doesnt say this himeself but that consulted people for this

 

want their comments?

here

http://developer.amd.com/wordpress/media/2012/10/Tatarchuk-Tessellation(EG2007).pdf

 

 

Because with every generational of graphics cards both Nvidia and AMD increase the processing capabilities, more processors requires more bandwidth to keep them fed efficiently.

Right now you are saying that the WiiU has over 500GB/s bandwidth, the recently released Titan Black (Nvidias flagship graphics card) has a total bandwidth of 336GB/s, are you proposing that the WiiU is now some how more capable than the Titan Black? If so, how would you explain the Titan's raw graphical capabilities which completely crush the WiiU ability despite the Titans lower bandwidth?

 

 

remember that the edrm on wii u works as a big cache not as big ram

do you even know how much bandwidth the internal parts of even a low end gpu can handle?

 

here

http://developer.amd.com/resources/documentation-articles/articles-whitepapers/opencl-optimization-case-study-fast-fourier-transform-part-ii/

 

and thats only for one local data share, each simd core has a local data share, so, how much bandwidth would you get for a gpu of marely 4 to 5 simd cores?

and we still havent accounted the texture units l1 cache bandwidth or the global dta share bandwidth

 

So the EDram is used as a cache instead, ok so what?

You still haven't explained how this cache could magically add extra performance to an already piss weak GPU, all you've done is remove the bandwidth bottleneck of the system, but now the GPU is the bottleneck.

The GPU could never use the potential of the EDram bandwidth anyways since it's a piss weak GPU, but to say that it can would mean that the WiiU GPU would now be more capable than the Titan Balck. ...and this just isn't reality.


as i said before, the answer is tesselation+displacement

bandwidth is not going to gie you more power, but the store and the speed for achieving render techniques that reuire lots of bandwidth an rapid access

 

tessleation+dispalcement can achieve about 400x more olygons by only trading off about 33fps or 30% performance,  but the trade off still pretty good, of course that since the wii u is not a high end gpu tying to do this at 1080 would prove a challenge, not to mention that starves about half the memory bandwidth

 

here, and is based on a rv770 according to AMD

http://developer.amd.com/wordpress/media/2012/10/WileyAuthoringforTessellation.pdf

"
The first and most obvious benefit of real-time tessellation and 
displacement mapping is the dramatic increase in visual 
quality. Tessellation in conjunction with displacement mapping 
eliminates one of the last hurdles towards achieving cinematic 
quality visuals in games.Film has been using this technique 
for years in order to provide animators with manageable 
meshes to work with during the animation portion of 
development while still providing the highest quality results at 
render time. This technique eliminates polygonal artifacts and 
provides highly detailed, smooth internal and external 
silhouettes.

Another slightly less obvious benefit of this technique is the 
effect that it has on your memory footprint. Essentially, you 
can think of real-time tessellation and displacement mapping 
as an effective form of geometry compression. This technique 
utilizes the same art assets as conventional rendering with the 
only additional storage requirement being the 16 bit 
displacement map. If we take the Froblin character as an 
example we see that the memory footprint for the low 
resolution mesh and 2k x 2k 16 bit displacement map 
requiring about 10 megabytes of video memory. This is 
compared to the 450 megabytes of video memory that would 
be required to render the high resolution Froblin model that 
weighs in at around 15 million triangles. So, for just a 
modest increase in memory footprint, we are able to 
dramatically increase the total polycount and visual detail of 
the render mesh when using this technique.

Another less obvious benefit of this technique is in animation 
quality. Transforming the low resolution mesh is faster than 
attempting to transform the high resolution equivalent. This 
means that we get better animation performance. Also, as we 
just saw in the previous slide, we are storing exponentially 
fewer vertices in video memory. This means that we are able 
to store more data per vertex. What this provides us, for 
example, is the ability to increase skinning quality by being 
able to store more influences per vertex. This would also 
allows us to store a much larger library of morph targets for 
better facial animation, etc

Performanceis yet another benefit of real-time tessellation and displacement mapping.You can see here that when implemented with multipassrendering and vertex compression we are able to render over 400 times as many polygons while only taking a 33 frames per second or 30 percent performance hit when compared to rendering only the corresponding low polygon mesh. That is a pretty good trade off.

"