-
We have an update on ResetEra's ownership. More info here!
Thank you, I recall now that you say it, that DynamIQ is supposed to emulate the big.LITTLE features.
So that's one relief, as it's paramount to keep as good of a user experience.
The way how big.LITTLE works is a bit more complicated than that and what the Switch's OS task scheduler sees is another matter, but no need to discuss these details that have no value for gamers.
DynamIQ is big.LITTLE for ARM A55 and A75 - A78 CPU family. The main difference between the old implementation is the size of the CPU cluster.
Modern ARM CPU cluster contains 8 cores instead of the old one which could only contain 4 cores. All cores shares the same L3$ memory pool. Some of the cores can also use a dedicated power rail in order to adjust the core voltage independently from the other cores (E2100 have a power rail for the X1 core compared to S888's X1 which use the same power rail used for the 3 A78s). Moreover, clocks can independently by adjust in a core by core basis which could only be done with A73/A53 with the old bL.
That's why the next model will probably have 8 cores in a 4+4 configuration (4*A78 + A55). The other possibility is A78C which can be used in a 6 or 8 cores layout but without any A55 cores. While it could mean higher price due to a much greater transistor budget, it could also be the only possibility to have an 8MB L3$ which could be necessary in order to handle PS5 ports.
I never heard of a requirement for internet connection to use dlss. If so, yea that's a major caveat for a handheld system.
The neural network used to train the DLSS model for each game uses a server, but the results are delivered locally via drivers & updates. There shouldn't be any technical requirement to have a persistent internet connection to use it, even if Nvidia is requiring it in the current implementations.
That's also how I thought it was managed; via a driver update.
DynamicIQ is not emulating big.LITTLE features.
It's a new and more flexible cluster design *for* big.LITTLE. It's the same concept, but with a new architecture that allows for more flexibility in the mixing of different cores.
And even then, the little cores being there or not have *nothing* to do with the sleep functionality in the Nintendo Switch.
DLSS does not require an internet connection at all.
You're mixing up the invasive telemetry in the Nvidia driver with the actual technology behind DLSS.
The technology itself does not have any need for an internet connection, the model is pre-trained and shipped as part of the driver.
Babbling about the power of misinformation and how people don't understand tech, and then making all these claims about DLSS, the state of the A53 cores in the X1, or how new ARM cores are not big.LITTLE and how that's supposedly needed for the sleep functionality (it's not), is all very ironic.
Absolutely. The problem I see with something like RT cores is cost limitations, die space limitations, and power consumption limitations. In a portable device of such a small size, it would be a challenge to include enough of them to efficiently use ray tracing with little consequence to the limitations in question.
Yup
As mentioned earlier, DLSS no longer requires training per game. It's a more generalized approach post 2.0 update.
Ah, right, of course. So the way this would likely work in practice is each game would require a certain Switch firmware version at a minimum.
No, not really. As explained in the video, DLSS 2.0 (and above) now uses one general model for every DLSS implementation, a model which Nvidia will update to improve the quality of DLSS as time goes on (and as of DLSS2.1, it now supports variable resolution internal rendering to a set target resolution). Any Switch game does not require to "have its own firmware" for DLSS to work. Rather, the game's engine just need to be updated to support DLSS as a sort of black box that it needs to feed data, such as motion vectors.
That word is doing a lot of heavy lifting, don't you think?
For example, Crytek talked about how problematic specular highlights along the edges of geometry could screw with the results. This would be highly scene dependent (but could be addressed by managing exposure levels). There's nothing about a DLSS black box that would make this not a problem. I think it's best not to oversimplify how DLSS might be integrated in an engine that wasn't designed for it from the beginning.
I had some time to kill, so because I never tested DLSS on my Laptop with a RTX 2080 MAXQ, I installed Deliver us the Moon and turned on DLSS (without and with an internet connection lol). I made a short video:
The settings are all on "epic", resolution is 2560x1440 and RTX is activated (of course). The framerate was around 60fps without obs recording, but you can still see how the framerate increases almost 2x as soon as DLSS is activated. Obviously the connection to the internet makes no difference on DLSS
The settings are all on "epic", resolution is 2560x1440 and RTX is activated (of course). The framerate was around 60fps without obs recording, but you can still see how the framerate increases almost 2x as soon as DLSS is activated. Obviously the connection to the internet makes no difference on DLSS
Last edited:
They wouldn't continue to update the drivers and (presumably) distribute those updates with new firmware updates?
I'm not talking about per-game updates; just general updates to the drivers.
General updates to the DLSS models would most likely be milestone updates that coincide with System Firmware updates. The current model should be generalized enough that it should work with any existing or future games that decide to use DLSS without the need to retrain the neural network. It just needs to be fed the right sort of data and mip biases/LOD for the target resolution also have to be taken into account.
(The Crytek presentation explains how not everything in their engine produces motion vectors, but the model seems to still be okay with it without any noticable negative impact. Of course, people with keen eyes will likely notice some mild ghosting like the foliage in Sekiro, but it would still be miles clearer than having TAA.)
It's likely the engineers would be taking into account all the different case-by-case scenarios, in which case, it's down to how they train their algorithms to blend/interpret pixels in every one of them, like those particle in Death Stranding which inadvertendly cause a streaking effect.
Well there you have it Ookaze . DLSS does not require a constant internet connection to function.
DLSS certainly doesn't have a single one-size-fits-all model.
That was 1.0. 2.0 was generalized enough to work even at different target resolutions and in 2.1 we started seeing a more universalized approach by implementing it enginewide in Unreal and Unity.
Sure, it's not going to be used for everything (pixel art, etc.). It's still going to require data like motion vectors and such, but for most use cases its a good replacement for TAA.
What i'm saying is that even if it's not trained per-game, doesn't mean that internally doesn't have different specialised models aimed at optimally upscaling different scenarios.
I find it likely they're doing some sort of classification of content and then picking the appropriate model matching a predefined set of hyperparameters.
If you look at text for example, there's strong indications given by the artifacts that it's being treated differently from game content.
All of this doesn't matter for the developer tho, it's all transparently handled by Nvidia.
For me DLSS is enough of a shock to me for Nintendo to be using nevermind RT. I just can't see it because of the limitations you listed. In an alternate World where Switch was a console meaning more die space then it would be a lot more likely.
There is of course the development saving they would make on baking lighting when using RT but at some point the limitations of the silicone would preclude the full use of RT for GI anyway so they would be using both methods for lighting which is spending more not less.
Overall I expect DLSS for this new Switch chipset with more cores for RT for the next major redesign.
I know and understand that, I was just asking out of curiosity
If it's generalized then a model set comes with the driver built into the firmware. If it's per game, then the model or models come with the game. If the models make it hard to fit on a cartridge, then they can be downloaded from the eShop as the free 4k DLC.
That part is easy enough.
What I wonder about is if portable clocks will be high enough to use DLSS (it feels like there will be some sort of tensor performance threshold that has to be met to do 360 -> 720 or 480 -> 720 or 540 -> 720) and if they're not, then maybe tensor cores could be powered down while in portable mode.
That part is easy enough.
What I wonder about is if portable clocks will be high enough to use DLSS (it feels like there will be some sort of tensor performance threshold that has to be met to do 360 -> 720 or 480 -> 720 or 540 -> 720) and if they're not, then maybe tensor cores could be powered down while in portable mode.
Just to articulate on this.
If you decide to use baked lighting in your game, you wouldn't use Switch hw to do the baking, so it doesn't really matter if it has hw support for it or not in this case.
You can use any hardware or software combination, and would likely use high end desktop cards for this.
That. said, while in theory using hw accelerated RT to bake lighting sounds a good time saver, the effort to switch to a baking pipeline exploiting the hw is quite significant and I'm not even sure there's many games if any at all actually doing that.
I don’t understand what on earth happened
To go on a more related discussion, it can make more sense, using brainchild’s information for the implementation of DLSS, why they mentioned it way back in September about getting games ”4k ready”. There is more than just a button flick to get it to work and if developers knew of it since way back then of not only the quality of assets ready for 4k, but also the implementation of DLSS in the case of the switch, then it makes sense why they would be notified that early.
A light remaster+implementing DLSS can require some time seems like a fair conclusion wrt that.
To go on a more related discussion, it can make more sense, using brainchild’s information for the implementation of DLSS, why they mentioned it way back in September about getting games ”4k ready”. There is more than just a button flick to get it to work and if developers knew of it since way back then of not only the quality of assets ready for 4k, but also the implementation of DLSS in the case of the switch, then it makes sense why they would be notified that early.
A light remaster+implementing DLSS can require some time seems like a fair conclusion wrt that.
Last edited:
...this is the weirdest concern trolling attempt I've seen in this place so far.
DLSS does not require any internet connection to anything to work.
DLSS does not require any internet connection to anything to work.
OP
OP
Someone thought I was full of shit for asking a hypothetical question of how many games would take advantage of DLSS to go from as low as 360p to as high as 1080p in handheld mode if the new model has a 1080p screen.
(I don't deny that in general, I'm full of shit at times.)
But here's something that's potentially interesting.
Hey, my time identifying traffic lights on CAPTCHAs has finally paid off!
Of course, my point was it would be better in terms of finances for Nintendo to wait and go all in on RT once their hardware can fully support it. I think it’s pretty well accepted that RT for most things would be significantly cheaper development wise rather than spending thousands of hours baking lighting into everything.
FYI, I've uploaded a link to the slides for that presentation:
SE3071 - DRIVE AGX Hardware Update with NVIDIA Orin.pdf
drive.google.com
Overview shot:
according to Anandtech, a single chip looks to be 32SM, which is inbetween the 3060 and 3060Ti (28SM and 38SM respectively).
it'd nearly compete with the PS5 in the number of shader cores, but not clock speed
OP
OP
Here's the information Nvidia provided about the specs of Orin during GTC China 2019, courtesy of Forbes.FYI, I've uploaded a link to the slides for that presentation:
SE3071 - DRIVE AGX Hardware Update with NVIDIA Orin.pdf
Overview shot:
Note: 2021 Orin is referring to the specs Nvidia revealed about Orin during GTC 2021, whilst 2019 Orin refers to the specs Nvidia revealed about Orin during GTC China 2019.
So, 2021 Orin has ~19.05% more transistors compared to 2018 Orin, which results in a ~21.26% increase in INT8 TOPS for 2021 Orin in comparison to 2019 Orin. 2021 Orin also has ~2.44% more memory bandwidth in comparison to 2019 Orin.
Edit: I wonder what the max transistor density of Samsung's 8N+ process node. And I guess there's still a possibility the new model's SoC might be fabricated using Samsung's 7 nm (7LPP) or 6 nm (6LPP) process nodes.
Last edited:
I would expect HDMI 2.1 for future-proofing. Heck, the Switch launched with USB-C in 2017 when the port wasn't even used that much.
Isn't that's the just power of the power of the built in encoder/decoder?
Here's the information Nvidia provided about the specs of Orin during GTC China 2018, courtesy of Forbes.
Note: 2021 Orin is referring to the specs Nvidia revealed about Orin during GTC 2021, whilst 2018 Orin refers to the specs Nvidia revealed about Orin during GTC China 2018.
So, 2021 Orin has ~19.05% more transistors compared to 2018 Orin, which results in a ~21.26% increase in INT8 TOPS for 2021 Orin in comparison to 2018 Orin. 2021 Orin also has ~2.44% more memory bandwidth in comparison to 2018 Orin.
Edit: I wonder what the max transistor density of Samsung's 8N+ process node. And I guess there's still a possibility the new model's SoC might be fabricated using Samsung's 7 nm (7LPP) or 6 nm (6LPP) process nodes.
It is a very large chip
disregard
They didn’t see it coming, 4.5K everything :P
Last edited:
OP
OP
Not necessarily, since those specs sounds like the specs for the 7th gen NVDEC (Nvidia Decoder) and NVENC (Nvidia Encoder), which is practically the same as the 6th gen NVDEC and NVENC.
I believe all of the consumer Ampere GPUs are fabricated using Samsung's 8N process, not Samsung's 8N+ process node.
I've managed to find a slide from Nvidia from 2020 talking about Orin. And the specs for Orin in the slide are the exact same as the specs Nvidia disclosed about Orin during GTC China 2018. So the increase of transistors, which resulted in the increase of INT8 TOPS, and the increase in memory bandwidth was very recent.Here's the information Nvidia provided about the specs of Orin during GTC China 2018, courtesy of Forbes.
Note: 2021 Orin is referring to the specs Nvidia revealed about Orin during GTC 2021, whilst 2018 Orin refers to the specs Nvidia revealed about Orin during GTC China 2018.
So, 2021 Orin has ~19.05% more transistors compared to 2018 Orin, which results in a ~21.26% increase in INT8 TOPS for 2021 Orin in comparison to 2018 Orin. 2021 Orin also has ~2.44% more memory bandwidth in comparison to 2018 Orin.
Edit: I wonder what the max transistor density of Samsung's 8N+ process node. And I guess there's still a possibility the new model's SoC might be fabricated using Samsung's 7 nm (7LPP) or 6 nm (6LPP) process nodes.
That sounds super impressive and I assume such a console would have hi compatibility with a hybrid Switch on the assumed OrinS cut down version