Is it normal to render using a CPU? Shouldn’t this test be done against GPUs instead?
Rendering on the Apple M1 Max Chip
31–40 of 328 posts
Re: Rendering on the Apple M1 Max Chip
#32Earlier quoted context omitted.
They are from 2012. They are not "are getting kind of old", but are actually discontinued. https://ark.intel.com/content/www/us/en/ark/products/64583/i...
Not the Intel Xeon W-3245 which is from 2019. https://ark.intel.com/content/www/us/en/ark/products/193753/...
Yes, but the author is pretty intellectually dishonest when he says that his new MBP beat out a "somewhat old" xeon.
That's a ten year old CPU.
Re: Rendering on the Apple M1 Max Chip
#33I was randomly curious how long it would take to render a full movie at the quality of that forest image, which absolutely blew my mind. At 24fps, a 2h movie has 172800 frames. 21,970,310 M1 seconds or 8.5 M1 months. Which is less than I was expecting. The rendering seems to scale linearly per core too. Presumably bad math or a lot more rendering complexity for the pixar super computer deploys?
Worth keeping in mind is the similarity of frames. Or, the lack of difference. If you know that the light-source isn't changing then you can get way with just copying the last frame and super-imposing < 300 pixels to reflect what's changed. i.e. there's no need to render the same wall for every frame.
Re: Rendering on the Apple M1 Max Chip
#34Earlier quoted context omitted.
> there was a longstanding prediction that the arm architecture would overtake x86. So now the wheel turns and someone will have to predict how long it takes before RISC-V overtakes ARM.
I'd be willing to bet Apple will catalyze that change as well.
Only if they can lock it down.
Re: Rendering on the Apple M1 Max Chip
#35Earlier quoted context omitted.
I thought the observation was always that instruction set was not such a big difference in high performance CPUs next to manufacturing technology which was by far the first order effect. It would be expected for a high performance ARM CPU to reach roughly the same performance in that case (AMD is 1 generation behind here, I think Intel is 2). Is there really "chipheads" who are predicting ARM ISA to buck this trend a…
We'll get a live test of this very soon - Zen4 is going to be going head-to-head against Apple A16 (Apple's next core architecture) on TSMC N5P next year. Does anyone expect x86 to close a factor-of-6 perf/watt difference? (from Anandtech's M1 Max preview) A factor-of-2-to-3 IPC difference? And that's just A15, not against the next-gen A16. Node makes a big difference, it doesn't close up a factor-of-3 IPC gap in a s…
> Does anyone expect x86 to close a factor-of-6 perf/watt difference?
The one number that surprised me in this review was that the perf/W of Threadripper for the rendering phase: it is very close to the M1 Max. I understand that the numbers are not apples to apples because of the total laptop vs CPU-only comparison, but the power consumption of the Threadripper CPU itself is very high and probably takes the lion's share of the overall power consumption. And that's for a previous generation Threadripper.
Re: Rendering on the Apple M1 Max Chip
#36Earlier quoted context omitted.
The fixed width decoders have always been a commonly cited advantage of fixed width, and to some degree it must be true. But this is not a recent thing, the "common wisdom" about instruction format not mattering too much still very much applies here. Pre-decode lengths or stop-bits and more recently micro-op caches have been techniques that x86 has used to mitigate this and improve front end widths, for example. Peop…
> X86 tax might be 5% A consistent 5% win is pretty huge for certain industries.
> A consistent 5% win is pretty huge for certain industries.
Are you referring to Andy Glew's thread? He said perhaps 5%, but he also went on to say probably less than 5% for basically the lowest-end out of order processor that was fielded (A-9), not what you would call a high performance core (even then 10 years ago). On today's high performance cores? Not sure, extrapolating naively from what he said would suggest even less. Which is backed up by what Jim Keller says later.
So I'm not saying ARM won't leapfrog x86, I'm just asking what the basis is for that belief, and what those who believe it think they know that the likes of Jim Keller does not.
If it's an argument about something other than details of instruction set implementation (e.g., economics or process technology) then that would be something. That is exactly how Intel beat the old minicomputer companies' RISCs despite having "x86 tax", is that they got revenues to fund better process technology and bigger logic design teams. Although that's harder to apply to Apple vs AMD/Intel because x86 PC and server units and revenues are also huge, and TSMC gives at least AMD a common manufacturing base even if Apple is able to pay for some advantage there.
Re: Rendering on the Apple M1 Max Chip
#37Earlier quoted context omitted.
The fixed width decoders have always been a commonly cited advantage of fixed width, and to some degree it must be true. But this is not a recent thing, the "common wisdom" about instruction format not mattering too much still very much applies here. Pre-decode lengths or stop-bits and more recently micro-op caches have been techniques that x86 has used to mitigate this and improve front end widths, for example. Peop…
> X86 tax might be 5% A consistent 5% win is pretty huge for certain industries.
Yes, but people aren't impressed by the M1 chips because of 5% KPI differences.
Re: Rendering on the Apple M1 Max Chip
#38Is it normal to render using a CPU? Shouldn’t this test be done against GPUs instead?
There are two major approaches to rendering: rasterization and ray tracing. The former is faster, the latter is more real. They are completely different approaches.
Historically, ray tracing is only used for movies whereas games generally uses rasterization. The former is highly coherent workload, and is great for GPU. The latter is incoherent workload, and generally isn't suitable for GPU.
Games have started using ray tracing, and there have been GPU implementation of ray tracing in the past 5 or so years. What I said above may be stale.
Re: Rendering on the Apple M1 Max Chip
#39I mean apple have it "easy", they control the hardware and the software, they don't need to to something that work with pci, old ram, thousands of different configs, different disk etc ... They can do whatever they want with 0 compatibility or backward compatibility. Why is the test not testing against some AMD CPU, CPU that cost $400, 5800x or 5900x for example.
> They can do whatever they want with 0 compatibility or backward compatibility.
Apple put in quite a bit of effort to make sure x86 binaries still run the ARM Macs. It works for 99.5% of things in my experience. They have even been observed putting in compatibility tweaks for specific applications.
Also fun fact: The x86 compatibility software, Rosetta, isn’t distributed with macOS and has to be downloaded once it’s needed. This is likely Apple hedging their bets against possible future patent claims.
Re: Rendering on the Apple M1 Max Chip
#40Some of these images look incredibly real. Even knowing those are renders my brain refuses to believe these are not actual photographs. Also, these Xeons are really put to shame here.
> these Xeons are really put to shame here.
It doesn't really matter. Nobody's doing rendering on CPUs.
I get that he's sticking to comparing CPU to CPU rendering to compare apples to apples, but that's like saying "My new buggy whip is amazing!" in a news article written in 1950.
Everyone is doing GPU based rendering. Pascal based GPUs are still (I believe) several times faster than even current mid-tier AMD desktop processors. Pascal is two generations behind current GPUs, which are several times faster than it is.
What will actually be relevant and interesting is how the M1X's full capabilities can be leveraged for rendering, and how that will compare against Ampere GPUs.