Author Topic: Corona for Apple Silicon M1?  (Read 46199 times)

2022-02-27, 09:51:49
Reply #75

Philw

  • Active Users
  • **
  • Posts: 273
    • View Profile
8 minute mark screengrabs attached!

2022-02-27, 17:03:35
Reply #76

jojorender

  • Active Users
  • **
  • Posts: 264
    • View Profile
Hi Philw,
Thanks for running this test.
I ran the test again set to your 4.2% noise level. Strangely it finished in 3:30
I assumed the M1max is faster than my 10850K.
Did you have any demanding things running in the background?
The only difference I can see from your screenshot, your build is Feb. 16 and I’m on Feb. 1
Any idea what’s going on?

Don't worry about Team Render. That brings with it too many other variables to be useful as a "how good is my CPU at rendering a real job?" question.
You’re definitely right about “too many variables”, but still can help deciding if replacing cheap render nodes with a ripper is worth it.

2022-02-27, 18:20:29
Reply #77

Philw

  • Active Users
  • **
  • Posts: 273
    • View Profile
Nope - nothing taxing - and after a reboot too to flush its brain.

I think its a combinaton of things:

  • Conservative Processor usage (even when switched to high power mode) (Apple flying the "it uses no power flag") - The efficiency cores are always maxed out - the performance cores maybe 75% so
  • Early days
  • Non-trivial to program/non-optimised rendering libraries that have had years of Intel nurturing - early adopters on M1? (For instance, Arnold still hasn't dipped its toe into Apple Silicon - guessing here of course, I'm certainly not informed
  • Early days again

2022-02-27, 20:12:43
Reply #78

jojorender

  • Active Users
  • **
  • Posts: 264
    • View Profile
Interesting… So instead of Intel’s thermal throttling, there might be a apple imposed performance throttle.
   
While the M1max was about 14% faster in the grapes c4d physical scene, it was about 56% slower in Corona native M1.
Not sure what this all means, but might be helpful info for the corona team.

Out of curiosity, I TR’ed this scene with 2x 10c/20t + 1x 8c/16t (closest I can get to your 32c/64t) set to your rippers 403 passes.
Took 8:52. This result makes sense.

2022-02-27, 21:23:01
Reply #79

Philw

  • Active Users
  • **
  • Posts: 273
    • View Profile
More wierdness... Didn't use VFB - direct to PictureViewer (prefs set to 4.2% noise)... all cores maxed out this time... a bit better at 4:25.

But then set it to high power mode... and it was slower :-(

« Last Edit: 2022-02-28, 06:19:53 by Philw »

2022-02-27, 21:45:04
Reply #80

jojorender

  • Active Users
  • **
  • Posts: 264
    • View Profile
I would say that's a LOT better!
Definitely strange that the VFB might throttle performance.
Maybe other M1 users can confirm this?   

2022-02-28, 16:54:33
Reply #81

BigAl3D

  • Active Users
  • **
  • Posts: 914
    • View Profile
I'm getting confused about how you guys are testing. I see one post about setting the passes to 403. I see another that appears to be set to 8 min. Then the 4.2%. I'd like to add to this, but not sure which one we're doing now.

2022-02-28, 17:07:01
Reply #82

Philw

  • Active Users
  • **
  • Posts: 273
    • View Profile
Originally its an 8 minute run to see what noise level we get down to. My M1Max got down 4.2% on that experiment in VFB. Since then - bypassing VFB and going direct to Picture Viewer it has gone faster considerably. We should stick to the 8mins and see what noise level we get down to.

2022-02-28, 18:45:24
Reply #83

jojorender

  • Active Users
  • **
  • Posts: 264
    • View Profile
I picked the 8min mark on the M1max to find a noise or pass level that is challenging enough and doesn’t take too long to test.
Ultimately, this test is to find out how Apple Silicon compares to Intel/AMD in a “real world” scenario.
Since there’s such a big difference in render time with VFB on or off and also the macOs power settings, maybe it’s best to first figure out what’s going on there, before setting test parameters?

@Philw is there any difference when rendering to PV, opening VFB to establish the connection and closing VFB again? Or you only get the faster times after c4d restart and no connection between PV and VFB?

2022-03-01, 15:28:01
Reply #84

Philw

  • Active Users
  • **
  • Posts: 273
    • View Profile
Just fairly random differences between the two methods and flipping into VFB didn't seem to make any difference or sense. I even got different noise levels squeezed into the 8 minutes both in VFB and PV modes - I'm putting it down to the machine maybe being busy with other things (but nothing obvious) or just overall weirdness. Might even just be a Monterey thing.

2022-03-09, 11:55:21
Reply #85

ianosss

  • Active Users
  • **
  • Posts: 83
    • View Profile
Anyone getting the new Mac Studio M1 Ultra? Would love to see some benchmarks. :)

2022-03-20, 00:24:03
Reply #86

piredude

  • Users
  • *
  • Posts: 3
    • View Profile
Model Name:    Mac Studio
Model Identifier:   Mac13,2
Chip:   Apple M1 Ultra
Total Number of Cores:   20 (16 performance and 4 efficiency)
Memory:   64 GB

Noise Level Limit set to 4.2, running Corona 8 daily.

2022-03-20, 20:58:11
Reply #87

frv

  • Active Users
  • **
  • Posts: 412
    • View Profile
No idea if this is fast. Grainy after two minutes at low res.

2022-03-20, 23:10:46
Reply #88

jojorender

  • Active Users
  • **
  • Posts: 264
    • View Profile
Let's find out if this is fast,
Philw can you pour some gasoline into your ripper and run it to the same 4.2% noise?

frv is right, maybe we should run this test at a more real world rez like 4k/ 3% noise?


2022-03-21, 02:52:00
Reply #89

BigAl3D

  • Active Users
  • **
  • Posts: 914
    • View Profile
Just for comparisons sake. Here's my test including my render settings to make sure I did it right. This was rendered in r20. I then rendered it in r25 and saved 3 seconds. I then copied all the parts of the scene and pasted into a brand new r25 scene. Saved another 3 seconds. I find it always best to paste everything from an old scene, into a fresh scene. Avoids some weirdness, plus a little bit faster.