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...
WiiU "Latte" GPU Die Photo - GPU Feature Set And Power Analysis
- Thread starter Thraktor
- Start date
- Status
Shin Johnpv
Member
NDA's probably mean they can't say anything.
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.
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).
OG_Original Gamer
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.
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.
Cosmonaut X
Member
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.
prag16
Banned
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.
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'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.
bgassassin
Member
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:
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.
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.
bgassassin
Member
Yeah that seems to be obvious for awhile now.
http://www.neogaf.com/forum/showpost.php?p=47540962&postcount=2039
See the end of my post.
Cosmonaut X
Member
The complete absence of detailed documentation leaks for Wii U/Latte vs the info-splooge for Durango/Orbis would strongly suggest that the documentation just isn't there for anyone to leak.
Cheers. Makes sense.
ahah! lol.
edit: I mean lol because it's true and it makes all this stuff quite comical.
lwilliams3
Member
Where and when did Marcan implied this? I guess I missed it.
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.
https://twitter.com/marcan42/status/300377763649576960
Zoramon089
Banned
Cut down from...what devs expect to be there?
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.
Fourth Storm
Member
Brazos:
Similar enough I think. Though the block in Llano looks like an even closer match.
Hey, I'm having a tough time finding a Brazos die shot. Mind posting a link?
DragonSworne
Banned
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
If it's true, Nintendo needs to replace the man running partner relationship, the person is a paranoid fool
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.
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.
bgassassin
Member
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.
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.
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.
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.
bgassassin
Member
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.
OG_Original Gamer
Member
What is Llano specifications?
bgassassin
Member
lwilliams3
Member
So, Latte has blocks that looks like ones from GPU parts from a 2011 AMD Fusion?
bgassassin
Member
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.
lwilliams3
Member
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?
Fourth Storm
Member
Thanks. Man, Brazos looks even weirder than Latte...
efyu_lemonardo
May I have a cookie?
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
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?
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.
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
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)
SpoonyBard
Banned
Using OpenGL/GX2 API. Optimization must require some serious trial and error...
THE:MILKMAN
Member
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.
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.
SpoonyBard
Banned
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.
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.
lwilliams3
Member
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.
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.
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
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.
lwilliams3
Member
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