It basically works like this: PSRAM refreshes on every cycle and has two buffers, one for reads and one for writes. On a read request, the requested bank will be read (while all other banks are refreshed as usual) and also copied to a buffer. If subsequent reads request data from the same bank, they read from the buffer while the corresponding original bank can be refreshed. Writes work similarly. That way, you get the same latencies as with SRAM - in fact, PSRAM is a drop-in replacement for SRAM.
WiiU "Latte" GPU Die Photo - GPU Feature Set And Power Analysis
- Thread starter Thraktor
- Start date
- Status
A
A More Normal Bird
Unconfirmed Member
'Derived from' doesn't rule out customisations. The likelihood that the core tech of things such as the shader cores would be developed from scratch or even radically customised however, is low. Evidence points to a baseline of R700: those chips or something like them were in dev kits, the name popped up repeatedly in rumours and documentation and even now post launch there is talk of DirectX10.1 equivalency. I know you'll respond by bringing up the instances in which DirectX11 was mentioned, but the point is that an R700 derived chip in a closed box environment could easily use an API that exposes parts of the hardware (e.g. tessellation and compute shaders) that were DirectX11 exclusive on PC. If it were derived from a fully DirectX11 compliant chip to begin with, why would 10.1 be mentioned at all? As for Brazos providing the most component matches, I'll quote Fourth Storm:
99%? christ why werent you helping understand all the die parts if you can tell 99%!
Oh my goodness. Now my head hurts.
The entire reason they know is custom built is because nothing about it looks likes any R700. We don't even know what 50%< of the chip is. That was one of the earliest finding in this thread.
I'm done. This is like trying to argue with Jordan. I feel like I'm talking to the air. 99%? Made up information out of of nowhere.
Can someone else take this over? I'm not wasting any more of my time.
Show me where it looks nothing like R700, I would love to know.
OG_Original Gamer
Member
I think what's happened here, is Nintendo purchased and owns the chip. So its based off r700 variants. Any chip is customizable, but there are limitations. In a agreement with AMD, certain components were added. The tessellator can be modified to match what's in a 7000's series GPU. The difference would be in the level of tessellation. You may be limited to 16x, instead of 32x or more. The r700 series didn't have compute units but, Latte have them. They didn't ship with 32MB of eDRAM that can be accessed by both the CPU/GPU. Its request that Nintendo made, similar to the request Sony made like ACE and HUMA. Ideas can come from Nintendo, its up to AMD to see if they can be implemented in hardware.
how about you identify all the blocks for that 99%.... also be handy if you put up the reference die shots as well.
99% is commonly used a term when we know a lot about something, he seems to have at least annotated around a physical 99% though. Shocking that we only know about 50% of the GPU yet the eDRAM and SRAM nearly takes up that much space.
im just being dick-ish like you were to other people (you brought up GCN3 and assumed people assumed it was super powered, and then you assumed it was awful [only after that did people make claims of it being powerful]). Also yeah 99% is a common exaggeration, which isnt really fitting in a technical thread.
Neither is claiming things that are outrageous (100% custom GPU, etc) yet here we are. (not talking about you specifically).
prag16
Banned
Are we looking at the same die shot? If so one of us needs glasses.
Also this.
And this.
lostinblue
Banned
This has been discussed to hell and back before.
Tesselation performance before GCN wasn't horrible; the thing is, it went through various generations/revisions; R5xx and Xenos had the first hardware tesselation unit (well, we could talk truform on R2xx but I'll pass), and yes, it sucked, it didn't support vertex compression so you had to decompress whatever you were pulling (providing it was compressed) and end up with bloated geometry due to the added detail; that... with limited RAM effectively defeated the purpose.
No warranty that would be the case had the console had double the RAM or so. Anywho, tradeoffs were inappropriate.
I'll skip ahead, but if I remember correctly GCN/HD7xxx is considered Gen 3+; HD6xxx were generation 3 and they were still VLIW4/5 (depending on the chip); it's was an DirectX 11/OpenGL 4.1 implementation at that point and thus it had to comply to all the demanded standards; no, they didn't suck.
As for Wii U, we know it fished above R700 on stuff like the Eyefinity implementation, they could have updated the Tesselator or not, anywho, worse case scenario it's a Gen 2 part, at best it's Gen 2+ or even Gen 3; either way it's infinitely more useful than what Xenos had.
Haha, yes they do; and this part is derivative from a "mass" product not originally meant for Nintendo, they surely didn't go out of their way to nuke everything they thought they wouldn't use. Gamecube could output stereoscopic 3D, for instance; SNES could pull 512x512, and only one game used (not a nintendo published one, looked horrible), I could go on.
And in the end, even if they document it, it depends on the developers whether a feature is attractive or not.
MrPresident
Banned
It wasn't 'terrible' but it underperformed next to nvidia's tessellator due to only having a single geometry engine. GCN added a second one in addition to whatever tweaks were made.
It's not the issue that it is on PC, in any case. It's much easier to tailor the amount of subdivisions to three known quantities (the three consoles) than it is for countless different PC configurations running at different clockspeeds and resolutions.
According to old reports, R700 was the first and only GPU with AMD's second generation tessellator. There's very little information about it, but it was supposedly a massive upgrade over their previous tech - it just became obsolete so quickly that it was never used outside of AMD tech demos and was never properly documented. Could be the most amazing shit of all time for all we know, but it simply wasn't DX11 compliant.
frankie_baby
Member
So it could actually be better than their more recent tesselators?
It wouldn't be ancient fixed function tech if it's an EVOLUTION of the TEV Unit. The TEV Unit gave the Wii a nonstandard rendering pipeline making ports a major pain in the arse...but it was in theory a great idea. I'm saying that we know that Nintendo were working closely with engine creators such as Crytek before the console launched.
The advantage of doing this as opposed to adding more shaders would be that things such as HDR would be 'free' and help bridge the gap between Latte and the PS4/One GPU's floppage, and the disadvantage would be that the lack of shaders would mean that new techniques for lighting in the future wouldn't be possible with Latte, it would be stuck with HDR.
Sounds like a decent trade-off to me.
They are only free if you use them otherwise they just cost you extra compute power you could of have and it seems like a lot of people like to do HDR differently theres no 1 way to really nail it down.
frankie_baby
Member
You wouldn't be stuck with HDR, just if you used anything else it would eat into the floppage
MrPresident
Banned
Regarding Shin'en, they're a former demo scene group. Bear in mind that a lot of Nano Assault's assets are procedurally generated and that the game itself will only be ~100mb in size. Procedurally generated content leverages memory much differently to handcrafted content like we expect from games that try to simulate cities with billboards and such.
It can still look beautiful (here's a demo made of 64 kilobytes) but it uses a very different paradigm in terms of leveraging hardware. Texture thrashing over the system bus can be eliminated, for example.
It can still look beautiful (here's a demo made of 64 kilobytes) but it uses a very different paradigm in terms of leveraging hardware. Texture thrashing over the system bus can be eliminated, for example.
Yup, that's what I meant. Sorry, I wasn't too clear about that. Developers would be stuck with HDR because using the limited floppage for anything else would be impractical.
efyu_lemonardo
May I have a cookie?
that demo is NUTS!
MrPresident
Banned
AMD made a tech demo for the R700-series and it's certainly good enough to be usable.
It's nowhere near later architectures though. nVidia's 400-series blew AMD's GPUs out of the water in tessellation at the time and GCN is now roughly on par with nVidia's newer GPUs. It still exists in Wii U and it will be used to improve the image.
Krizzx doesn't make baseless assumptions that have no ground in reality like you are. Anything I state, I can point to a source for. Whether or not I will, however, depends on who's asking and why as I hate wasting my time to dig up information only to have the person ignore it and/or move the target.
Your the only one that made a claim and provided no evidence for it. This thread itself hosts proof of my claim.Oh I merely asking for the evidence of there claims
And thanks to those demos, we know what that tessellator can do http://www.youtube.com/watch?v=p7PlQ-q17tM
Its still likely that the Wii U has a higher level tessellator though.
OG_Original Gamer
Member
Isn't tessellation shader based now or is it directly tied to graphic engines?
Tessellation creates real geometry. Its completely different from shading, so that is unlikely. You still have to use displacement maps to take advantage of it but that is about it.
You know, I actually proposed the same thing long long ago in this thread. It pretty much got struck down. The TEV was a beast though. It would e nice if it was on the GPU.
I always find it strange how people try to write off improved hardware that didn't exists until a few years previous as ancient, because its "based" on older tech.
For me, the fact that Espresso and Latte didn't exist until 2012 means they are 2012 tech. The hardware in the Wii U was impossible to produce back in 7th gen making the endless "Wii U is a 7th gen console" claim asinine.
OG_Original Gamer
Member
My guess is, that it eats up bandwidth, and older cards just didn't have enough to not affect performance.
MrPresident
Banned
HD5870 and HD7870 have the exact same bandwidth and the former is faster in terms of pure FLOPs. Yet, HD7870 is more than twice faster at tessellation.
lwilliams3
Member
So this was the r700 tessellation video mentioned before. Thanks for posting that. I would expect the Wii U to just as capable with tessellation at the minimum. I believe that it has been upgraded, though, but I'm unsure if anyone would truly know. Not much is known about AMD's Gen-2 Tessellation.
OG_Original Gamer
Member
I'm going as far back as TruForm, before r600 and Xenos. R800 and up all used GDDR5, I know that. Actually bus width changed with the 7000 series.
I see your 64kB demo and raise you a 1kB demo: http://www.youtube.com/watch?v=dgDlqC19kss
I have posted the Froblins videos so many times through this thread every time tessellation has come up and you are just now seeing it. This is why I stopped bothering to link stuff.
And This is why I scoff at statements that try to make issues out of meager RAM capacity differences over 1GB. No game "needs" more than 2GB of RAM to to make a high quality game. Having more than that just allows for more laziness in development.
Can someone explain that comment Shin'en made about the GPGPU features alleviating memory access?
blu
Wants the largest console games publisher to avoid Nintendo's platforms.
The computer I'm typing this on hosts a DDR3-equipped R800.
ab.aeterno
Member
No game "needs" more than DVD for storage, or 480i for display, or Mono for sound -- you can make that argument about anything. But having the capability is important for pushing boundaries. And as most games can't procedurally generate their assets, they can't make their memory usage as low as what you see in that demo.
More memory means fewer sacrifices need to be made to get the game to run well. And that's certainly not laziness.
That is an an extreme exaggeration of my point and far cry from what I was trying to say.
DreadPirateRoberts
Member
Wait, are you seriously advocating weaker hardware because "lazy devs" the less time they have to spend on optimizing code and the more they can spend on content, or just having shorter and cheaper development cycles the better for everyone.
Weaker?
What I said had nothing to do with strength. I guess now people think capacity = power. Then again, everything is always about supposed "strength" with modern gamers.
OG_Original Gamer
Member
Impressive, optimization on memory use.
Gemüsepizza
Member
I don't know how you come to this conclusion because of graphic demos. Those demos do mostly not use any existing, high quality assets, they are just code and generate their "assets" in real-time to achieve their extremely small size. This is absolutely not viable for serious game development.
Gemüsepizza;82999713 said:
I don't know how you came to the conclusion that it was simply, because of graphics demos. My opinions on RAM precedes those demos.
Though, why are all of you raging about this? Its just my opinion. If you don't like it, you don't have to believe it. Goodness
MrPresident
Banned
I agree but we want to keep it within reason. I mentioned this above but procedural generation has very different needs of memory to that of hand created content. Procedural textures can be generated at runtime (which I assume Shin'en do using GPGPU) but that is very different to having 500mb of texture data in the form of, say, billboards or paintings in a scene. Procedural textures can be great for organic lifeforms or tarmac (because their textures are random in real life) but they can't be used to make a Calvin Klein billboard in a game like GTA.
Both of those 64k and 1k demos are generated procedurally which is the reason they can be so small. Games like GTA5 contain 12-15 gigabytes of data because cities aren't randomly generated. That said, the 1gb of usable RAM in Wii U would be able to make a vastly more spectacular GTA5 than the one we got.
It's not quite optimization of memory use but rather of file size. That procedurally generated content could be using a full 2gb of RAM once generated; it just means that the actual instructions to generate them use less.
DreadPirateRoberts
Member
the idea that cache has nothing to do with system performance (especally with unoptimized code) is silly, keeping a powerful system limited to 2GB of ram is just making a needless bottle neck.
That is true, though technically, if the game does not continuously store the procedurally generated data, then you could run an entire game like that in less than 200 MB of memory. You would just have to clear the cache as you proceed which is entirely up to the programmer(hence my statement about lazy devs).
Generally, the only way you will "need" more than a 1GB is if all of the textures in the game are the highest resolution possible, and the code isn't clean(ie. it doesn't overwrite data for things that aren't on screen anymore.)
A dev would have to make an intentional effort to make a game require more than 2GB of RAM.
Maybe when we reach the point where we can game in 4k, Then I could see us realistically needing more than 2GB.
MrPresident
Banned
That's amazing. I still try to follow the Amiga demo scene and it's incredible what people are coming up with on 26 year old hardware.
Also, this is also why I hate higher level programming languages(especially Java). Assembly has always been my favorite means of programming.
It is the only way to truly get the most out of hardware.
I wonder if Shin'en program some of their game components in assembly.
When you look at the making of Jett rocket on the Wii
‘Jett Rocket’ Character setup
Number of Triangles: 2508
Number of Vertices:1362
Number of Bones: 32
Number of Textures: 10
All Textures size: 290kb / 80kb (compressed)
Mesh Size: 50kb (compressed)
Animation: 244kb (compressed)
They get such a high quality model with such little data put into use. Also, on another note, the Wii hardware had some really nice occlusion capability.
ArchangelWest
Member
Wow.
blu
Wants the largest console games publisher to avoid Nintendo's platforms.
What was it?
JordanN
Banned
Froblins runs at 22fps on a HD 4890 by the way. Not really sure how that's helping Wii U especially since R700 is still outdated and that's a much more powerful card (almost Xbox One level?).
Also, that's a tech demo. Everyone knows games play differently. There was never a game made with it that I know of.
Also, that's a tech demo. Everyone knows games play differently. There was never a game made with it that I know of.
That's a texture. It even says so.
- Status