It comes down to do you believe in magic? BG preach the magic or special sauce that people just loved. Nintendo magic or whatever you want to call it.
WiiU "Latte" GPU Die Photo - GPU Feature Set And Power Analysis
- Thread starter Thraktor
- Start date
- Status
It comes down to do you believe in magic? BG preach the magic or special sauce that people just loved. Nintendo magic or whatever you want to call it.
Fourth Storm
Member
Seems to me they got it working with the hardware they already had designed for two outputs in mind. They likely use some type of interleaving of the two images and send it to the Broadcom SoC via one video out. Regardless, if they modified Latte itself for dual Gamepad support, we should be seeing a triplet block somewhere, which we don't see.
Has we even seen 2 gamepad support yet? You can not even buy another controller at this point.
bgassassin
Member
If you're going to bash someone at least do it with facts.
I left because I'm focused on some projects to make me money. Going back and forth on consoles doesn't make me money.
I still don't see how that works. When did frame rates become set in stone? Shouldn't the FPS be determined by how many resources you are using.
Saying that is can only do it at 30fps would mean that there is a hard limit on frame rate that make available resources meaningless. I know it was taken from a quote by Nintendo, but it still just goes against all of my knowledge as programmer of resource management. Maybe the context people are using it in is wrong like with HD on the Wii. Could he simply mean in a normal gaming scenario? ie. a game that runs at 720 60 FPS would be dropped to 30 since the signal is dived. I was under the impression that running an image on the gamepad was not too different than doing split screen multiplayer in a normal game.
Can someone explain this to me?
It has long since been confirmed that it can(I think even before launch). There is no point in begging this.
frankie_baby
Member
no not yet, we have seen a shot of dev tools (unity?) showing the output options for multiple gamepads
Fourth Storm
Member
The limit is not so much framerate as the Hz. Which is why it's obvious that they've jury rigged it.
IDK about that, marcan said tegra3 was a more capable processor than wii u's and that is a phone cpu. But I don't want to derail with cpu talk.
frankie_baby
Member
jury rigged the broadcast yes, doesn't necessarily mean though they've jury rigged the video output though
But then it would still be resource dependent in the end, and thus still possible to achieve 60 FPS across all screens.
The only way I can see this being possible as its being taken is if there is an absolute limit in the chip responsible for sending the video signal to the gamepad(as in it ws designed for consistent 60 FPS regardless of circumstance), in which case, only the pad would be limited and the TV can still run at any given frame rate affordable by the resources.
frankie_baby
Member
as i said i was talking about general purpose code not floating point, an area (general)where espresso performs notably better than xennon
frankie_baby
Member
the limit comes from the wifi broadcast signal to the pad(s)
Espresso handles floating points better? That is new info to me.
frankie_baby
Member
no general
bgassassin
Member
What Fourth is saying is true. It's been awhile, but we did learn that while Wii U could output to multiple controllers the framerate would be split among the controllers.
I'm aware of all of that, but that is not what confuses me. The "30FPS" is what is confusing me. Why would it be limited to that? Why could you not design a game to target 120 FPS did split that and get 60 FPS for both? Why is it specifically 30 FPS?
Schnozberry
Member
Do we know what Llano chip this is? Or are they all the same, just with clock changes and cores disabled? The Llano GPU's have varying core configs from 160:8:4 to 400:20:8.
just in case you misinterpreted: the pads are split to 30fps each, tv still runs at whatever it wants. theres no limitation applied there.
If you're going to bash someone at least do it with facts.
I left because I'm focused on some projects to make me money. Going back and forth on consoles doesn't make me money.
Damn we said his name three times!! lol
frankie_baby
Member
imagine a game runs at 40fps, the wii u still outputs a 60hz to the pad (or the tv), if 2 pads are used it would output just 30hz to each pad
bgassassin
Member
That wouldn't matter because the stream itself is limited.
The picture is of the latter. I did not originally intend on posting or else I would have saved Azak the trouble, but I annotated that same die shot with my take.
http://www.neogaf.com/forum/showpost.php?p=57705258&postcount=4770
Saint Gregory
Member
Pardon my ignorance on this but wouldn't both pads be receiving the same image for that to be true? I assumed that with multiple pads each pad would be capable of displaying a unique vantage point of the game. How would that be achieved without discrete video outputs?
bgassassin
Member
All I can do is point to where we learned it from.
http://www.neogaf.com/forum/showthread.php?t=477035
Ah, I see. This is what I was asking from the beginning. I wanted to know whether or not there was a hard limit. A 60 hz limit makes sense in that case. I wonder if its possible to raise it though.
Fourth Storm
Member
Hey bg, sorry you had to be dragged into this. haha. I am getting ready to go back to school myself, so I should probably be gearing up for that instead of forum back and forth.
Anyway, I think that if the bottleneck in Gamepad support was strictly in bandwidth, and hence the Broadcom chip, that it would be easier to switch that out rather than modify the GPU config. I believe this for the same reason that RAM is one of things we see changed up to the last moment. The GPU design was likely set prior to the decision to support 2 Gamepads.
Good question. I don't know, really, but that one has the 400:20:8 config regardless of whether some cores have been disabled (well, all cores have been disabled since the chip was sacrificed for photos.
)bgassassin
Member
Hey bg, sorry you had to be dragged into this. haha. I am getting ready to go back to school myself, so I should probably be gearing up for that instead of forum back and forth.
Anyway, I think that if the bottleneck in Gamepad support was strictly in bandwidth, and hence the Broadcom chip, that it would be easier to switch that out rather than modify the GPU config. I believe this for the same reason that RAM is one of things we see changed up to the last moment. The GPU design was likely set prior to the decision to support 2 Gamepads.
It makes getting things done easier that's for sure. Plus my spare time goes to gaming. Beat AC1 recently and am now playing AC2.
And I agree that the design had to have been set on one and likely too early. Nintendo isn't just cost conscious, but at times cost paranoid. I think the paranoia won out in this case when they realized how much a controller would most likely cost at retail and didn't let consumers decide if it was too much to handle.
Schnozberry
Member
Good question. I don't know, really, but that one has the 400:20:8 config regardless of whether some cores have been disabled (well, all cores have been disabled since the chip was sacrificed for photos.
So it really boils down to densities then. Staring at these die shots to compare them can make you go cross eyed, but it seems like either 160:8:8 or 320:16:8 are the most likely configurations. It just depends on whether or not our naked eye perceptions are accurate.
Saint Gregory
Member
Ah OK, I didn't realize that more info hadn't been released about the feature yet. I supposed that they could be rendering scenes separately and then condensing them into a single image that the pads then sort into even and odd images. That sounds incredibly messy but if the support wasn't planned from the start I'm not sure how else it could be done unless the pads only get cloned imagery.
I've been reading the thread again after the latest strange overclock rumor and it's been very entertaining. As much as I'd love to discount the constant low end speculators I do remember having these same debates six years ago with the Wii and in the end the low end folks were right, things never got better for that platform visually.
At the same time the GameCube should not have been able to output the visuals it did with the specs it had on paper. The Xbox and PS2 specs ran rings around it theoretically but yet it kept up. So is the Wii U more Wii or is it more GC? Hopefully that will get answered in the next couple of weeks
Ah OK, I didn't realize that more info hadn't been released about the feature yet. I supposed that they could be rendering scenes separately and then condensing them into a single image that the pads then sort into even and odd images. That sounds incredibly messy but if the support wasn't planned from the start I'm not sure how else it could be done unless the pads only get cloned imagery.
I've been reading the thread again after the latest strange overclock rumor and it's been very entertaining. As much as I'd love to discount the constant low end speculators I do remember having these same debates six years ago with the Wii and in the end the low end folks were right, things never got better for that platform visually.
At the same time the GameCube should not have been able to output the visuals it did with the specs it had on paper. The Xbox and PS2 specs ran rings around it theoretically but yet it kept up. So is the Wii U more Wii or is it more GC? Hopefully that will get answered in the next couple of weeks
Let us not confuse what was done with what could be done. Honestly, I don't think we ever saw any games on Wii that exceeded the best on the GC. We never saw the max it can do in a Resistance vs. Resistance 3 sort of since. The only chance we had of seeing the max of the Wii was Lair from Factor 5(they said it exceeded their PS3 version) but they died, so it never came about.
Also, in real world results, the GC didn't just keep up, it ran past. Thing with the GC was that people misinterpreted the numbers. They compared real world numbers to peak maxes.
As for the Wii U, we still have Bayonetta 2, and X too look forward to for analysis. Iwata also alluded to putting heavy emphasis on graphics with the next Zelda for the Wii U.
bgassassin
Member
Anyway let's talk about my dual graphics engine idea. The amount of duplicate blocks works out. Fourth and I see the GPU pipeline from opposite perspectives.
Yeah I don't remember anything being mentioned after that came out.
And yeah we can speculate all we want, but at the end of the day it's on Nintendo to show what Wii U is capable of. I tried to give Nintendo the benefit of the doubt in their being ready for and HD transition, but I was wrong. And when they already have things working against them, getting their dev environment together so late doesn't help.
Ah OK, I didn't realize that more info hadn't been released about the feature yet. I supposed that they could be rendering scenes separately and then condensing them into a single image that the pads then sort into even and odd images. That sounds incredibly messy but if the support wasn't planned from the start I'm not sure how else it could be done unless the pads only get cloned imagery.
I've been reading the thread again after the latest strange overclock rumor and it's been very entertaining. As much as I'd love to discount the constant low end speculators I do remember having these same debates six years ago with the Wii and in the end the low end folks were right, things never got better for that platform visually.
At the same time the GameCube should not have been able to output the visuals it did with the specs it had on paper. The Xbox and PS2 specs ran rings around it theoretically but yet it kept up. So is the Wii U more Wii or is it more GC? Hopefully that will get answered in the next couple of weeks
Yeah I don't remember anything being mentioned after that came out.
And yeah we can speculate all we want, but at the end of the day it's on Nintendo to show what Wii U is capable of. I tried to give Nintendo the benefit of the doubt in their being ready for and HD transition, but I was wrong. And when they already have things working against them, getting their dev environment together so late doesn't help.
Do you have a link to that? I find that just impossible.
Guess you are talking about this?
That doesnt mean anything about the way it looks.
http://www.joystiq.com/2008/02/12/factor-5-wii-engine-does-everything-the-ps3-did-and-then-some/
I posted it a few times in this thread and not that far back. Go back to the around the time we were discussing normal mapping on the Wii. It should be about 10-15 pages back.
The video that showed off the Wii engine certainly put up a good argument, and being it that Rebel Strike on the GC pushed more polygon and effects on screen at once than other game game in the 6th gen, I'm inclined to give them the benefit of the doubt.
http://www.youtube.com/watch?v=GuiS4ji2Bng
I'd think they know more about their own games and their own tech than I or anyone else.
Wishmaster92
Member
If you're going to bash someone at least do it with facts.
I left because I'm focused on some projects to make me money. Going back and forth on consoles doesn't make me money.
wooo hes back! Now where is ideaman and burnt pork..
Wow that looked terrible. Man SD looks so bad now a days.
Looks like an analog recording (i.e. literal tape demo).
Fourth Storm
Member
I agree with bgassassin in that I think we should be able to identify most blocks on Latte using the Radeon architecture as a reference. However, I see things quite differently than his interpretation. Here's how I'd place things.
Command Processor: Block C
Setup Engine: I'd have block G as the Vertex Assembler with the tesselator included within. H would be the Geometry Assembler, L the Rasterizer and K the Hierarchichal Z. I may have mixed up a few of these blocks, but I generally see this area as the "front end" of the graphics pipeline.
Instruction Cache and Constant Cache: Block D. I am pretty confident in these. The Constant Cache (which is helpful in GPGPU functionality) can be pretty significant in recent chips (up to 128kB) so I see that as the SRAM pool on the right of this block.
Thread Dispatch: Block I. It looks alot like the ones in Tahiti. Perhaps smaller than the one on RV770, but then again, it's dealing with alot less threads.
Interpolators: J Blocks. 32 in total distributed in the 4 blocks. If Latte is based on R700 series, you can't leave these out. Not as flexible as having interpolation done by shaders, but should decrease their load compared to DX11 chips by having fixed silicon.
Local Data Shares: Block M. 16 kB for each of the 2 SIMD cores.
SIMD cores: N Blocks. These have been covered pretty well, so no explanation should be needed.
Shader Export: Block P. Alot of SRAM on there for buffers and whatnot I would think.
Video Output Heads: Q Blocks. I just explained why I concluded this a few posts back.
Global Data Share: Block V. 64 kB. Similar to block found on Llano in a similar position relative to shaders, TMUs, etc. Upgraded from standard R700 for better compute.
TMUs: T blocks. Again, I've already explained why I think this, but it also makes sense for them to be close to the DDR3 I/O.
L1 caches: S blocks. 8 kB each.
L2 caches: U blocks. 32(?) kB each. Seem to resemble the L2 on RV770 to an extent. I'm only counting the long SRAM banks as actual storage space. There should be a fair amount of other logic/SRAM for cache functionality, so it's hard to say how much is for actual texture data.
ROPs: W blocks: Seem to look like the ROPs on RV770 and their positioning next to L2 and DDR3 I/O makes sense.
North Bridge: Block B? Just kinda guessing with this one but it would be logical for it to be around the CPU interface.
South Bridge/DSP: Block X. Pretty obvious. Marcan helped us with this one.
ARM926 core: Block Y. Ditto. Thanks to Marcan.
Media Decode: Block F. A similar block is also found on Llano. Block E may be related to this or related to the caches in Block D.
Blocks O and R are kind of a tossup, but they may have something to do with moving data to and from the 32 MB eDRAM. Call them "move engines" or whatever - who knows how they work really or how efficient they are. Block A seems to be related to the 1 MB eTC for Wii mode and contains the cache tags and possibly allows interaction with the CPU.
As you can see,this covers all blocks and is pretty standard stuff. Going by this, I don't think we need to draw up imaginative theories to explain Latte. It's a well designed chip that meets Nintendo's needs. Whether we agree with their use of available technology is another story.
Command Processor: Block C
Setup Engine: I'd have block G as the Vertex Assembler with the tesselator included within. H would be the Geometry Assembler, L the Rasterizer and K the Hierarchichal Z. I may have mixed up a few of these blocks, but I generally see this area as the "front end" of the graphics pipeline.
Instruction Cache and Constant Cache: Block D. I am pretty confident in these. The Constant Cache (which is helpful in GPGPU functionality) can be pretty significant in recent chips (up to 128kB) so I see that as the SRAM pool on the right of this block.
Thread Dispatch: Block I. It looks alot like the ones in Tahiti. Perhaps smaller than the one on RV770, but then again, it's dealing with alot less threads.
Interpolators: J Blocks. 32 in total distributed in the 4 blocks. If Latte is based on R700 series, you can't leave these out. Not as flexible as having interpolation done by shaders, but should decrease their load compared to DX11 chips by having fixed silicon.
Local Data Shares: Block M. 16 kB for each of the 2 SIMD cores.
SIMD cores: N Blocks. These have been covered pretty well, so no explanation should be needed.
Shader Export: Block P. Alot of SRAM on there for buffers and whatnot I would think.
Video Output Heads: Q Blocks. I just explained why I concluded this a few posts back.
Global Data Share: Block V. 64 kB. Similar to block found on Llano in a similar position relative to shaders, TMUs, etc. Upgraded from standard R700 for better compute.
TMUs: T blocks. Again, I've already explained why I think this, but it also makes sense for them to be close to the DDR3 I/O.
L1 caches: S blocks. 8 kB each.
L2 caches: U blocks. 32(?) kB each. Seem to resemble the L2 on RV770 to an extent. I'm only counting the long SRAM banks as actual storage space. There should be a fair amount of other logic/SRAM for cache functionality, so it's hard to say how much is for actual texture data.
ROPs: W blocks: Seem to look like the ROPs on RV770 and their positioning next to L2 and DDR3 I/O makes sense.
North Bridge: Block B? Just kinda guessing with this one but it would be logical for it to be around the CPU interface.
South Bridge/DSP: Block X. Pretty obvious. Marcan helped us with this one.
ARM926 core: Block Y. Ditto. Thanks to Marcan.
Media Decode: Block F. A similar block is also found on Llano. Block E may be related to this or related to the caches in Block D.
Blocks O and R are kind of a tossup, but they may have something to do with moving data to and from the 32 MB eDRAM. Call them "move engines" or whatever - who knows how they work really or how efficient they are. Block A seems to be related to the 1 MB eTC for Wii mode and contains the cache tags and possibly allows interaction with the CPU.
As you can see,this covers all blocks and is pretty standard stuff. Going by this, I don't think we need to draw up imaginative theories to explain Latte. It's a well designed chip that meets Nintendo's needs. Whether we agree with their use of available technology is another story.
Saint Gregory
Member
This is retreading ancient history but back when we were having these kind of discussions about the Wii's architecture it was always my belief that something went wrong from an engineering standpoint with the system. This was kind of supported by another poster who uploaded developer support diagrams that indicated the tiny Wii framebuffer was supposed to be primarily used for BC.
The Wii was supposed to have been capable of carving out any part of the main memory to be assigned as a framebuffer which could then have direct access to video output according to the diagram's flow arrows. I believe that's how Factor 5 intended to achieve 720P on the system but no one appears to have ever used that method and I've never seen any other documentation that suggested that this was possible.
Still, it's difficult to understand how the Wii was essentially maxed out as quickly as it was. SMG1/2 were pretty much the high point of the system graphically and were released very early in the Wii's lifespan. Every console prior to the Wii saw gradual improvements over time so in my opinion there was other than hardware strength holding it back from its potential and some miscalculation creating an artificial bottleneck that Nintendo didn't intend seems like a good guess.
There's really no excuse for Nintendo to be this far behind. I assumed that their strategy for last gen was to let others do the heavy lifting of struggling with HD development while they took their time and learned from common mistakes from behind the scenes. From the look of things Nintendo has spent the last several years since they halted Wii development pouring resources into the 3DS instead of taking the steps necessary to make sure that their studios were ready for this launch.
I'm guessing that their thought process was just to get the system out there and sell as many units as they can until they're really ready to focus on the console but that's an awful strategy considering that many (gamers, retailers, developers) may choose to move on to other things rather than wait for them to get their house in order.
bgassassin
Member
^ I can agree with all of that. I guess they must have really underestimated the requirements of a HD console and services, and didn't realize they weren't truly able to handle everything despite seeking help for the online infrastructure. Plus they tend to be so secretive that at times it only hurts themselves.
It's funny that said they wanted to avoid the mistakes they made with 3DS, that they ended up doing the exact same thing, minus a couple of quick 1st party titles.
Unfortunately ALU talk dominated things, but this is what I was hoping my breakdown would do and that's give you guys something to talk about in regards to Latte and to settle my curiosity.
Fourth I think to help prove my case and debate against yours (but primarily to spur discussion), I'll focus on a couple things to save me time. Just getting it out of the way, I think we can safely say the layout is based on AMD's IGP line of GPUs. Because of this I lean more on those GPUs for identifying things, though I can see r700 similarities.
First I will focus on block W. This block was very noticeable in Brazos and Llano. If we are to claim W contains 4 ROPs, then that would mean Llano only has 4 ROPs.
Here are my annotations of those two GPUs again.
One of the main problems I have with J being Interpolators is their size, especially J1.
Not an argument against, but what you list as caches (mainly L1, L2, GDS) seem to have more memory than you list.
It's funny that said they wanted to avoid the mistakes they made with 3DS, that they ended up doing the exact same thing, minus a couple of quick 1st party titles.
Unfortunately ALU talk dominated things, but this is what I was hoping my breakdown would do and that's give you guys something to talk about in regards to Latte and to settle my curiosity.
Fourth I think to help prove my case and debate against yours (but primarily to spur discussion), I'll focus on a couple things to save me time. Just getting it out of the way, I think we can safely say the layout is based on AMD's IGP line of GPUs. Because of this I lean more on those GPUs for identifying things, though I can see r700 similarities.
First I will focus on block W. This block was very noticeable in Brazos and Llano. If we are to claim W contains 4 ROPs, then that would mean Llano only has 4 ROPs.
Here are my annotations of those two GPUs again.
One of the main problems I have with J being Interpolators is their size, especially J1.
Not an argument against, but what you list as caches (mainly L1, L2, GDS) seem to have more memory than you list.
That is easily answered. As I just stated and you referened from Factor 5, it was never maxed out.
There is no question that 99% of the devs on the Wii didn't go in 100%. No one attempted to "push" the hardware. Over half the games look like subpar PS2 games and ran worse. Hardly anyone used normal mapping or bump mapping and no one used its anti-aliasing capabilities. The best looking game were the ones you could play from Gamecube discs aside from a handful a Wii titles. The best looking game was MG2 and Nintendo has never ever "pushed" their hardware. Their aim has always been to be creative as opposed to technical in both their hardware and games.
We know the Wii was capable of really good phsyics because of Elebits and Boom Blocks but those were rarities. We know the Wii was capable of massive use of Normal Mapping thanks to that homebrewer from B3D. We know the Wii was capable of HDR because of the devs of Cursed Mountain. We never quite saw someone go all the way and push the Wii for all it can get under optimal conditions though.
The simplest answer is that we never saw all that the Wii can do and now we probably never will.
I'm sure that the Wii U still has miles to go, though. Even now, they are still optimizing the OS and hardware, so increased performance and subsequently better looking games are guaranteed. Heck, we haven't even seen what its tesselator can do yet. I'll be nice when Shin'en drops some screen form their next Wii U game.
Well, there are still games being made for the Dreamcast and the Wii has long since been blown wide open
But I'm not sure I buy the theory of the Wii being wrongly used in terms of framebuffers. For one, that's one mother of a mistake, for every developer- including Nintendo! - to make. If it was meant to be used differently, they would say so. Two, the Wii was always meant to target 480p, the framebuffer size probably made sense given that. Three, the framebuffer was probably hardware-set, not like a developer can just pick anywhere to put it. It seems like a very very far stretch of a theory.
Well, there are still games being made for the Dreamcast and the Wii has long since been blown wide open
I don't understand your point.
bgassassin
Member
Or tessellators if my hypothesis is correct.
Now that certainly would be interesting to see.
I'm still pinning the Froblins demo in line with the capabilities of the Wii U.
You said we'd probably never see its potential, since its generation is over. But who knows, in 10 years it may have a similar indie game community like the Dreamcast has, and by then the tools may be good enough for indie devs to make games that surpass what big devs did on the Wii.
Saint Gregory
Member
I honestly don't think that the answer is that simple, especially since the 99% of developers includes Nintendo's own first party developers. In a lot of cases 1st party games saw minimal increases in visual quality over their GC predecessors on a system that on paper should have been at least three times more powerful. Something else more complicated had to be at work.
I don't believe that it was a case of the framebuffer not being used as intended but the main memory framebuffer process not working as intended. If that flow diagram was accurate (it could have been a fake for all I know) it was up to the developer to carve out the chunk of memory to be used and set it up to bypass the hardware framebuffer. There's a lot of reasons why this may not have worked as originally engineered but Factor 5 did say that they had an engine running on Wii in 720P somehow. That shouldn't have been in any way possible on the Wii's hardware framebuffer.Well, there are still games being made for the Dreamcast and the Wii has long since been blown wide open
But I'm not sure I buy the theory of the Wii being wrongly used in terms of framebuffers. For one, that's one mother of a mistake, for every developer- including Nintendo! - to make. If it was meant to be used differently, they would say so. Two, the Wii was always meant to target 480p, the framebuffer size probably made sense given that. Three, the framebuffer was probably hardware-set, not like a developer can just pick anywhere to put it. It seems like a very very far stretch of a theory.
Okay, now I see where you were going. Problem is, there were no big devs on the Wii. Two of the biggest pushers of Nintendo hardware died trying to sell themselves to Sony at the start and the other jumped ship to Microsoft during the GC era. That is the main problem I was pointing out. The Wii had few games were made on the scale of PN.03, and the RE Remake. None ever came close to Rebel Strike.
When I saw people praise this as being one of the best looking games on the Wii(both journalists and even Nintendo fans) it made me sick and sad at the same time. I would say it was like looking at an N64 game, but the N64 version looked better.
http://image.gamespotcdn.net/gamespot/images/2010/307/reviews/997757_20101104_screen002.jpg
http://image.gamespotcdn.net/gamespot/images/2010/307/reviews/997757_20101104_screen046.jpg
For me, this is still the best looking set of hand produced on the Wii and wall textures for that matter. http://www.meodia.com/userfiles/image/The Conduit/TheConduit5.jpg If only more devs invested that kind of effort. I'll give High Voltage credit for making the effort that majority of other devs didn't try. They simply lacked the talent to bring it together.
Fourth Storm
Member
Indeed, it works out for Brazos, since that only has 4 ROPs. Llano is tricky because there aren't any two identical blocks with the size/shape/SRAM requirements to be ROPs. What you've labeled as W seems a pretty good candidate though (and looks enough like the RV770 ROPs as well, even though that photo is so fuzzy it's hard to be certain). It might be as happened on the latest 360 processors and the single W block has 8 ROPs on Llano. It is a 32nm chip compared to the others, so perhaps that allowed for it.
There's definitely something extra going on in J1. My theory is that there is extra logic sprinkled throughout many of the blocks which allow them to be used for Wii mode. Hence, fatter shaders and the one oversized J block. I don't know what I would equate the interpolators to on Flipper, though. The texture coordinate generator maybe?
Wishmaster92
Member
Oh my dayum.
Saint Gregory
Member
Isn't one of the few things Nintendo has said specifically about the CPU/GPU is that no silicon is being wasted on Wii mode? In other words there's nothing specifically dedicated to BC that isn't being used in Wii U mode or did I misinterpret that?
- Status