-
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.
Nintendo Switch Dev Kit Stats Leaked? Cortex A57, 4GB RAM, 32GB Storage, Multi-Touch.
- Thread starter Robert at Zeboyd Games
- Start date
- Status
Smurfman256
Member
1080p->720p isn't an even number, either. It's also a 1.5 scale.
Yeah, 720p looks bad on a 1080p TV.
Smurfman256
Member
That said, 720p -> 2160p is 1:3, so I'll see how that looks on my 4KTV.
No it doesn't.
LordOfChaos
Member
I recently started dicking around on my 360 after being on the PS4 and PC for a year and a half, I remember reading in like, 2006 that 1080p wasn't a big upgrade, but holy shit is going back down to 720p native noticeable.
Not being an integer scale of 1080 hurts it further, and the scale of 540 would of course just be ungodly low on a large TV.
To prevent an infinite loop here, this is all of course subjective and if it looks good to you, awesome. I can't un-notice the blur personally. 900p is far less annoying, but still a bit noticeable.
lwilliams3
Member
I don't think Occam would have survived having a razor in hand and reading the last pages of this thread.
Also the "we don't know anything yet" people are the worst, actively trying to censorship a discussion just because they don't like the way it's going. It's mostly educated guess based on several rumoured variables anyhow.
Also the "we don't know anything yet" people are the worst, actively trying to censorship a discussion just because they don't like the way it's going. It's mostly educated guess based on several rumoured variables anyhow.
Yes. The visions come whenever I close my eyes. Never been easier.
I think whether or not Nintendo allows devs to use full clock speeds in portable mode depends on how efficient the system is (i.e. if it's 16 nm and/or has a decent battery). If we were to trust NateDrake and the reported 5-8 hours of battery life, then obviously they can allow devs to clock it higher in portable mode and still achieve a great portable experience.
On the other hand, if the battery life is already 3-4 hours using portable clock speeds, then I don't see Nintendo allowing it to go even lower.
On the other hand, if the battery life is already 3-4 hours using portable clock speeds, then I don't see Nintendo allowing it to go even lower.
I have a Shield TV, I could downclock it to the rumored Switch clock speeds and run a Unity 3D demo on it to for benchmarking. Might need clocking a little higher then Switch because of Android overhead though, not sure if its that much. Some high bandwidth usage demos would be interesting! Anything anyone wants me to test?
LordOfChaos
Member
Did that get the Android Vulkan update? On Vulkan it should make a better comparison (at the same clocks), NVN may be more efficient for being bespoke but I'm sure these low level APIs hit diminishing returns. On that you could test them 1:1 for clocks without worrying about OpenGL Android overhead.
You'd have to go deeper to turn off the second cluster of 4 cores that that has that the Switch does not though, if you want to get that exact.
The problem is that people aren't taking this stuff as rumor, they're treating it as fact, when we don't have all of the variables. Speculating is fine, but treat it as such. Until we get more pieces of the puzzle, all of this is just speculation. I can't speak for everyone else, but that's my take on it. There's nothing definitive here yet. We'll know more next week for sure. Even what games look like running on the system.
UnemployedVillain
Member
Come on dude, really? Do you honestly think clock speeds were the only change Nintendo made? They wouldn't even need Nvidia's involvement if they were using the off the shelf X1
You nailed it there. I doubt the final product is literally a Jetson TX1 massively downclocked.
I'm going to be prepared for it possibly being that, but I have to imagine they've made some changes and that there's not massive bottlenecks being caused by the reported "final clockspeeds".
I can test using Vulkan indeed, forgot about that! I thought perhaps Android itself may have some overhead too, but Android TV may have trimmed a lot of fat that isn't needed for a non phone device. I don't know if Unity would use the second cluster of CPU cores, perhaps it only uses 2 A57 cores on Android, for app compatibility with other Android devices?
If there is a Unity demo that has been tested on PS4, X1, Wii U etc that I can also test here, then we got a pretty good idea what to expect perhaps hah.
Of course not. Come on dude, really. But we know rumors say developers have had to work with similar hardware at least up until October.
LordOfChaos
Member
250 people working 2 years including a bespoke NVN API isn't going to be groundbreakingly different either. No one is saying they'd be 1:1 the same, but unless more SMXs were added it'll roughly point to the ballpark.
If Nintendo does their traditional thing of making sure memory bandwidth isn't a pressure it could be decently better still, but again, we're talking very loose ballparks, not saying exactly what to expect.
So what you want is that every post to begin with "If this is true ..." or "Considering these rumours ..."? Isn't that redundant? We're in a thread about rumours.
There's nothing definitive probably until somebody will do a teardown of the Switch after March and even then it's not guaranteed to be some 100% sure info.
So what then? Never discuss anything until some official info that will never come? It's ridiculous.
blu
Wants the largest console games publisher to avoid Nintendo's platforms.
He won't - TX1 uses cluster switching, so when the big cluster works the LITTLE sleeps, and vice versa. Bottomline, busy sw would mostly run on the big cluster, seeing 4x A57 for the duration of its run.
LordOfChaos
Member
Ah, right-o. Forgot it wasn't on the newer big.LITTLE heterogeneous multi-processing
Yes, but the HDD-less version came in the same case, there was just an empty space where the hard drive would otherwise be.
PowerVR uses tag buffers to resolve visibility for a tile and interpolates attributes before executing pixel shading. Perhaps they could use a similar technique?
Edit: Here's the TBDR Pipeline. The Tag Buffer seems to accomplish the same tasks as a G-Buffer would.
I only just saw your edit, and I've been reading a little bit on ImgTech's use of tag buffers, but I'm not sure it would be applicable here. For one, it would likely require a large-scale redesign of the Maxwell/Pascal ROPs, which I don't really see happening (unless Nvidia have already implemented something similar, which is possible). The other issue is that it would be of relatively little benefit to explicitly deferred renderers, as the intent of tag/visibility buffers seems to be largely focussed on gaining some of the benefits of deferred renderers (specifically the computational saving of not shading fragments until visibility is fully resolved) with forward renderers.
I was thinking more along the lines of the API giving developers the ability to give sufficient information to the GPU to know exactly what can be tiled and what can't, to allow any intermediate buffers to benefit from tiling as well as the color buffer.
Reading up a bit more on Vulkan's renderpasses and subpasses, though (PDF link here), it seems that it basically covers this. Each renderpass is a high-level operation which can consist of multiple subpasses over a number of (identically sized) buffer objects. The idea is that rather than using a render-to-texture for g-buffers (which requires pushing the entire frame to memory, and then reading from the texture in a way where tiling can't be guaranteed), you add the g-buffer as a buffer object, or "attachment" within the renderpass. Within the renderpass you can only operate on data from same pixel within the framebuffer or any attachments, which allows the GPU to tile the entire renderpass however it likes (or not, as the case may be).
Because of the limitation of not being able to reference data from other pixels (which is necessary to ensure it can be tiled) you can't do things like depth-of-field blurring or post-process AA within the renderpass, so it's unlikely that any given renderer can be fully tiled, but it allows the developer to explicitly group together everything that can be tiled, without resorting to vendor-specific extensions or breaking compatibility with immediate-mode rasterisers.
lwilliams3
Member
It may be a good baseline on what to expect. When we do see actual Switch games, we could also use that data to get some ideas on what modifications Nvidia and Nintendo have done to the chipset?
In my journey to figure out how to down clock my Shield's GPU, it turns out that it down clocks from its stock 1GHz speed anyway because of GPU scaling? Guessing its something to do with thermal throttling, but yeah! One of Dolphin's developers said that here. Shield TV could be running the GPU at that same 768MHz frequency as the Switch in its docked mode.
I just need to figure out how to set the frequencies.
In other news, the benchmarking I decided to go for was the Unity Standard Assets project, which features a couple of scenes. All scenes run at 1080p 60fps locked on the "Fantastic" quality settings, which includes 8x MSAA! Vulkan working very nice. Then again, these scenes aren't demanding but its nice to see. I can't figure out how to force vsync off so I can see how high the FPS can go, must be an Android thing? I need to push this harder ...
EDIT: Shield TV thermal throttles the GPU to 614MHz, very interesting indeed. I have an app that logs the frequencies, and it doesn't appear to go higher then that. Ran a 3DMark benchmark before and after to make sure, and yep it stays at 614MHz. Weaker then the Switch's docked mode, hah!
I just need to figure out how to set the frequencies.
In other news, the benchmarking I decided to go for was the Unity Standard Assets project, which features a couple of scenes. All scenes run at 1080p 60fps locked on the "Fantastic" quality settings, which includes 8x MSAA! Vulkan working very nice. Then again, these scenes aren't demanding but its nice to see. I can't figure out how to force vsync off so I can see how high the FPS can go, must be an Android thing? I need to push this harder ...
EDIT: Shield TV thermal throttles the GPU to 614MHz, very interesting indeed. I have an app that logs the frequencies, and it doesn't appear to go higher then that. Ran a 3DMark benchmark before and after to make sure, and yep it stays at 614MHz. Weaker then the Switch's docked mode, hah!
LordOfChaos
Member
Best we have is an "estimated" 1GHz by Ganesh from AT (several others cite 1020MHz exactly), I'm assuming he reversed the equation of 256 ALUs and the end performance, which probably means it's closer to there than the Switch. But as it's still an Android set top box first and console second, it's probably less stringent about maintaining exactly the same clock speed all the time and may jump up and down with loads and throttling.
http://www.anandtech.com/show/9289/the-nvidia-shield-android-tv-review/4
lwilliams3
Member
Now.. that is unexpected and interesting. So, does that mean that the games that were running on Shield have not been running close to full power?
Wow, is that when running games ported to Shield as well? Like, say, DOOM 3? Please do see what you can do to unlock the framerate, this is super interesting
Wait... Really?
This could potentially cast the Switch's rumored specs in a very different light.
LordOfChaos
Member
Now that's interesting. In docked mode that would mean they did actually increase the clock it stays at, rather than the maximum boost clock in most TX1s. Probably more stable a clock as a console too, they tend to avoid boost/throttling for steady performance
Was this on a Vsynced load, or did you find how to uncap it? The other possibility is that it just didn't need its full speed if vysynced.
lwilliams3
Member
Yeah. If the Shield really caps at 614MHz, the Switch's GPU in docked mode is running 25% faster (767MHz) , and it is running exactly half-speed (307 MHz) undocked. I have doubts that is just a crazy coincidence.
At this point, I'm wondering what's the max clock speed for the Jetson TX1 board when in full load. Might it also get thermal throttled just like the Shield?
Smurfman256
Member
This actually raises a few questions for me:
- Whats the cooling unit look like in the Shield TV?
- Why is it running that low with active cooling?
- Could the tiny little fan in the Switch really provide enough airflow to keep the max 768MHz clock speed?
- Is this possibly the reason why the early dev kits had such loud fans?
- Is it possible that they did switch to a smaller manufacturing process to mitigate the thermal throttling issues?
lwilliams3
Member
Good point!
Here's the Shield TV Opened up. A lot of space is taken up by the potential hard drive slot.
Which is why the new Basic model is smaller. They actually made a smaller case since basic doesn't support HDD.
Trying to find another app / figure out adb shell commands so I have more then one way of measuring to really make sure it is topping out at 614MHz when throttled. The Dolphin developer saying the Shield TV needs to be rooted to make it stay at 1GHz to get the most out of the GPU is convincing me enough that is the frequency it throttles down to.
Going to throw my shield in the fridge for a bit
Going to throw my shield in the fridge for a bit
lwilliams3
Member
That was my next question.
Trying to find another app / figure out adb shell commands so I have more then one way of measuring to really make sure it is topping out at 614MHz when throttled. The Dolphin developer saying the Shield TV needs to be rooted to make it stay at 1GHz to get the most out of the GPU is convincing me enough that is the frequency it throttles down to.
Going to throw my shield in the fridge for a bit
can u check on the temps ?
TyMiles2012
Member
Trying to find another app / figure out adb shell commands so I have more then one way of measuring to really make sure it is topping out at 614MHz when throttled. The Dolphin developer saying the Shield TV needs to be rooted to make it stay at 1GHz to get the most out of the GPU is convincing me enough that is the frequency it throttles down to.
Going to throw my shield in the fridge for a bit
Don't forget that Android also has a lot of overhead. The OS that the Switch will have will likely have bare metal access because of that and also the custom NVN API that Nvidia is putting together. Vulkan should also come close.
The A57 cores should to be clocked at 1.9GHz.
Well, that's the case with the Jetson TX1: http://www.phoronix.com/scan.php?page=article&item=nvidia-jtx1-perf&num=10
Pokemaniac
Member
We've heard both at different times. It's hard to say which will be accurate, especially because the two are very similar, and the Switch being a hybrid of the two is not unlikely.
Shield CPU clocks up to 2GHz fine, temps are between 40c to 50c. I have a infrared thermometer to check the outside case temperature and the little exhaust vent shows about 35c. The fan is dead silent, wouldn't be able to tell its on if you didn't check to feel a tiny bit of air blowing out of it hah!
lwilliams3
Member
Schnozberry
Member
Given how closely Nintendo and Nvidia worked on this API, I wouldn't be shocked to find out if cache was customized towards minimizing the need to move data in and out of main memory for additional post processing subpasses. A sizable L3 cache for the GPU and a larger L2 cache for the CPU would save a lot of bandwidth.
Huh.
So maybe they really are on 16nm and still need the fan, haha. 25% clock boost, for a ~30% efficiency gain down to 16nm?
No it's not. People can discuss whatever the hell they want. The difference is how it's approached. Some people in this thread are going on about how what we know is definitive and that's just not true. Nothing is definitive, but the reactions are acting like it is. That's the difference. If people understand that this is all speculation, then that's great. I personally have no problem with that.
And, yeah, posts SHOULD have some sort of disclaimer in there saying this is their opinion and not a sure thing. Saying... "The NS has A57 processors" is different from "I think it should have A57 processors" or "It makes sense for it to have A57 processors". Wording is important, because people run with this stuff and start taking it as fact when it's not. Maybe a lot of folks in this thread are responsible posters and understand what's going on, but there are others who aren't are take this stuff as gospel, when it shouldn't be.
You see it all the time. Someone says, "It's like this." and someone else will come along asking how they know. That leads to the original poster saying something to the effect of "It's just my opinion." Why cause confusion?
GameplayWhore
Member
Maxwell and Pascal are kind of the same architecture. There are some differences, and the latter is built on a process with a smaller feature size. The Switch's internals have been described in various rumour permutations as being a custom nvidia chip based off of Maxwell/Pascal.
Thing is, it could be a custom chip built on the earlier 28nm or 20nm fabrication process but incorporating some microarchitectural elements from Pascal. Or it could be a chip that's really entirely just a Maxwell architecturally but that's fabbed on a 16nm process like Pascal is (it seems less likely that they'd go this route, but whatevs). Which of those two options is "Pascal-based", and which is "Maxwell-based"? It's really kind of up in the air what you call it, since the two designs are so similar.
That's probably why you've seen it described as either in various places, especially since the only thing that's been confirmed is that it's a custom Tegra (per Nvidia).
(...also, Pokemaniac beat me with a more succinct answer, but I'm clicking Submit anyway)
It's running that low with active cooling because 20nm isn't efficient enough to run at a higher clock.
If Switch is 16nm, the clock would work well, and the extended battery life also makes sense, could also have other customizations in the chip, such as embedded memory or larger cache for the GPU and CPU to provide the increased power we heard from October devkits.
Yes, this is a safe assumption IMO.
This is the most reasonable way they could keep the clocks without throttling, we were wrong about the efficiency that 20nm had, and now the fan makes sense even at the 768mhz with 16nm IMO.
And X1 is a mix of Option Maxwell and Option Pascal already. It never really mattered if it was pascal or maxwell, it only mattered how many SMs it had (both maxwell and pascal have the same) and which process node it used (which thanks to higher clocks than X1's 20nm without throttling, points to 16nm) so yes after dozens of pages of speculation about 16nm, 20nm, 28nm... Maxwell or Pascal. The best of those options are pretty much what we have and the specs have not changed one bit, they are still ~400gflops docked, 157gflops portable.
lwilliams3
Member
Yeah, it sounds like 28nm is definitely off the table now. It is crazy that we went this long without knowing that Shield TV caps its GPU to such an extent.
What about Google's Pixel C? I recall people reporting that the GPU barely throttles at all. Does it cap at an unexpectedly lower frequency too?
- Status