New Apple Silicon

[Gavin Hird]

32 minutes ago, Nick0678 said:

Non SL related question and off topic. how well does crossover21 runs on it, have you checked?

Run on what? – Apple Silicon?

Generally Mac users respond very poorly to the suggestion of running Windows apps on their Macs. So that is not a solution, if that is what you ask. 

To the extent it actually runs, it will still be dependent on Rosetta2.

In theory a Windows version of the viewer could run in Windows 11 ARM version with x86 emulation in VMware Fusion for Apple Silicon, but Microsoft has so far said they will not support that in any way. 

Add to that, VMWare has said it will not take on the task of writing their own Intel emulation on Apple Silicon. (which for all practical purposes would require deep support from Apple).

Edited November 18, 2021 by Gavin Hird

[Gavin Hird]

4 minutes ago, RaffaeloMonastir said:

See my tests above...not that much promising 😞

It probably wont, unless the Rosetta2 emulated OpenGL can take advantage of all the GPU-cores. 

[Nick0678]

13 minutes ago, Gavin Hird said:

Run on what? – Apple Silicon?

Generally Mac users respond very poorly to the suggestion of running Windows apps on their Macs. So that is not a solution, if that is what you ask. 

To the extent it actually runs, it will still be dependent on Rosetta2.

In theory a Windows version of the viewer could run in Windows 11 ARM version with x86 emulation in VMware Fusion for Apple Silicon, but Microsoft has so far said they will not support that in any way. 

Add to that, VMWare has said it will not take on the task of writing their own Intel emulation on Apple Silicon. (which for all practical purposes would require deep support from Apple).

Ok so you don't use Crossover21, i want info from a user who uses it. Thank you for the reply.

[Gavin Hird]

3 minutes ago, Nick0678 said:

Ok so you don't use Crossover21, i want info from a user who uses it. Thank you for the reply.

I don't use it simply because it is a complete mess on macOS, and it is very difficult to get anything to run on it.

I have had reports that Linux users have successfully run my opensim Windows version viewer in Crossover or Wine.

[Nick0678]

7 minutes ago, Gavin Hird said:

I don't use it simply because it is a complete mess on macOS, and it is very difficult to get anything to run on it.

I have had reports that Linux users have successfully run my opensim Windows version viewer in Crossover or Wine.

Never mind i found a yourube video.Thanks.

 

[Gavin Hird]

17 minutes ago, Nick0678 said:

Never mind i found a yourube video.Thanks.

 

👍

Just to elaborate on that, afaik the difference is that on Linux, wine and crossover allows direct access to the GPU, so you get reasonably good OpenGL performance. On macOS it don't. It probably falls back to the Apple OpenGL CPU renderer.

[Nick0678]

28 minutes ago, Gavin Hird said:

👍

Just to elaborate on that, afaik the difference is that on Linux, wine and crossover allows direct access to the GPU, so you get reasonably good OpenGL performance. On macOS it don't. It probably falls back to the Apple OpenGL CPU renderer.

Never mind i wanted to know how Battlefront2 plays on the M1 pro.. It's shiite. Thanks

 

Edited November 18, 2021 by Nick0678

[anitabush]

28 minutes ago, Nick0678 said:

Never mind i wanted to know how Battlefront2 plays on the M1 pro.. It's shiite. Thanks

 

One of the cloud streaming services is probably a better bet if your connection is up to it.

The lack of bootcamp with the new chips is annoying.

[Cuga Rajal]

Follow-up to my last post, my friend uses a Windows laptop - AMD Ryzen 9 with a NVIDIA GeForce RTX 3070 - and we compared frame rates to my MBP 14" (M1 Max 10/32/32 32G RAM) with same settings in a number of enviros. Overall I'm getting about 70-80% the frame rate on the MBP compared to that. It isn't that fastest Windows laptop in the world but reasonably fast, and the Mac is running FS with Rosetta. The rendering code has always been more optimized for Windows anyway. 

I'm guessing the reason my Mac never heats up is that the renderer is single threaded. So it maxes out one thread and can never distribute the load to other processors enough to take advantage of speed increase and produce heat.

It's unlikely that the Mac world will ever see a native renderer written in Metal due to the amount of work required, however I'm hopeful something will be done using Vulkan, which could potentially be a lot less work. 

@RaffaeloMonastir - the "Open using Rosetta" option is only present for apps that have both ARM and x86 code (universal binary) -The Mac will default to the faster ARM option unless you check that box. This is not the case for Firestorm or any of the viewers, they only have x86 code, so they launch automatically with Rosetta2 or they don't run at all, and they don't include that checkbox.

Regarding Windows emulators, I've read that Parallels works quite well, and is currently the only Windows platform that runs on Apple Silicon. I don't think this is relevant though to SL or Opensim.

 

Edited November 18, 2021 by Cuga Rajal

[Gavin Hird]

46 minutes ago, Cuga Rajal said:

Regarding Windows emulators, I've read that Parallels works quite well, and is currently the only Windows platform that runs on Apple Silicon. I don't think this is relevant though to SL or Opensim.

 

Parallels have been peddling you can run Windows 11 for ARM in a VM, but Microsoft has said that is not an option you can buy from them or is supported, so there is something Hackintosh-ish dishonest about it.

Also Parallels don't have an Intel emulator running on Apple Silicon, and is even less likely to have one than VMWare. It is the emulation in Windows that has made it possible to run x86 Windows apps on their virtual machine. 

I have not been able to run any viewer in Windows on their Intel version due to poor OpenGL support. VMWare Fusion runs them reasonably well (all things considered). 

[RaffaeloMonastir]

1 hour ago, Cuga Rajal said:

Follow-up to my last post, my friend uses a Windows laptop - AMD Ryzen 9 with a NVIDIA GeForce RTX 3070 - and we compared frame rates to my MBP 14" (M1 Max 10/32/32 32G RAM) with same settings in a number of enviros. Overall I'm getting about 70-80% the frame rate on the MBP compared to that. It isn't that fastest Windows laptop in the world but reasonably fast, and the Mac is running FS with Rosetta. The rendering code has always been more optimized for Windows anyway. 

I'm guessing the reason my Mac never heats up is that the renderer is single threaded. So it maxes out one thread and can never distribute the load to other processors enough to take advantage of speed increase and produce heat.

It's unlikely that the Mac world will ever see a native renderer written in Metal due to the amount of work required, however I'm hopeful something will be done using Vulkan, which could potentially be a lot less work. 

@RaffaeloMonastir - the "Open using Rosetta" option is only present for apps that have both ARM and x86 code (universal binary) -The Mac will default to the faster ARM option unless you check that box. This is not the case for Firestorm or any of the viewers, they only have x86 code, so they launch automatically with Rosetta2 or they don't run at all, and they don't include that checkbox.

Regarding Windows emulators, I've read that Parallels works quite well, and is currently the only Windows platform that runs on Apple Silicon. I don't think this is relevant though to SL or Opensim.

 

Thanks Cuga, yeah I figured that as well out already that there is no dedicated switch to enable x86 emulation but that FS already runs on that.

Regarding Parallels: I installed a 14 day free trial with window 11 and tried with both FS and Catznip. But forget this. It is even much slower compared to the native Rosetta 2 emulation.

[Cuga Rajal]

Another follow-up for those who are interested in the results using Firestorm for x86 Mac on an M1 Max. Some here have told me they aren't getting the same performance as mine and I believe there are 2 factors that play significantly in the results:

- Close the lid and use a smaller pixel size display. I'm using an external 2560x1440 display (32") on HDMI2 with the laptop lid closed. The draw cycles are going to be significantly faster than the pixel size of the native screens that come with the new laptops. The 16" laptop has a 3456 x 2234 pixel size which will be significantly slower, all other things being equal.

- The new laptops' built-in screens also support 120Hz selective refresh rate, and the computer's negotiating the 60/120Hz display switching might also add load to the GPU. All my testing has been on an external monitor with a fixed 60Hz refresh.

- Recommend raising the Texture Cache and Asset Cache in Prefs -> Network & Files -> Directories much higher than their defaults. Recommend 8G each.

Correction regarding the fan: Although I wasn't aware of the fan being on, I ran a fan monitor program and found that during the highest load (Ultra graphics, crowded venues) the fans were running at 50% capacity (~3k rpm) and keeping the CPU/GPUs in the 75-80C range. I just couldn't hear them, the fan is amazingly silent.

 

[uk89201]

On 11/18/2021 at 6:42 PM, RaffaeloMonastir said:

Disk-Cache: Max size 2048.0 MB (100.0% used

Did spot this in your specs and wondered if @Cuga Rajal’s suggestion on increasing cache size helps?

Edited November 28, 2021 by uk89201

[WackyIraqi Gonzales]

On 11/18/2021 at 12:11 AM, Gavin Hird said:

There is no Apple Silicon native OpenGL, so the viewer will not compile at all. 

In addition, there is a dependency of a lot of rather old libraries, many of which most likely will not compile on Apple Silicon without significant updates.

Well, I was able to compile it on an M1 mac after jumping through a few hoops.

First, I couldn't use autobuild to generate the project files. Not surprising since autobuild (or cmake?) doesn't seem to recognize ARM or that it is 64 bits. I'll look into it at some point but I just wanted to build the dang thing.

Using Rosetta2 I was able to get autobuild to spit out a darwin-x86-64 project. Progress! Autobuild wouldn't actually build the project so I tried the manual way by using Xcode and (after suppressing/fixing a few errors) I was able to get it to compile, run, and login.

Edited May 4, 2022 by WackyIraqi Gonzales

[Gavin Hird]

3 hours ago, WackyIraqi Gonzales said:

Well, I was able to compile it on an M1 mac after jumping through a few hoops.

First, I couldn't use autobuild to generate the project files. Not surprising since autobuild (or cmake?) doesn't seem to recognize ARM or that it is 64 bits. I'll look into it at some point but I just wanted to build the dang thing.

Using Rosetta2 I was able to get autobuild to spit out a darwin-x86-64 project. Progress! Autobuild wouldn't actually build the project so I tried the manual way by using Xcode and (after suppressing/fixing a few errors) I was able to get it to compile, run, and login.

 

Congratulations!

Autobuild is a python app and runs fine on both Intel and AS (Apple Silicon) Mac. It does require python 2.7 so you need to get that installed via macports.org  2.7 is possibly an Intel only implementation that runs in Rosetta2, but newer version 3.x are AS native.

I too compile the viewer on AS, but it only spits out an Intel version, which will run in Rosetta2 on AS, and of course normal on Intel based Macs. 

To compile the viewer native for AS as it is, is a hopeless task, first of all because, as I said before, there is no AS native implementation of OpenGL, and then you have all the libs + the code itself. OpenGL is only available in Rosetta2.

[ST33LDI9ITAL]

On 5/4/2022 at 2:20 AM, Gavin Hird said:

To compile the viewer native for AS as it is, is a hopeless task, first of all because, as I said before, there is no AS native implementation of OpenGL, and then you have all the libs + the code itself. OpenGL is only available in Rosetta2.

That isn't true at all. Apple does provide native OpenGL lib that support <= OpenGL 4.1 that runs on a Metal compatibility layer similar to MoltenVK and is accessible to C++. There are plenty of native apps that use OpenGL under the hood. Porting whatever libs that SL viewer uses that don't have an ARM package would be the only real issue. 

It's far form a "hopeless task" and necessary if they wish to support Mac moving forward. The larger issue is supporting Metal which depends on if they go forward with a Vulkan renderer in the future or decide to do secondary renderer for Mac is up to them. Porting to Vulkan alone isn't going to magically improve the performance of the viewer though, it will just offer them better support and a path to move forward on... For performance, it's going to take some real effort in profiling and refactoring to better take advantage of multi threading/core and non blocking techniques to better structure the viewer as well as some more efficient rendering lod and streaming asset support.  Currently it's very congested as can be seen in animations and GUI while under stress.

Edited May 7, 2022 by ST33LDI9ITAL

[Gavin Hird]

On 5/7/2022 at 8:23 PM, ST33LDI9ITAL said:

That isn't true at all. Apple does provide native OpenGL lib that support <= OpenGL 4.1 that runs on a Metal compatibility layer similar to MoltenVK and is accessible to C++. There are plenty of native apps that use OpenGL under the hood. Porting whatever libs that SL viewer uses that don't have an ARM package would be the only real issue. 

It's far form a "hopeless task" and necessary if they wish to support Mac moving forward. The larger issue is supporting Metal which depends on if they go forward with a Vulkan renderer in the future or decide to do secondary renderer for Mac is up to them. Porting to Vulkan alone isn't going to magically improve the performance of the viewer though, it will just offer them better support and a path to move forward on... For performance, it's going to take some real effort in profiling and refactoring to better take advantage of multi threading/core and non blocking techniques to better structure the viewer as well as some more efficient rendering lod and streaming asset support.  Currently it's very congested as can be seen in animations and GUI while under stress.

There are some Apple native apps that still use OpenGL, but the OpenGL compatibility layer is running in Rosetta2 for as long as Apple allows Rosetta 2 to exist. If they are as fast to axe it was they were with Rosetta in the PowerPC to Intel transition, both Rosetta 2 and OpenGL could go in macOS 16, to be announced at WWDC2022.

Even if the compatibility layer may support some OpenGL features up to 4.1, the only two OpenGL profiles you can set for an application to use are NSOpenGLProfileVersionLegacy  and NSOpenGLProfileVersion3_2Core, but the latest one cannot be used by the viewer till all the BOOL clutter is removed completely.

It is not possible to call OpenGL features that may exist in hardware on existing Macs directly from code. If you do, you will get the software renderer. So even if all currently supported Intel Macs supports OpenGL 4.1 in HW, it means jack to the developer. Apple Silicon GPUs don't support OpenGL in HW at all. 

Vulkan and MoltenVK is a dead end on macOS both because MoltenVK is a subset of Vulkan, and because it has no official support by Apple at all, it is doomed to run in user space with no chance of Apple signing any drivers to let it tap directly into the HW and gain full performance. Apple can also easily kill it by simply refuse to sign it. 

The reason why I say it is a "hopeless task" is not because it cannot be done, but because the current approach is a "hopeless task", procrastinating fixing even the most pressing issue in the macOS version of the viewer to transition it to a reality without OpenGL.

The Metal libraries are only compatible with Objective-C and Swift, meaning that on macOS the viewer must become a full fledged Objective-C++ application to take advantage of the existing codebase. The alternative is to rewrite in Swift, which is not an alternative in the real world. 

EDIT: To clarify, there exist a NSOpenGLProfileVersion4_1Core, but it gives you a pure CPU renderer.

EDIT2: It looks like NSOpenGLProfileVersion4_1Core giving a CPU renderer was fixed in macOS 10.12, but as the Apple developer documentation states, selecting it does not give you the OpenGL 4.1 implementation that exist in hardware support on the graphics card, but Apple's implementation of 4.1 including their omissions, additions and own extensions. Trying to directly address the HW will still give you a fallback CPU renderer.

Edited May 9, 2022 by Gavin Hird

[ST33LDI9ITAL]

I'm not sure wtf you're going on about... but it doesn't take any time at all to setup or snag an opengl boilerplate to test. You can build native, on apple silicon, in c++, without rosetta, the performance is fine, it uses metal (as everything else that uses gpu does, so uses gpu)...

If you need more extensions than ones supported natively then you could try something like MGL project which provides some conformance upwards to OGL 4.6 wrapping OpenGL > Metal, although untested. 

MoltenVK is fine for what it is, very performant, and will only get better with time.

There is absolutely C++ access to Metal...

Wrappers and translations to gpu drivers are a very common thing... it's abstraction..
Apple has Metal, Windows has DirectX, Vulkan, OpenGL, etc.. they all have abstractions to access them in various ways. Nothing wrong with user space translations or wrappers. 

 

Edited May 11, 2022 by ST33LDI9ITAL