"No later than Monday".
It's Tuesday.
Not really wanting to bump, but just comment from the Shield TV die that 3 things are clear in that die shot from my highly uneducated understanding:
* The 4 A57s cluster
* The 2 Maxwell SMs
* No A53s
They're giving it for free, again, when they charge a buttload for die scans and analysis, just because we were interested. Lets not give them snark here![]()
There's an article on teh Verge about someone opening the left JoyCon and soldering a new antenna (I guess the right Joy Con has a separate antenna while the left one does not).
has anyone on GAF tried this?
Thanks for posting this, it's really helpful to have an original TX1 die photo to compare against for Switch, so it's great to see Fritzchens Fritz has done one just in time.
For reference, this is from the original Shield TV, not the new 2017 version (they have different die markings, so there may be some small changes to the TX1 in the newer Shield TV).
I started doing up a diagram of where everything is on the die photo, to use as a point of reference against a Switch die shot... but then I got distracted and started playing Zelda instead. So here you go:
Shield TV TX1 does include A53s, they're just disabled (no battery, larger space for cooling, they just chose responsiveness over slight power savings)
My optimistic guess is:
16nm
4xA72s
2xPascal SMMs
Modified uncore for cache coherence (Standard ARM uncore, licensed)
![]()
Look at this die analysis, we can spot the same formation of a57s although it seems in a less wider fab process, but there is no little a53s "cross" cluster in Shield TV die.
Some time ago I found a page stating that a53 were ditched from later X1s but I just can't find it now :/
Way to high hopes!
I think It's going to be:
28nm
4xA53
2xMaxwell SMMs
There's an article on teh Verge about someone opening the left JoyCon and soldering a new antenna (I guess the right Joy Con has a separate antenna while the left one does not).
has anyone on GAF tried this?
that's funny
The pics we got from before, dont they basically disprove 28nm process?
The hypothesis I made was, the game is very bandwidth-heavy because of its physics and alpha effects, and since it comes from a system based around having the whole render targets in its 32MB eDRAM, whereas Switch uses tiles in order to have a smaller, cache based, memory pool. Since Zelda was originally designed for Wii U not all of the graphics can be tiled and the game suffers in bandwidth intensive areas and when streaming assets.
Why do you guys think BOTW Switch in docked mode was only 900p with significant sub 30 fps drops?
Best the Switch could do? Different architecture from the Wii U made it difficult to do better and/or Nintendo didn't want to spend too much time on the port? Nintendo is still learning the Switch architecture and there will be better graphical games in the future?
Way to high hopes!
I think It's going to be:
28nm
4xA53
2xMaxwell SMMs
Port from a completely different architecture made mostly on non final hardware and rushed for launch.
Nintendo: The internals is a Custom tegra optimised for performance and power efficiency.
Devs: Great! What are these customisations?
Nintendo: We took a TX1, enlarged the fabrication node, and put in a much less efficient and weaker cpu.
Devs: Wtf.
I mean, the transistor count of the chip would barely decrease, and wouldn't account for the huge die size that 28nm would entail.
Also, the redesign would be as expensive as making it more powerful, and the 28nm chips would not be significantly cheaper than 16nm ones.
It makes no sense, engineering wise, commercially wise, or in any way.
The hypothesis I made was, the game is very bandwidth-heavy because of its physics and alpha effects, and since it comes from a system based around having the whole render targets in its 32MB eDRAM, whereas Switch uses tiles in order to have a smaller, cache based, memory pool. Since Zelda was originally designed for Wii U not all of the graphics can be tiled and the game suffers in bandwidth intensive areas and when streaming assets.
Edit: about Zelda, that's the thing. Switch has 20GB/s of main memory bandwidth available in portable mode, so in that mode it has no problem because of the resolution difference.
A resolution increase wouldn't increase main memory bandwidth linearly though. Framebuffer access in main memory (especially for a TBR) will only be a fraction of total main memory usage. So the 56% resolution increase wouldn't come close to requiring 56% more bandwidth. It may need more than the 20% increase docked mode gives Switch though. So like I suggested possibly a small framerate dip with double buffering then causing the major drop to 20fps?
The way I see it, of the devices in the same range as Switch released in the last 18 months, the 100% of them are in 16/14 nm and the 0% of them have A57 CPUs.
So, why would Nintendo use them?
Nvidia had 250 of its 10000 employees working exclusively on this thing, I'm sure that's enough for designing an updated chip compared to the 2 year old TX1.
Edit: about Zelda, that's the thing. Switch has 20GB/s of main memory bandwidth available in portable mode, so in that mode it has no problem because of the resolution difference.
It might have something to do with quickly porting an engine that was designed for Wii U somewhat late in the development cycle.
Eh, i've been saying this since the DF analysis dropped, Tom said that too, nobody's listening.The hypothesis I made was, the game is very bandwidth-heavy because of its physics and alpha effects, and since it comes from a system based around having the whole render targets in its 32MB eDRAM, whereas Switch uses tiles in order to have a smaller, cache based, memory pool. Since Zelda was originally designed for Wii U not all of the graphics can be tiled and the game suffers in bandwidth intensive areas and when streaming assets.
This too, but it never drops in 720p so better bandwidth management in 900p should bring performances to undocked levels. GPU certainly can't be an issue.A resolution increase wouldn't increase main memory bandwidth linearly though. Framebuffer access in main memory (especially for a TBR) will only be a fraction of total main memory usage. So the 56% resolution increase wouldn't come close to requiring 56% more bandwidth. It may need more than the 20% increase docked mode gives Switch though. So like I suggested maybe a small framerate dip caused by bandwidth constraints with double buffering then causing the major drop to 20fps?
I know, having low hopes
ShhhI rather have low hopes and be surprised than disappointed
![]()
Eh, i've been saying this since the DF analysis dropped, Tom said that too, nobody's listening.
There also seem to be some issue with the streaming (sometimes when it starts dropping if i stop and start moving again after 1-2 seconds it doesn't dip anymore) and possibly a memory leak somewhere, which would potentially explain the "game stopped working due to an error" message that some of us got (happened 10 times to me before i could actually start it).
Because no 16nm Tegra is available as of yet. What other companies have done with their SoCs doesn't mean Nvidia has come along.
250 people working two years could certainly do /something/, but that's not a massive amount of man-hours to radically redesign a tegra in the chipmaking world.
The die size is also suspiciously very similar to the TX1, so occam's razor here,
1) They reconjiggered a bunch of stuff, moved to a new node, and coincidentally landed on the same die area
or
2) Same node, same basic layout of CPU/GPU, minor changes here and there where Nintendo found interest (i.e memory chain)
We'll see hopefully shortly, but I think expecting a radically different chip than TX1 is setting yourself up for a letdown.
Parker is a 16nm tegra. It's made for cars but still. Would a node shrink really count as a radical redesign?Because no 16nm Tegra is available as of yet. What other companies have done with their SoCs doesn't mean Nvidia has come along. And A72 and Pascal aren't taped out on 20nm.
250 people working two years could certainly do /something/, but that's not a massive amount of man-hours to radically redesign a tegra in the chipmaking world.
The die size is also suspiciously very similar to the TX1, so occam's razor here,
1) They reconjiggered a bunch of stuff, moved to a new node, and coincidentally landed on the same die
Parker is a 16nm tegra. It's made for cars but still. Would a node shrink really count as a radical redesign?
I agree with you from all the evidence it's most likely 20.
Afaik they detailed the layout, but Parker isn't in any shipping products yet, or has that changed?
Wasn't calling the node shrink itself a radical redesign, but rather that node difference combined with changing all the functional units on a TX1 and coincidentally landing on a similar die size would be a big coincidence, rather than the seemingly more likely scenario of it being on the same 20nm node, same functional units, a tweak here and there.
The 250 people x 2 years also includes the bespoke NVN API, the OS integration, some sort of physics library tailored for Tegra they mentioned, etc. Doesn't seem to leave much room for changing things a whole lot.
Port from a completely different architecture made mostly on non final hardware and rushed for launch.
Woah so I'm not the only one who noticed this.There also seem to be some issue with the streaming (sometimes when it starts dropping if i stop and start moving again after 1-2 seconds it doesn't dip anymore)
That's what TBR is for, with Vulkan you can even do full deferred rendering without touching main memory just like you do in Wii U. If the thing is cache coherent, that also reduces bandwidth needs by eliminatig copying between memory allocations.I wonder if they made the L2 or L3 cache any larger... I'm worried about the 25 GB/s RAM speeds. I know Wii U was only about 12 GB/s, but that 32 MB EDRAM made a huge difference.