Viewer on Apple M3, M3 Pro, M3 Max CPUs

[martinmoun]

Hello,

since the thread on the M1 and M2 has been closed, allow me to follow up here with an update.

Does anyone of you have first experiences with SL on the new M3, M3 Pro or even M3 Max Machines?
If so, it would be nice if you added your amount of RAM too.

 

 

 

Edited November 21, 2023 by martinmoun

[Gavin Hird]

From reviews it looks like the M3 in general use more GPU memory which comes from the unified memory, so you might want go for a 16 GB configuration if you plan to run other apps concurrent with the viewer or go to locations that are packed with content and / or avatars. If you only run the viewer in locations with low and medium content or few avatars, a 8 GB config should do plenty fine.

Even if the viewer does not take advantage of hardware ray tracing and mesh upscaling, the GPU looks like it reserves a bit more memory to support these features. The more GPU cores in the machine, the more pronounced this might be. 

[Crash Sewell]

I have a 16inch M3 Max MacBook Pro 16 cores CPU, 40 cores GPU and 48 of ram. Have not had much time to be on SL but I did a couple hours. I was on DD of 128, and one step below ultra.

My observations:

Frame rate alone at my Elysion home ran 120+ fps. With my partner it dropped to 90-95+. Out shopping with about ten others near me it bounced around 40 to 90 fps. Went to Muddy's with 60 avatars around me. Cammed around and was able to get it to drop to 20 fps with everyone in the picture. Zoomed more on me it was a decent 40+ fps.

I never heard my fans come on.. but I had music on... tho not loudly. My MacBook got warm to the touch in a few places, but not hot.

Compared to the late 2019 Intel MacBook it replaced: Beautiful screen, stunning colors. Could certainly hear the fans on my old MacBook pro, and it got decently hot. FPS seems maybe 4X+ better on my new MacBook pro in moderately busy areas.

I am quite happy with my new machine in SL ... but I certainly didn't buy it for SL.

[Randy Pole]

I recently updated to an M2 Pro (16GB) as quite frankly the M1 with only 8GB was a mistake - never ever opt for the 8GB models.

It's good to see that performance on the M3 chips are on par (if not even better) but we have to remember that the performance is being hampered by having to run through the Rosetta 2 compatibility layer. What I would love to see is some serious work done by LL (and Apple if wishes were real) to get genuine native support libraries and apps for SL.

It's super that the M3 is better in performance but that was to be expected  

Despite performance of SL being poorer on my M2 machine than the MSI Laptop I have with an RTX4070 I prefer using the M2 because it is so darn quiet! You do not notice how loud PC fans are until you use a machine that does not have to use them so much.

I am looking forward to continued development and support of SL on the MacOS platform but at the same time I have a a sliver of worry over the whole GL/Metal thing and what that may mean for the future.

Edited November 24, 2023 by Randy Pole

[martinmoun]

10 minutes ago, Randy Pole said:

IIt's super that the M3 is better in performance but that was to be expected  

It's expected that the Mx CPUs provide a better performance. I'm keen to know "how much" (significantly?) better SL performs on them. With this posting I'm trying to find out.

Thank you for your feedback

Edited November 24, 2023 by martinmoun

[Randy Pole]

Performance of any system in SL is a tricky one. A state of the art system can provide blinding fps in one place and average to awful in another thanks to textures, complexity and heaps of other stuff.

Best bet would be to locate a suitable place, provide the SLURL and then people with various versions can provide stats based upon various draw distances and settings?

[Erik Kundiman]

4 hours ago, Randy Pole said:

I recently updated to an M2 Pro (16GB) as quite frankly the M1 with only 8GB was a mistake - never ever opt for the 8GB models.

It's good to see that performance on the M3 chips are on par (if not even better) but we have to remember that the performance is being hampered by having to run through the Rosetta 2 compatibility layer. What I would love to see is some serious work done by LL (and Apple if wishes were real) to get genuine native support libraries and apps for SL.

I happen to have got a friend with an M1 & 8GB, who has tested a native macOS arm64 build for me (I don't have any Apple Silicon mac). From the image, you can see his mac's specs, though the floater doesn't say anything about whether it's native or through Rosetta 2 (but it is native, one could run the file or lipo command on any of its binaries to confirm).

The thing is, he said running the native one didn't feel any faster than running its x86-64 counterpart emulated. There hasn't been any special effort to further improve the performance on Apple Silicon, let alone any macOS architecture, indeed. He had the graphics level set to High, and his movements were still okay. It could reach a slightly higher FPS than the SL viewer when rendering with more or less the same quality (and much higher at some other time but I think the graphics quality was being affected), but on SL viewer it was heavier.. at least according to his reports. I think the graphics quality on SL viewer is still better, nevertheless.

So it's either Rosetta 2 is that good, or the arm64 binary results from the cross-compiling are somehow not good enough yet 🙃

[Henri Beauchamp]

10 hours ago, Erik Kundiman said:

I happen to have got a friend with an M1 & 8GB, who has tested a native macOS arm64 build for me

I am curious about how he got a native macOS ARM build (and how truly ”native” too)... The viewer contains SSE source-level code that can only be ”translated”/adapted via specific libraries (such as sse2neon), and he would have had to rebuild for ARM64 all the third party libraries used by the viewer as well... This is totally doable, and a couple contributors to my viewer and myself did it (for Linux only, so far). But it is not trivial either.

However, AFAIK (but I am not a Mac specialist, by far: I do not even own a Mac and just toyed with Hackintosh x86_64 virtual machines, which cannot even run a viewer, but can still build it), there is no access to the OpenGL API for native ARM64 macOS builds, making it even more complex a task to compile a truly native SL viewer for macOS Silicon... So this gets me even more curious/perplex... 🤔

 

10 hours ago, Erik Kundiman said:

The thing is, he said running the native one didn't feel any faster than running its x86-64 counterpart emulated.

This is because, under ARM64 macOS, the bottleneck will be at the OpenGL emulation level, not at the C++ code one (be it ran from native aarch64 binary, or ”translated” via Rosetta from x86_64 to aarch64).

Note also that Rosetta is not exactly an emulator: it is a dynamic binary code translator, taking a x86_64 piece of code it runs for the first time, translating it into its aarch64 (ARM64) counterpart, and then running the said translation for any further occurrence of that same piece of code: this is extremely efficient for speed (waaaaay less for memory consumption) after the first run (and you do not really care about the high inefficiency of the first translation run for pieces of code that will never be ran again). The same kind of translator exists under Linux (e.g. Box86 and Box64).

Edited November 25, 2023 by Henri Beauchamp

[Erik Kundiman]

10 hours ago, Henri Beauchamp said:

I am curious about how he got a native macOS ARM build (and how truly ”native” too)...

He got it from me! 🥳

Cause I can't test it myself.

I guess I've only been relying on the info as shown on the attached image (can also be done from a non macOS) to be able to tell the architectures.. I haven't done any further investigations.

 

10 hours ago, Henri Beauchamp said:

The viewer contains SSE source-level code that can only be ”translated”/adapted via specific libraries (such as sse2neon)

Yes! It's been such a handy library. 😀

 

10 hours ago, Henri Beauchamp said:

This is totally doable, and a couple contributors to my viewer and myself did it (for Linux only, so far). But it is not trivial either.

Ah yes, I've read about it.. Well done! 🙌

 

10 hours ago, Henri Beauchamp said:

This is because, under ARM64 macOS, the bottleneck will be at the OpenGL emulation level, not at the C++ code one (be it ran from native aarch64 binary, or ”translated” via Rosetta from x86_64 to aarch64).

Ah! It makes much more sense now. Thank you!

 

10 hours ago, Henri Beauchamp said:

Note also that Rosetta is not exactly an emulator: it is a dynamic binary code translator, taking a x86_64 piece of code it runs for the first time, translating it into its aarch64 (ARM64) counterpart, and then running the said translation for any further occurrence of that same piece of code: this is extremely efficient for speed (waaaaay less for memory consumption) after the first run (and you do not really care about the high inefficiency of the first translation run for pieces of code that will never be ran again).

So much for the efforts to get a running native build, then.. 🥲

Edited November 25, 2023 by Erik Kundiman

[Gavin Hird]

21 hours ago, Erik Kundiman said:

he said running the native one didn't feel any faster than running its x86-64 counterpart emulated.

 

The limiting factor is not so much the CPU, but OpenGL on Apple Silicon. Because it is deprecated and will be removed, Apple has put in only minimal effort to make sure it runs. 

Both the Intel Rosetta and native OpenGL essentially runs in the same process on Apple Silicon. 

[Gavin Hird]

13 hours ago, Henri Beauchamp said:

This is because, under ARM64 macOS, the bottleneck will be at the OpenGL emulation level

OpenGL does not run as emulation.

Apple's OpenGL implementation has always been they have full control of the OpenGL implementation, and the graphics card vendors were only allowed to supply a thin HAL to the graphics card hardware. – Which is why the fallout with NVIDIA, which did not accept this model and wanted to implement their own OpenGL stack fully on macOS.  (HAL = hardware abstraction layer)

So the OpenGL stack is basically the same as it always was, but this time with a HAL to the Apple Silicon GPU. They have made no particular attempt to optimize it. 

Edited November 25, 2023 by Gavin Hird

[Henri Beauchamp]

1 hour ago, Gavin Hird said:

OpenGL does not run as emulation.

It does, sort of, for Apple Mx, since those GPUs were only designed to run Metal, with an entirely different architecture as what a GPU designed for OpenGL can do. You end up with ”translated” OpenGL primitives into ones that can be implemented with Apple's custom GPU hardware architecture...

OpenGL has always been implemented like utter sh*t by Apple, resulting in extremely poor performances for OpenGL apps on Apple hardware, while the latter usually got quite capable CPUs and GPUs...

Beside, and AFAIK, there is not even a native aarch64 OpenGL driver for Mx... But I could be wrong here.

Edited November 25, 2023 by Henri Beauchamp

[Henri Beauchamp]

5 hours ago, Erik Kundiman said:

So much for the efforts to get a running native build, then.. 🥲

The effort is not vain, by far: even though Rosetta does a good job running x86_64 apps at decent speed, it cannot perform as good, when it translates x86_64 optimized code into aarch64 code, as what a proper optimizing compiler would obtain when compiling from sources into aarch64 binary...

For the SL viewers, however, and since they use OpenGL, and since the latter is implemented like sh*t by Apple, the bottleneck at the GPU level is what drives their performances, far more than the C++ code optimization level.

[Dov Watanabe]

On 11/24/2023 at 1:18 AM, Randy Pole said:

Best bet would be to locate a suitable place, provide the SLURL and then people with various versions can provide stats based upon various draw distances and settings?

Love this idea, as it would provide us with some baseline comparisons between different Apple Silicon-based systems. Does anyone here have an idea of where would be a good place to run something like this?

Thanks for this discussion, all!

[Crash Sewell]

Baselines seem like a good idea. But aren’t they really a fools errand? FPS varies wildly for me at most locations ( but still good to great). On my exact same computer, with exact same settings. Then try to account for all the variables between machines and the environmental ones and the seemingly completely random ones. Good luck!

Instead, my take is… my M3 max MacBook Pro is performing great in SL. Brute force… or whatever. Now, finally … it just works. FPS is no longer an issue. The environments are beautiful. Immersion is so much better. I don’t have the expertise of Henri or you others. I hope y’all can make improvements in the Mac experience. But for me, for now, there is no longer an issue.

[Brian Aviator]

1 hour ago, Crash Sewell said:

Baselines seem like a good idea. But aren’t they really a fools errand? FPS varies wildly for me at most locations ( but still good to great). On my exact same computer, with exact same settings. Then try to account for all the variables between machines and the environmental ones and the seemingly completely random ones. Good luck!

Instead, my take is… my M3 max MacBook Pro is performing great in SL. Brute force… or whatever. Now, finally … it just works. FPS is no longer an issue. The environments are beautiful. Immersion is so much better. I don’t have the expertise of Henri or you others. I hope y’all can make improvements in the Mac experience. But for me, for now, there is no longer an issue.

I see the same.   I have the M3 Max MacBook Pro 16in (16 core CPU, 40 core GPU config) with 64GB of RAM. On my previous M1 Max machine I wouldn't do any serious building or other work because of performance issues. I no longer have such issues and think nothing of building or doing things in SL that would previously require me to wait until I am on my PC.

I am hoping that a Vulkan/MoltenVK viewer is still in the works however as I bet it will run quite well on the M3 Max machines.

[Gavin Hird]

13 hours ago, Brian Aviator said:

 

I am hoping that a Vulkan/MoltenVK viewer is still in the works however as I bet it will run quite well on the M3 Max machines.

It will not run well on any M-series processor, if at all in the future.

Apple ditched OpenGL because they don't want any dependency of Chronos in their hardware and software development, which is why there will not be any Vulkan support in the first place. MoltenVK is a subset of Vulkan which not only Vulkan calls must be translates to, but again be translated into Metal that is not constructed for running these calls.

As Metal evolves, like the extensive additions added to Metal 3 to support the upcoming 3D headset, in combination with removal of OpenGL support, there is no guarantee anything developed with the combination Vulkan/MoltenVK will run on future macOS versions. So developing to this combination is pure stupidity if you want to keep your app running on Apple hardware in the future.

An added complication is that Metal is a tile based renderer that is rather different in the approach to rendering a scene compared to OpenGL and Vulkan. 

[Gavin Hird]

21 hours ago, Henri Beauchamp said:

It does, sort of, for Apple Mx, since those GPUs were only designed to run Metal, with an entirely different architecture as what a GPU designed for OpenGL can do. You end up with ”translated” OpenGL primitives into ones that can be implemented with Apple's custom GPU hardware architecture...

OpenGL has always been implemented like utter sh*t by Apple, resulting in extremely poor performances for OpenGL apps on Apple hardware, while the latter usually got quite capable CPUs and GPUs...

Beside, and AFAIK, there is not even a native aarch64 OpenGL driver for Mx... But I could be wrong here.

OpenGL on Apple Silicon versions runs in a system extension that is launched from /System/Library/Extensions/AppleMetalOpenGLRenderer.bundle which has arch x86_64 and arm64e so there is a native implementation of it. I assume the x86_64 version is invoked by the SL viewer that is compiled to x86_64 and running under Rosetta 2.

This extension is not installed on Intel based Macs, but rather /System/Library/Extensions/AppleParavirtGPUMetal.bundle and /System/Library/Extensions/AppleParavirtGPU.kext which is a kernel extension

 

[Henri Beauchamp]

34 minutes ago, Gavin Hird said:

Apple ditched OpenGL because they don't want any dependency of Chronos in their hardware and software development

Another stupid stance by Apple... Not the first, sadly, and likely not the last such stupid stance either, dishearteningly...

[Gavin Hird]

42 minutes ago, Henri Beauchamp said:

Another stupid stance by Apple... Not the first, sadly, and likely not the last such stupid stance either, dishearteningly...

They make the decisions they make, so if you want to be on their platforms, it is probably wiser to take advantage of what they actually support and supply, rather than trying to disprove them.

[Henri Beauchamp]

48 minutes ago, Gavin Hird said:

if you want to be on their platforms

Good news: I don't ! 😜

[Gavin Hird]

4 hours ago, Henri Beauchamp said:

Good news: I don't ! 😜

Yet you keep plugging at it 😉

[Henri Beauchamp]

25 minutes ago, Gavin Hird said:

Yet you keep plugging at it 😉

Can't help it: I'm of the ”plug and play” type... 😛