Prices of CPUs are horrible. Perhaps I am stupid, but the price for fabrication of a xeon/threadripper and a GPU should be the same as long as they have the same physical size and same node so either it is IP costs (licensing) or just poor competition in the CPU market that explains the price. I think it is the latter.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
3D Rendering on Apple Silicon, CPU&GPU
- Thread starter vel0city
- Start date
- Sort by reaction score
It’s all round horrible in tech ATM, not just CPUs and GPUs. But yeah, once more factories come online, things might ease up..might. Because you can never have enough compute power..not the way data is exploding exponentially
Things are not exactly like this
About path tracing, well.. thanks God modern engines uses every sort of trickery to avoid that the light emitted by a light bulb travels kilometers away, that will result in immense computing time. Once a ray reach a certain threshold and do not contribute to the scene significantly is cutted away.
About memory usage, only progressive rendering needs to keep all the assets loaded on memory every time, Vray bucket sampler for example can split the scene into smaller parts and assign every part to a CPU thread or a GPU, this will save RAM since not all assets needs to be on memory constantly and can also be loaded and unloaded on demand depending on what the bucket is rendering. Incidentally bucket rendering not only consumes less RAM, is also a bit faster than progressive rendering.
Buckets are ways of batching individual samples that have absolutely nothing to do with splitting up the scene itself (but may aid cache coherence because rays that are coherent when fired are likely to remain somewhat coherent)
The amount of memory used at this stage is trivial compared to the scene itself.
It's like I said, if you can fit the scene in memory, then the task becomes embarrassingly parallel and you can delegate individual samples to as many GPUs or CPUs as you like. The problem comes when the scene itself doesn't fit in memory.
Well they can do (hello micropolygon renderers) but I guess probably a thing of the past
Much of the time the difference between fitting things in memory or having epic render times comes down to fairly trivial optimisations. You can be rendering billions of polygons, thousands of lights and hundreds of textures on relatively little memory just through some good optimisation - had render times for some shots go from 24hr a frame to ~1hr just by giving the lighting to someone who knew how to optimise well for the render engine (bit of instancing, mipmapped textures, optimising ram usage etc).
Speaking of real time, always been impressed and moderately perplexed by the optimisations that go in game dev and getting everything working in real time from lighting to asset prep - it's a really next level form of cheating.
Remember seeing some of a presentation on that; was pretty crazy and the scene looked awesome. Filed it under the Pixar's gonna Pixar by doing something crazy just because they can, much like deciding to render all the grains in Piper as instances with SSS. It looked amazing, but still…crazy.
I was really bummed for a minute when, whilst moving to a new house, I lost my VHS promo copy of Geri's Game I picked up at the Pixar booth at Siggraph in 1996...
Building refractive caustics:
Is one of the many attempts to compute this class of rays quickly, my experience tells me that no matter what you use, easy refractive caustics methods are always slow when it comes to render real scenes.
Is one of the many attempts to compute this class of rays quickly, my experience tells me that no matter what you use, easy refractive caustics methods are always slow when it comes to render real scenes.
There are essentially two ways of path-tracing: "Forward tracing" which is similar to how things work in reality. You fire rays from lights, bounce them around the scene, and when they hit the "film" of your camera, you mark the light contribution.
The issue with this is that as you can imagine, 99% of rays don't hit the camera which is a huge waste, which is why the standard way of doing things is backward tracing, where you start from the camera and bounce around the scene until you hit a light.
This suffers from the opposite problem, where most rays don't actually hit the light. This isn't a huge problem for surfaces because you can use probability distributions, but for stuff like caustics it's a huge problem.
You can try to do caustics by tracing in both directions and then combining the result, but it tends to be slow and noisy. An algorithm like MNEE, tries to give the light rays a helping hand a bit like an aim-bot, so if the ray almost hits something interesting like a light, MNEE will "fix" its aim and shoot the bounce directly at the light.
Still feel that baking caustics is probably the way to go. I don't think any renderer really has good non-baked caustics that renders reasonably (although I think the new version of Octane was boasting massive improvements there).
The practice use case for MNEE is blood sweat and tears (usually what rendering caustics leads to
); it seems primarily designed for the small scale refractive caustics you get in droplets of liquid, or the meniscus at the corner of the eye. I think Renderman has had it since v22 (I vaguely ILM talking about it being used in one of the Star Wars films).
Beat me to it...! ;^p
Am I wrong, or are these three the apps that have been assisted by Apple in some way to become ASi / Metal native...?
I guess all the other 3D DCC apps are taking a wait and see approach to optimizations...?
If I'm not wrong it's not native yet.
From Beppe (of Otoy) on the Octane X forum, december 08:
"Hi,
PR13 is working here, under macOS 12.0.1, and C4D R25, if Open with Rosetta is enabled."
And it's not really stable, also denoiser still not working on M1.
I just received my M1Max MBP, I haven't installed Octane X yet, I'll see how it behaves, but I'm not very confident, Octane X has just been a mess till now...
Last edited:
It depends what you mean by native I guess. Vray appears to be compiled for ARM but doesn't support GPU rendering on macOS. Octane X appears to be using Rosetta, but uses Metal / GPU rendering.
Am I the only one tired to see this sterile YouTubers regurgitating always the same benchmarks? Why nobody shows real world tests on real production scenes? I’m wondering if all those people are actually working on their device or they are just interested in benchmarking software...
Out of curiosity, what kind of benchmarks would you like to see?
The viewport performance is as important as the rendering performance, but I can imagine it is much harder to test it.
The problem is that unlike most manufacturers Apple doesn't send out review units (except maybe to a handful of mega YouTubers). That means specialist 3D YouTubers don't get review units, and they aren't going to buy them with their own money because a) They aren't very good for 3D, and b) their audience isn't going to watch multiple Mac videos.
The only YouTubers who are buying M1 Max / Pro machines for making videos will be tech channels with an audience of Apple fans who can make 25 different videos with a single machine.
The only YouTubers who are buying M1 Max / Pro machines for making videos will be tech channels with an audience of Apple fans who can make 25 different videos with a single machine.
The AL labs test scene would be a good one. Opens in most dcc apps from Blender to Maya and uses production assets.
Not going to work for GPU renders though
will render in anything that supports usd and is a good viewport benchmark.
Animal Logic's USD ALab
Find out more about Animal Logic's USD ALab: an open source scene interpretation and implementation of production and pipeline concepts.
Nice thanks for sharing.
I was trying to find out some more about any possibility of Metal API support for the Substance apps on macOS the other day, so I tagged Sebastien DeGuy, Adobe VP of 3D and founder of Allegorithmic in a Tweet. Happily he replied saying: "Hehe sorry about the lack of info. We are indeed working on it. I have seen things
a little bit more time and we should be able to share native / close enough versions soon!"Very exciting!
They release a native version with metal support and I would upgrade my steam license that dayNice thanks for sharing.
I was trying to find out some more about any possibility of Metal API support for the Substance apps on macOS the other day, so I tagged Sebastien DeGuy, Adobe VP of 3D and founder of Allegorithmic in a Tweet. Happily he replied saying: "Hehe sorry about the lack of info. We are indeed working on it. I have seen things
Very exciting!
Something with lots of glass (transparent with different refraktions indexes) and metal reflections. Also lots of objects (transparent of course). Looking forward to benchmark an M1 Pro towards my 2020 iMac.The AL labs test scene would be a good one. Opens in most dcc apps from Blender to Maya and uses production assets.
Not going to work for GPU renders though