• Hey, guest user. Hope you're enjoying NeoGAF! Have you considered registering for an account? Come join us and add your take to the daily discourse.

WiiU "Latte" GPU Die Photo - GPU Feature Set And Power Analysis

Status
Not open for further replies.

wsippel

Banned
Yes indeed. I noticed some heavy bias there long ago. I figured that professionals would behave more...well professional. One thing I've certainly noticed is that they are fast to generalize Nintendo products towards the lowest common denominator and close cases on a negative point.

Also, how do people stand on the Wii U GPU being a downscaled 4650/4670? Are people still supporting this claim?
The more I look at it, the more it seems like it's somehow related to the 6xxxD series. VLIW5, that strange V block, 40 ALUs per shader cluster and such...
 

Darryl

Banned
The majority of those beyond3d guys... I take anything they say with a grain of salt. Some of them are obviously very well versed in computer/tech/etc. But many of them are clearly very biased for unknown reasons... every bit as biased as they'd claim Nintendo fanboys are.

i think that any board that has a user-base made up of primarily high-tech enthusiasts would be bias'd against nintendo by default.
 

FLAguy954

Junior Member
I never really checked out b3d before you guys started dumping on it, but the forums there say both the 1MB and 2MB memory pools are locked off to developers, is that correct? Marcan indicated the 1MB pool may have been locked off, but not the 2MB, I haven't read this whole thread yet to see where that idea is coming from.

http://forum.beyond3d.com/showthread.php?t=60501&page=186

It would be a minor bummer if all that fast memory is in there but can only be used for BC, why not give devs access to it? Like I guessed way back, maybe the smaller memory pools are only wired to the parts that emulate the Wii? Otherwise, why make it unusable?

I think if we had more info a case could be made that the other pools of memory we locked/limited in the incomplete skus. Developers may have access to them now (I hope).
 
Looks like Nano Assault Neo just got patched, looks like graphics update. The ship seems to be rounder with more detail. Maybe you guys can notice things I can't see, but I was wondering if its just polygon increase with high resolution bump mapping or parallax mapping, maybe even tessellation.
 

krizzx

Junior Member
Looks like Nano Assault Neo just got patched, looks like graphics update. The ship seems to be rounder with more detail. Maybe you guys can notice things I can't see, but I was wondering if its just polygon increase with high resolution bump mapping or parallax mapping, maybe even tessellation.

Sounds like tesselation if what you are saying is true. That is generally what Tesselation patches do.

I noticed when I was watching a tesselation demo of S.T.A.L.K.E.R Call of Pripyat.

http://www.pcgameshardware.com/aid,...oP-Dirt-2-Unigine-and-Alien-vs-Predator/News/

This shows it well.
 

wsippel

Banned
I think if we had more info a case could be made that the other pools of memory we locked/limited in the incomplete skus. Developers may have access to them now (I hope).
Actually, if Marcan isn't talking out of his ass, and I don't think he is, there's a much more fundamental issue: Developers have no fucking clue how Latte even works to begin with. Because there's basically no documentation whatsoever. If you're a "will code for food" guy at some sweatshop studio, you're probably not motivated and certainly don't have the time to explore uncharted territory. All you care about is doing something that's good enough and meets the deadline.
 
Actually, if Marcan isn't talking out of his ass, and I don't think he is, there's a much more fundamental issue: Developers have no fucking clue how Latte even works to begin with. Because there's basically no documentation whatsoever. If you're a "will code for food" guy at some sweatshop studio, you're probably not motivated and certainly don't have the time to explore uncharted territory. All you care about is doing something that's good enough and meets the deadline.

How on Earth can this happen? I mean, I know it's fashionable to go "LOLtendo", but how can you push dev kits out with no documentation on the functionality of the GPU? Is it a language issue - the documentation may exist, but this early in the console's lifecycle it's still primarily documented in Japanese - or an attempt to preserve a "home-team" advantage for Nintendo?

EDIT:

Or is it just a (misguided) belief that the thing is documented well enough (in whatever form it may actually be documented) and/or simple enough to work with for the basics of what devs want to do?
 

AzaK

Member
Actually, if Marcan isn't talking out of his ass, and I don't think he is, there's a much more fundamental issue: Developers have no fucking clue how Latte even works to begin with. Because there's basically no documentation whatsoever. If you're a "will code for food" guy at some sweatshop studio, you're probably not motivated and certainly don't have the time to explore uncharted territory. All you care about is doing something that's good enough and meets the deadline.

If this is true, it's a terrible way to work, especially with developers who want to know that stuff to maximise potential.
 

prag16

Banned
Everyone's biased. It's what happens when you get overly invested in things like this.

I don't disagree. I'll admit that I'm more likely to try to spin things positively because I want the Wii U to succeed (though I'm not insane about it; I'm mostly reasonable.. usually).

The problem with the B3D guys (and a handful here) is that they REALLY think they're completely objective, and will fight to the death defending it even though they're obviously blatant confirmation bias victims. Oh well, life goes on.

Actually, if Marcan isn't talking out of his ass, and I don't think he is, there's a much more fundamental issue: Developers have no fucking clue how Latte even works to begin with. Because there's basically no documentation whatsoever. If you're a "will code for food" guy at some sweatshop studio, you're probably not motivated and certainly don't have the time to explore uncharted territory. All you care about is doing something that's good enough and meets the deadline.

I doubt that's really the case (at least that it's that simple). What do we have to go off of? Some indication that porting isn't as easy as Nintendo claimed? Check. But what else? Eurogamer's claim? Is that it?

Nintendo probably played it a little too close to the vest, but I doubt the extremity of the Eurogamer claim is true. That would be absurd even for Nintendo. I'm sure they weren't completely forthcoming either. The truth is probably somewhere in the middle.

I never really checked out b3d before you guys started dumping on it, but the forums there say both the 1MB and 2MB memory pools are locked off to developers, is that correct? Marcan indicated the 1MB pool may have been locked off, but not the 2MB, I haven't read this whole thread yet to see where that idea is coming from.

http://forum.beyond3d.com/showthread.php?t=60501&page=186

It would be a minor bummer if all that fast memory is in there but can only be used for BC, why not give devs access to it? Like I guessed way back, maybe the smaller memory pools are only wired to the parts that emulate the Wii? Otherwise, why make it unusable?

I've been lurking that thread for awhile. I never saw much to back up that claim. I think it originated with speculation by one of them (function maybe, don't remember) based on various assumptions that to my knowledge we have no backing for yet. It's many pages back from where the thread's at now I think. I'll look for it later if I remember.
 
I think I'm agreeing with you. =P It just need to be emphasized that once hardware is significantly changed instead extended ensuring compatibility is one hell to ensure. And Nintendo has a long line of public backward compatibility with its portable systems as well as endless internal revision of boards and chips for all of there systems (e.g. there are at least three internal revisions of the SNES, the first had the sound unit as a separate daughter board, which later was replace by a couple consolidated chips on the mainboard, then further consolidated into one all-including chip). And Wii U of course doesn't officially support GC games, it doesn't have the necessary controller ports and memory card interfaces anymore. Still, using homebrew GC code starts just fine on Wii U, meaning that likely even the assumingly GC specific logic in the metal was kept for BC just in case some Wii games made use of it.

Sorry I meant home console BC specifically. See when I see that from Shiota I see them doing exactly that with Wii components and putting forth the effort to ensure that since they had IBM/AMD engineers that were familiar with Wii. I don't see Nintendo increasing the production cost when it can be avoided as mentioned by adjusting certain parts.

Brazos:

jeepQfS.png


Similar enough I think. Though the block in Llano looks like an even closer match.

Honestly I was thinking of that one being more like Block I. And on Llano I think I see a block similar to I to the left of the upper row of SIMD cores.

The more I look at it, the more it seems like it's somehow related to the 6xxxD series. VLIW5, that strange V block, 40 ALUs per shader cluster and such...

Same thing I had been thinking for a little while now as well. I had been looking up 6530D though it seems to be 6550D with a disabled SIMD and lower clock. Also on Llano I see a block to the right of the top SIMD cores beside the I/O that looks like W1/2.
 
Actually, if Marcan isn't talking out of his ass, and I don't think he is, there's a much more fundamental issue: Developers have no fucking clue how Latte even works to begin with. Because there's basically no documentation whatsoever. If you're a "will code for food" guy at some sweatshop studio, you're probably not motivated and certainly don't have the time to explore uncharted territory. All you care about is doing something that's good enough and meets the deadline.

Yeah that seems to be obvious for awhile now.

How on Earth can this happen? I mean, I know it's fashionable to go "LOLtendo", but how can you push dev kits out with no documentation on the functionality of the GPU? Is it a language issue - the documentation may exist, but this early in the console's lifecycle it's still primarily documented in Japanese - or an attempt to preserve a "home-team" advantage for Nintendo?

EDIT:

Or is it just a (misguided) belief that the thing is documented well enough (in whatever form it may actually be documented) and/or simple enough to work with for the basics of what devs want to do?

If this is true, it's a terrible way to work, especially with developers who want to know that stuff to maximise potential.

http://www.neogaf.com/forum/showpost.php?p=47540962&postcount=2039

See the end of my post.
 
Actually, if Marcan isn't talking out of his ass, and I don't think he is, there's a much more fundamental issue: Developers have no fucking clue how Latte even works to begin with. Because there's basically no documentation whatsoever. If you're a "will code for food" guy at some sweatshop studio, you're probably not motivated and certainly don't have the time to explore uncharted territory. All you care about is doing something that's good enough and meets the deadline.
Where and when did Marcan implied this? I guess I missed it.
 

tipoo

Banned
Héctor Martín ‏@marcan42
@henriok Forget about the Latte, that's Nintendo internal stuff. I'm told devs get the Espresso manual but it's severely cut down.

https://twitter.com/marcan42/status/300377763649576960


Wait, so developers get a (cut down) manual for the CPU but not the GPU? What?

I wonder where Nintendo falls on the developer friendly spectrum. Microsoft has bar none the best dev tools available, and the PS3 had a tonne of problems like them not even shipping the dev kits with a GPU debugger, but apparently that gap closed after Sony bought some dev tool company in 2005. I know little about Nintendos case.

How are their dev tools and debuggers, anyone know? Did they have both a CPU and GPU debugger for the Wii, and any info on that for the U? Do they use Microsofts Visual Studio like PS3 developers can choose to and 360 devs usually use? By far the best IDE IMHO.
 

sfried

Member
I hope nintendo can remedy this situation the same way they did for the 3DS. The handheld suffered from the same problems with the lack of dev kits, although documentation might be an entirely different matter.
 
It doesn't make sense for Nintendo to withhold documentation now... Why on earth would they?

If it's true, Nintendo needs to replace the man running partner relationship, the person is a paranoid fool
 

Popstar

Member
I wonder where Nintendo falls on the developer friendly spectrum. Microsoft has bar none the best dev tools available, and the PS3 had a tonne of problems like them not even shipping the dev kits with a GPU debugger, but apparently that gap closed after Sony bought some dev tool company in 2005. I know little about Nintendos case.
Sony bought SN Systems. On the PS2 you had the option of that or CodeWarrior. Nintendo used to provide CodeWarrior for DS/Wii but has switched to Green Hills MULTI.
 
Hey, I'm having a tough time finding a Brazos die shot. Mind posting a link?

Here's the one I've been using.

http://images.ht4u.net/reviews/2011/amd_zacate_e350_review/amd_zacate_dual_core_die_shot.jpg

Brazos also has a block similar to W1/2 just above the SIMD cores. It's interesting Latte has two of these while Brazos and Llano only have one.

Well I guess they couldn't make docs with all the time they were spending making tonnes of great games during the end of the Wii's lif......oh wait.

LOL. I'm going to try and give them the benefit of the doubt and that they are working on building up everything necessary for development on Wii U. If they really weren't putting forth the effort or even being "stingy", then they have no right to say they want 3rd parties developing on Wii U.
 

z0m3le

Banned
I imagine that at least some of the reason that functions are going undocumented is because the SDK isn't ready to implement some of this stuff... You have to imagine that unlike Microsoft who has been developing DX and knew exactly what they were doing with Xenos, Nintendo is figuring out how best to use the hardware as it goes, this is why stuff like HTML5 (for development) isn't supported yet, but will be shortly (with GDC).

Nintendo is going to be about 6 months late to their own party with the Wii U, and that is entirely Nintendo's fault, will that hurt the console in the long run? absolutely, but it should be able to recover at least from the major wounds inside the next 2 years, since XB3 and PS4 adoption likely won't be like the Wii's either.

From the developers comments I've read and from the few insiders I've talked to, Nintendo just has growing pains moving into the Wii U, they seemed to be aware of it too, which is why they launched what they did, but their delays to other software and their complete failure in marketing the Wii U is extremely clear to be their biggest problem.

I think a lot of this will be fixed at GDC and the majority of the rest will be fixed at E3, is it too late? I really doubt that is the case after seeing 3DS recover, the big difference there of course is 3DS is a handheld so Japan will buy it in large quantities and that certainly repaired that system, this is going to be a different matter. I expect adoption to be slower, but in line with what we saw for 360/PS3. This is almost entirely on Nintendo's back since for the next year, expect 3rd parties to largely ignore the Wii U, subject to change only if XB3 and PS4 are adopted even slower.
 
Block S1/2 also seems to be in Llano, but with more memory in Latte (bottom right of GPU section in Llano). I wonder what's the purpose of what seems to be duplicate blocks as opposed to singular blocks in the PC GPUs.
 
And in certain instances doubled.

Ignoring N obviously and going back to the notion that J are TMUs, so far I've seen what I would consider to be I, S, V, and W.

Hmm. Interesting to note that both Brazo and Llano are dx11 GPUs. Can these blocks include the customizations/additions that Li Mu Bai was referring to?
 

efyu_lemonardo

May I have a cookie?
Block S1/2 also seems to be in Llano, but with more memory in Latte (bottom right of GPU section in Llano). I wonder what's the purpose of what seems to be duplicate blocks as opposed to singular blocks in the PC GPUs.

is it possible some of these duplicates can be explained by the need to support two screens?
perhaps each has its own scaler and perhaps other dedicated logic as well?

Also, might as well ask a monumentally noobish question while I'm at it, and get it out of the way :p
All the empty space we're seeing in between the SRAM on each block, that's due to the process used to photograph the chip? In reality these areas are occupied by a layer of connections that has been removed. Is that accurate at all?
So more empty space would mean more connections?
 

Donnie

Member
I never really checked out b3d before you guys started dumping on it, but the forums there say both the 1MB and 2MB memory pools are locked off to developers, is that correct? Marcan indicated the 1MB pool may have been locked off, but not the 2MB, I haven't read this whole thread yet to see where that idea is coming from.

http://forum.beyond3d.com/showthread.php?t=60501&page=186

It would be a minor bummer if all that fast memory is in there but can only be used for BC, why not give devs access to it? Like I guessed way back, maybe the smaller memory pools are only wired to the parts that emulate the Wii? Otherwise, why make it unusable?

I don't know if its true that these memory pools are locked away from developer control in WiiU mode, at the moment it seems to be little more than theory. But if they are I'm sure they'll be using them for something, maybe just caches of some kind. Often caches are locked away from developer control after all. I definitely can't see them using so much die space for something as universally useful as fast memory and then simply leaving it dormant in WiiU mode.
 

z0m3le

Banned
is it possible some of these duplicates can be explained by the need to support two screens?
perhaps each has its own scaler and perhaps other dedicated logic as well?

Also, might as well ask a monumentally noobish question while I'm at it, and get it out of the way :p
All the empty space we're seeing in between the SRAM on each block, that's due to the process used to photograph the chip? In reality these areas are occupied by a layer of connections that has been removed. Is that accurate at all?
So more empty space would mean more connections?

Llano supports 3 screens (also the same as Wii U)
 

THE:MILKMAN

Member
Honest question: how are developers supposed to write WiiU games without proper GPU documentation?!

I don't know but it can't be easy if true. I remember in the Wii U specs thread I stupidly suggested that maybe third party devs didn't have complete docs (specifically about the eDRAM) after Ideaman was surprised some big improvements in a game didn't materialise.

I was rightly shot down. Now it could be worse than even that, if true.
 

Turrican3

Member
So developers only have a rough - should I say indirect - understanding of the inner workings of the GPU through API calls?

( I just don't understand if there's detailed API documentation missing as well but... I don't know :-\ )
 

seanoff

Member
Nintendo redefining lemon engineering.

I can't see the point of hiding the GPU from the devs. can you imagine the groaning when the people are told they're on a Wii U projet. wonder if it pays more to work on an undocumented system.
 

z0m3le

Banned
Nintendo redefining lemon engineering.

I can't see the point of hiding the GPU from the devs. can you imagine the groaning when the people are told they're on a Wii U projet. wonder if it pays more to work on an undocumented system.

Considering the devs we have in here knowing stuff and feeding us information all this time, I don't think it is quite as undocumented as some are thinking... I think it is more that the SDK is being updated with new functions of the GPU as they best write it to their APIs, PS3 had similar problems early on, and I think with Nintendo moving to a new platform, they just are starting to completely understand it themselves.

I would hope though that the update to the SDK developers should get next month, would open up the platform a bit more. I just think people are running with scissors a bit too much in here.
 
Well, have we heard serious complaints from developers? Maybe the debugging tools are good enough, so the presumed lack of GPU documentation is not a huge issue.
 

CrunchyB

Member
Honest question: how are developers supposed to write WiiU games without proper GPU documentation?!

In the N64 days third-party developers didn't have the complete access to the machine. I thought Nintendo had changed since then, but perhaps they're still withholding some details of the system. You can develop games with just some self-describing API's, maybe some examples and little else.

It's not as unusual as it sounds. Software like DirectX and OpenGL also abstracts lots of stuff, as does an OS like Windows. One of the reasons PC performance tends to lag behind in efficiency. Doesn't mean you can't design good games, but it can be frustrating.
 
Well, have we heard serious complaints from developers? Maybe the debugging tools are good enough, so the presumed lack of GPU documentation is not a huge issue.
The GPU probably has enough raw power to run most 360/PS3 games with little optimization, but the lack of documentation could explain why weird problems involving the GPU (like no snow in that Tekken stage) consistently shows up in games, and why most dev teams can't push the system beyond a certain point.
 

seanoff

Member
Well, have we heard serious complaints from developers? Maybe the debugging tools are good enough, so the presumed lack of GPU documentation is not a huge issue.

Henrik Wannheden ‏@henriok
@marcan42 How hard would it be to get the CPU manual for Latte and Espresso from some developer?

Héctor Martín ‏@marcan42
@henriok Forget about the Latte, that's Nintendo internal stuff. I'm told devs get the Espresso manual but it's severely cut down.


The answer is fairly straightforward - leaks tend to derive from development kit and SDK documentation and, as we understand it, this crucial information simply wasn't available in Nintendo's papers, with developers essentially left to their own devices to figure out the performance level of the hardware. http://www.eurogamer.net/articles/df-hardware-wii-u-graphics-power-finally-revealed
 

blu

Wants the largest console games publisher to avoid Nintendo's platforms.
Henrik Wannheden ‏@henriok
@marcan42 How hard would it be to get the CPU manual for Latte and Espresso from some developer?

Héctor Martín ‏@marcan42
@henriok Forget about the Latte, that's Nintendo internal stuff. I'm told devs get the Espresso manual but it's severely cut down.


The answer is fairly straightforward - leaks tend to derive from development kit and SDK documentation and, as we understand it, this crucial information simply wasn't available in Nintendo's papers, with developers essentially left to their own devices to figure out the performance level of the hardware. http://www.eurogamer.net/articles/df-hardware-wii-u-graphics-power-finally-revealed
Generally speaking, while not submitting full documentation (incl performance meterics) to developers is not the norm, even if devs were supplied with the entire thinkable documentation, they are still expected to run their own performance metrics on the new hw. Taking performance figures from the documentation on face value is a no-no - documentation cannot, and does not, cover all possible use cases which could stem from the documented topics, so as a rule docs cover the hypothetical maximums, and a few practical cases (if that much), but that's about it.

The one problem I see with developers left entirely on their own device wrt performance is that they can fall victim to 'false negtives' - cases where their internal benchmarks indicate the hw does not reach certain performance levels, but its actually a faulty benchmark. That's why theoretical maximas are still useful - they give an idea how much far from the hypothetical max performance your particular testcase yields, as well as that you cannot hope to hit results above the max quoted levels. But internal benchmarks cannot be skipped.
 

prag16

Banned
Considering the devs we have in here knowing stuff and feeding us information all this time, I don't think it is quite as undocumented as some are thinking... I think it is more that the SDK is being updated with new functions of the GPU as they best write it to their APIs, PS3 had similar problems early on, and I think with Nintendo moving to a new platform, they just are starting to completely understand it themselves.

I would hope though that the update to the SDK developers should get next month, would open up the platform a bit more. I just think people are running with scissors a bit too much in here.

This. There's no way it's as undocumented as some are claiming. That would be insane even for Nintendo. All the talk seems to originate from Marcan and Eurogamer, and neither cite a real source (maybe eachother? lol...)

But I don't doubt they're playing some things closer to their vest than they should be, and/or are behind in some areas.
 
This. There's no way it's as undocumented as some are claiming. That would be insane even for Nintendo. All the talk seems to originate from Marcan and Eurogamer, and neither cite a real source (maybe eachother? lol...)

But I don't doubt they're playing some things closer to their vest than they should be, and/or are behind in some areas.
AFAIK, there is documentation for at least the general feature-set of the GPU. They are not that elaborate, though, considering that the info giving about features like tesellation is still a bit vague to determine the orgin of the unit.
 
Status
Not open for further replies.
Top Bottom