Star Wars Force Unleashed
This patch was to head in the mainline kernel. The public mailing lists are the correct path for that, so this isn’t an accidental leak. This is totally normal for kernel development. The only unusual thing here is the fan scrutiny on this particular product.
Given Nvidia’s SoC naming conventions (Parker, Xavier) it’s 100% Marvel Thor.
Because the emails were sent to a public mailing list. That's just how Linux kernel development works.
Probably, I wouldn't expect them to upstream it unless the hardware was finalized.
Also lacks Ada's Optical Flow Accelerator and much faster Tensor cores. The OFA specifically is what powers the frame interpolation, from what I'm reading. My 3080 doesn't share T239s power limitations and I'm not getting 3.0 either.
ah thanks! yeah I was drawing a blank with Batman.
It will most likely have most of the latest tech, but not the really latest
Isn't that interpolation? You have point A and point E and you use those to generate points B, C and D?
xenosaga.fandom.com
I mean, in theory. People have mostly assumed they were referring to AV1 encode.
yea, the power draw is why I think it's not there. impossible to know just how much more power the tensor cores need now, but it's definitely moreAlso lacks Ada's Optical Flow Accelerator and much faster Tensor cores. The OFA specifically is what powers the frame interpolation, from what I'm reading. My 3080 doesn't share T239s power limitations and I'm not getting 3.0 either.
github.com
> diff --git a/drivers/cpufreq/tegra194-cpufreq.c b/drivers/cpufreq/tegra194-cpufreq.c
> index 1216046cf4c2..f38a760da61b 100644
> --- a/drivers/cpufreq/tegra194-cpufreq.c
> +++ b/drivers/cpufreq/tegra194-cpufreq.c
> @@ -38,14 +38,6 @@
> /* cpufreq transisition latency */
> #define TEGRA_CPUFREQ_TRANSITION_LATENCY (300 * 1000) /* unit in nanoseconds */
>
> -enum cluster {
> - CLUSTER0,
> - CLUSTER1,
> - CLUSTER2,
> - CLUSTER3,
> - MAX_CLUSTERS,
> -};
> -
> struct tegra_cpu_ctr {
> u32 cpu;
> u32 coreclk_cnt, last_coreclk_cnt;
> @@ -67,12 +59,12 @@ struct tegra_cpufreq_ops {
> struct tegra_cpufreq_soc {
> struct tegra_cpufreq_ops *ops;
> int maxcpus_per_cluster;
> + size_t num_clusters;
> phys_addr_t actmon_cntr_base;
> };
>
> struct tegra194_cpufreq_data {
> void __iomem *regs;
> - size_t num_clusters;
> struct cpufreq_frequency_table **tables;
> const struct tegra_cpufreq_soc *soc;
> };
> @@ -166,6 +158,14 @@ static const struct tegra_cpufreq_soc tegra234_cpufreq_soc = {
> .ops = &tegra234_cpufreq_ops,
> .actmon_cntr_base = 0x9000,
> .maxcpus_per_cluster = 4,
> + .num_clusters = 3,
> +};
> +
> +const struct tegra_cpufreq_soc tegra239_cpufreq_soc = {
> + .ops = &tegra234_cpufreq_ops,
> + .actmon_cntr_base = 0x4000,
> + .maxcpus_per_cluster = 8,
> + .num_clusters = 1,
> };
>
> static void tegra194_get_cpu_cluster_id(u32 cpu, u32 *cpuid, u32 *clusterid)
> @@ -382,7 +382,7 @@ static int tegra194_cpufreq_init(struct cpufreq_policy *policy)
>
> data->soc->ops->get_cpu_cluster_id(policy->cpu, NULL, &clusterid);
>
> - if (clusterid >= data->num_clusters || !data->tables[clusterid])
> + if (clusterid >= data->soc->num_clusters || !data->tables[clusterid])
> return -EINVAL;
>
> start_cpu = rounddown(policy->cpu, maxcpus_per_cluster);
> @@ -433,6 +433,7 @@ static struct tegra_cpufreq_ops tegra194_cpufreq_ops = {
> static const struct tegra_cpufreq_soc tegra194_cpufreq_soc = {
> .ops = &tegra194_cpufreq_ops,
> .maxcpus_per_cluster = 2,
> + .num_clusters = 4,
> };
>
> static void tegra194_cpufreq_free_resources(void)
> @@ -525,15 +526,14 @@ static int tegra194_cpufreq_probe(struct platform_device *pdev)
>
> soc = of_device_get_match_data(&pdev->dev);
>
> - if (soc->ops && soc->maxcpus_per_cluster) {
> + if (soc->ops && soc->maxcpus_per_cluster && soc->num_clusters) {
> data->soc = soc;
> } else {
> dev_err(&pdev->dev, "soc data missing\n");
> return -EINVAL;
> }
>
> - data->num_clusters = MAX_CLUSTERS;
> - data->tables = devm_kcalloc(&pdev->dev, data->num_clusters,
> + data->tables = devm_kcalloc(&pdev->dev, data->soc->num_clusters,
> sizeof(*data->tables), GFP_KERNEL);
> if (!data->tables)
> return -ENOMEM;
> @@ -558,7 +558,7 @@ static int tegra194_cpufreq_probe(struct platform_device *pdev)
> goto put_bpmp;
> }
>
> - for (i = 0; i < data->num_clusters; i++) {
> + for (i = 0; i < data->soc->num_clusters; i++) {
> data->tables[i] = init_freq_table(pdev, bpmp, i);
> if (IS_ERR(data->tables[i])) {
> err = PTR_ERR(data->tables[i]);
> @@ -590,6 +590,7 @@ static int tegra194_cpufreq_remove(struct platform_device *pdev)
> static const struct of_device_id tegra194_cpufreq_of_match[] = {
> { .compatible = "nvidia,tegra194-ccplex", .data = &tegra194_cpufreq_soc },
> { .compatible = "nvidia,tegra234-ccplex-cluster", .data = &tegra234_cpufreq_soc },
> + { .compatible = "nvidia,tegra239-ccplex-cluster", .data = &tegra239_cpufreq_soc },
> { /* sentinel */ }
> };
>
> --
> 2.17.1
>Harada is standing in the way of the second coming.Jesus Christ
Jesus Christ, referred to in the Xenosaga trilogy as the Messiah (メシア, Meshia), is a major figure referenced multiple times in the Xenosaga series who directed and influenced chaos and Mary Magdalene, setting into motion several wide-reaching events in life and in death. He is seen physically in...
Bandai Namco won't port it.
Solving Entry-Level Edge AI Challenges with NVIDIA Jetson Orin Nano | NVIDIA Technical Blog
NVIDIA Jetson Orin Nano series system-on-modules (SoMs) deliver up to 80x the AI performance of NVIDIA Jetson Nano and set the new standard for entry-level edge AI.developer.nvidia.com
Jetson Orin Nano 4GB Jetson Orin Nano 8GB AI Performance 20 Sparse TOPs | 10 Dense TOPs 40 Sparse TOPs | 20 Dense TOPs GPU 512-core NVIDIA Ampere Architecture GPU with 16 Tensor Cores 1024-core NVIDIA Ampere Architecture GPU with 32 Tensor Cores GPU Max Frequency 625 MHz CPU 6-core Arm Cortex-A78AE v8.2 64-bit CPU 1.5 MB L2 + 4 MB L3 CPU Max Frequency 1.5 GHz Memory 4GB 64-bit LPDDR5 34 GB/s 8GB 128-bit LPDDR5 68 GB/s Storage –
(Supports external NVMe)Video Encode 1080p30 supported by 1-2 CPU cores Video Decode 1x 4K60 (H.265) | 2x 4K30 (H.265) | 5x 1080p60 (H.265) | 11x 1080p30 (H.265) Camera Up to 4 cameras (8 through virtual channels*) 8 lanes MIPI CSI-2 D-PHY 2.1 (up to 20 Gbps) PCIe 1 x4 + 3 x1 (PCIe Gen3, Root Port, & Endpoint) USB 3x USB 3.2 Gen2 (10 Gbps) 3x USB 2.0 Networking 1x GbE Display 1x 4K30 multimode DisplayPort 1.2 (+MST)/e DisplayPort 1.4/HDMI 1.4* Other I/O 3x UART, 2x SPI, 2x I2S, 4x I2C, 1x CAN, DMIC and DSPK, PWM, GPIOs Power 5W – 10W 7W – 15W Mechanical 69.6 mm x 45 mm 260-pin SO-DIMM connector Price $199† $299†
Yeah…. I’m not seeing 8N
Yeah, it seems like Nvidia disproved me on that one pretty quick! It makes more sense to use Orin for their Jetson line anyway, as it has the double-rate tensor cores and they advertise these based on ML performance.I think T239 being used for a Jetson devkit is unlikely, considering Nvidia recently announced Jetson Orin Nano.
Solving Entry-Level Edge AI Challenges with NVIDIA Jetson Orin Nano | NVIDIA Technical Blog
NVIDIA Jetson Orin Nano series system-on-modules (SoMs) deliver up to 80x the AI performance of NVIDIA Jetson Nano and set the new standard for entry-level edge AI.
But I am already here?
Yes, that’s true for interpolation, but if I understand correctly, with this technique they aren’t rendering point E ahead of time. They are relying entirely on past frames and their motion vectors fields to predict what the content of the next frame will be.
It almost sounds like it's alternating generated frames with game engine frames, unless it's doing 2:2:2:2.
I guess the language could be interpreted several ways. I'm excited to see something like a Digital Foundry breakdown of the technology, either way.
But Arm does mention the Cortex-A710 supporting up to 8 CPU cores per cluster and the Cortex-A715 supporting up to 12 CPU cores per cluster.
I think the details of your framing argument distracted a bit from what you were trying to say. But I get it now.
Yeah, it seems like they use the OFA to guess the next frame's motion vectors.
The docs say 8 cores are supported, but A710 seems too new to have been used, and A715 definitely is.
you added absolutely zero to this discussion, thanks for that.
Yes, since it is still using tensor cores. It would have to be updated in the software suite for devs though.
So would it be from the past?
This wouldn’t really come to Drake I’m afraid.Finally, a gigantic news for our coming beloved Switch Drake
They do support an 8 core cluster, but A715 does not support 32-bit and a few switch games are 32-bit.
We don’t really know tbh.
I mean, if that’s what you meant, then you should’ve phrased it like that because the way you were responding to the others implied heavily that you were basically saying that of which I wrote. I apologize if I didn’t understand it but like I can’t really imagine anything else if what’s in front of me, it just looks like you’re painting a different picture
Thanks, I missed that. Yeah, apparently some Wii U ports use 32 bit binaries, which would make the A715 tricky (although this is something they're going to have to deal with at some point). In theory the A710 would work, but I'd still say the A78C is by far the most likely unless we get any evidence otherwise.
Yeah, the more I think about it the more interpolation makes sense, except that they specifically say DLSS is generating one frame for each game-rendered frame, which makes it sound like you get four frames out for every two frames in. Unless it just means that 'after the first two frames, DLSS alternates generated frames with game-rendered frames.'
Wait a minute, only 30FPS for video encode? that's kinda disappointing
They are definitely alternating - there’s a diagram on this page that shows it:
The description of the inputs on that page also doesn't mention having to draw from future frames:
Still not 100% certain, but I feel more confident that they really are relying completely on inference for the generated frames.
Yeah, if I understand it correctly anyway.
It's definitely extrapolation, NVidia specifically mentions generating frames while the CPU bottlenecks a frame drop. It needs a buffer of input frame data in order to infer motion vectors in the OFA but also the DLSS 3.0 use case involves extrapolating frames while also supersampling.
Very cool, thanks for pointing this out.They are definitely alternating - there’s a diagram on this page that shows it:
I believe the pairs of images part is talking about the optical flow estimation:
The description of the inputs on that page also doesn't mention having to draw from future frames:
Still not 100% certain, but I feel more confident that they really are relying completely on inference for the generated frames.
Yeah, if I understand it correctly anyway.
nvidianews.nvidia.com
From a technical point of view I'm sure they could, but from a practical point of view the small size of joy-cons would probably be a hinderance. VR controllers tend to be quite large, usually with a halo ring of tracking points on top, to make them visible to the tracking cameras, and to provide enough distance between tracking points to properly triangulate the position. The joy-cons have to be small for the Switch to be portable, and even if you added a bunch of tracking points onto them they'd pretty much all be covered by people's hands while in use. I wonder if something along the lines of the ultra-wideband RF-based location tracking Apple use in their U1 chip could provide accurate enough tracking without the need for cameras.
I think that's the eventual target. You set an output resolution and frame rate and DLSS - or whatever the end upscaler is - guarantees it, upscaling and extrapolating as it goes. Ultimately, the only barrier is actually rendering frames starving out the GPU before it can generate pixel/frame data.
My hope is that something like this simply allows for Wii level motion controls, outside of VR - using the dock, for example, as a reference point, and the tensor cores for inference.
Maybe relax
it seems to be a bait similar to the ones who can read under the big twitter accounts, the best is to just ignore
