Live data from Hacker News

Rendering on the Apple M1 Max Chip

blog.yiningkarlli.com

131–140 of 328 posts

Re: Rendering on the Apple M1 Max Chip

#131

Earlier quoted context omitted.

You’ve correctly identified one reason Apple’s hardware is so effective: they have a hardware-accelerated standard library, something that requires cooperation between their software and silicon developers. The nearest comparison is if Dell released a line of servers that, when paired with Ubuntu LTS, provided a hardware-accelerated glibc. They could do this at any time, but it’s not easy; the capital cost is incredi…

A lot of good it does them. MacOS is an incredibly poor performing OS. For years, Windows and especially Linux have been more responsive and load faster than macOS on similar hardware, despite not being in a vertically-integrated hardware/software system. It's difficult to imagine how anyone can think that M1 is "competing" with Intel or AMD because of this. You won't be getting macOS on any new x86 processor, and yo…

You are absolutely right, with one key alteration: There is no point for you in what Apple's doing. As you've identified, you're not the target market for their products. There is, however, a point for others, who have different priorities and compromises than you.

M1 is not a decision point for their consumer base, because most people don't care what CPU architecture is inside their laptop. However, M1 notably improves the decision points that do matter to their customer base: weight, noise, and battery capacity for each customer's workload.

This comes at the cost of macOS and the restrictions inherent in it. If that cost is acceptable, then the benefits are significant. If that cost is unacceptable, then the benefits are irrelevant. As you indicate, that cost isn't acceptable to you, and you do not indicate interest in any of the other benefits of their platform, which specifically exclude Windows, Linux, and PC gaming. This leaves me unable to determine why you're participating in this discussion.

So, then; why does the topic of 'M1 MAX' matter to you at all? I'm happy to continue discussing, but without that information, there's not a lot left to say.

Re: Rendering on the Apple M1 Max Chip

#132
post #31

Is it normal to render using a CPU? Shouldn’t this test be done against GPUs instead?

It's very normal. High end path tracers are still very much run on the CPU. GPU rendering is improving quickly, but the author is working at WDAS. Hyperion is still a CPU renderer, and I don't see it going to the GPU anytime soon.

Commercials and mid to low budget TV shows are moving to GPU rendering , but it's very much a factor of scene complexity and available time.

Re: Rendering on the Apple M1 Max Chip

#133
post #127
post #29

I 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?

You've got a few flawed basis points in your math. 1) that forest isn't near the complexity of most major feature films. It's great, but it's got a ton of instancing, it's not got very complex shaders, it's not got very complex lighting. It's a good benchmark scene, but it's not approaching the level of scenes in most feature films. 2) You're assuming a single render happens per frame. Every scene in a movie is rende…

> Pixar and other studios don't have really extraordinary computers. They're usually run of the mill HP or Dell workstation specced machines with a dual Xeon and tons of RAM.

"Pixar has a huge 'render farm,' which is basically a supercomputer composed of 2000 machines, and 24,000 cores. This makes it one of the 25 largest supercomputers in the world." Source: https://sciencebehindpixar.org/pipeline/rendering

Re: Rendering on the Apple M1 Max Chip

#134

Earlier quoted context omitted.

It's crazy that I can't get a bicycle chain for the next six months, but these chipsets are shipping?

> I can't get a bicycle chain for the next six months Why?

Supply chain chaos? I assume bike parts in the US come from overseas in shipping containers. One of my shifters broke in September and the local bike shop said they were out of parts and didn't expect to have any more until April 2022.

Re: Rendering on the Apple M1 Max Chip

#136
post #67
post #54

Earlier quoted context omitted.

The vast majority of developers will never even see assembly for x86 or ARM. Compiler developers and those need to hand optimize code may care but for everyone else it's a black box.

Sure but I am part of that latter category. The unwashed masses don't have to care and won't actually use the performance, I'm not that bothered whether they care or not, although it's worth saying that X86 is such a mess that hiding instructions at weird alignments is a valid obfuscation technique - i.e. it's not just aesthetics/performance.

Are there any easily digestible resources you could point to for getting a better grasp of this?

Re: Rendering on the Apple M1 Max Chip

#137
post #122

The problem with Apple is, and remains, the software, which I find utterly hostile and inflexible for my workflows, and getting worse by the year. Personally, I only consider getting one of these after it is able to a decent Linux distribution well.

Once the Asahi Linux folks get their work into Linux/mesa mainline, you will be able to run any distro on Apple M1. https://asahilinux.org/

I'm really looking forward to Asahi. These laptops + Linux are going to be pretty great.

Re: Rendering on the Apple M1 Max Chip

#138
post #119
post #2

> There’s really no way to understate what a colossal achievement Apple’s M1 processor is; compared with almost every modern x86-64 processor in its class On the other hand I'm sure there's more than a few chipheads out there who are saying "it's about time", there was a longstanding prediction that the arm architecture would overtake x86.

Yeah, your quote is a bit unfair to x86 - after all the x86 architecture is hampered by having to maintain compatibility not only with the original 8086, but also with most other instruction set extensions that Intel and/or AMD came up with during the last 40 years. Compared to that, the M1 is almost a "clean sheet" design. So, while still a great achievement, its dramatically better efficiency is not that surprising…

> So, while still a great achievement, its dramatically better efficiency is not that surprising.

Is it? I was under the impression modern CPUs translate x86 instructions do on the fly translation to something else anyway. I’d be very surprised if that hardware translation process was making their chips 4x less power efficient (or whatever the number is).

Also as a consumer, the reasons why x86 stayed around as long as it did sound like a bunch of excuses. If x86 is really as inefficient as you say, then it’s about time the industry started sidelining Intel and moving to a better architecture with or without them. I’m hoping AMD follows suit before long and starts selling competitive arm or risc-v chips.

Re: Rendering on the Apple M1 Max Chip

#139
post #127
post #29

I 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?

You've got a few flawed basis points in your math. 1) that forest isn't near the complexity of most major feature films. It's great, but it's got a ton of instancing, it's not got very complex shaders, it's not got very complex lighting. It's a good benchmark scene, but it's not approaching the level of scenes in most feature films. 2) You're assuming a single render happens per frame. Every scene in a movie is rende…

1. Instancing doesn't reduce the complexity of rendering a scene in terms of light transport, it only reduces the memory storage and Accel structure complexity.

Actually, a forest with occluding foliage geometry is a quite difficult light transport situation: it's very difficult for next event estimation to work efficiently, so therefore most of the lighting is indirect and therefore is quite noisy, as it's difficult to find the environment / IBL light for the sun.

Portal guiding and NEE guiding can help a bit, but it can still be quite slow.

Post reply on HN