Gavin Hird

Sounds like you have your hobby cut out in front of you. There are about 1.3 billion active Apple users out there for you to convince. 🤣

There probably won't be a Metal API update till OpenGL support is removed from the system. We shall see what is being announced at WWD2022 scheduled for June 6 through 10. They may cut it this year or give it another year depending on for how long they want to keep Rosetta2 translation around (which it depends on). At the previous processor change from PowerPC to Intel, Rosetta (enabling PowerPC code to run on Intel) was only kept for 2 years after the initial announcement. WWDC this year will be the 2 year anniversary for the Apple Silicon announcement. Apart from that, your vitriol over anything Apple makes you sound like you think Apple owes you something. I suggest you find yourself another hobby. 😉

First of all Apple Silicon use the ARM instruction set with a few added proprietary instructions to better facilitate Intel memory modes on the processor. These are used by the Rosetta2 translator to translate Intel code into the ARM instruction set on application first run. Thereafter the application runs ARM code. – Which is also what happens when you start up a viewer on a Mac with the Apple Silicon processor. AMD is instruction compatible with Intel processors and can in most cases run Intel code unmodified. Apple Silicon cannot execute a single Intel instruction. The memory layout is also radically different in that the CPU, GPU and the ML unit share the same memory space and read and write to it simultaneously. This means there is no "transferring" to the GPU from the CPU in the traditional sense. On the M1 Ultra the 64 core GPU can in theory use 64 Gb of memory. Thus the GPU can (in theory) read 800 Gb/s. To discuss the M2 processor is premature because Apple has not formally announced it or given any technical details.

Apple only offers two OpenGL profiles, the OpenGL 3.2 profile and the Legacy profile which the viewer currently use. To enable the OpenGL 3.2 profile you have to get rid of all the BOOL in the viewer code (12k+ of them) otherwise you cannot link the viewer with the necessary libraries. This is a hurdle that LL could have gotten rid of 3-4 years ago. Next, Apple has documented what you need to do to transform your application to Metal, and the intermediary steps, one of which is upgrade your code to the OpenGL 3.2 profile with specific attention areas documented for this to happen. The documentation was issued over 4 years ago, including multiple sessions and workshops at WWDC, and there is no evidence in the current viewer code these recommendations have been followed; even in the performance update. Rather they stupidly try to go directly to the graphics HW and enable OpenGL 4.1, which is unreachable for any normal running code on macOS. LL should have, IMO, rather than go ahead with the expensive and disruptive EEP project (still mainland is on WindLight), started the work to upgrade the viewer to OpenGL 3.2 and only then - maybe have built EEP on top of it.

No wonder Firestorm runs like a train-wreck on macOS with that attitude. 😉

Whatever Apple's motivation for deprecating and removing OpenGL, it does not help to stick your head in the sand for years and pretend nothing will happen. – Sure as the bank, Apple will switch off OpenGL, and most likely this fall when they have replaced the two last machines with Intel processors (Mac mini Intel config, and Mac Pro) with Apple Silicon configurations after the M2 processor is introduced at the WWDC in June. Then what? Is the lab happy to lose 15% of their active users and perhaps as many as 25% of the creators overnight? – If that is the case, then please tell us, because we Mac users can surely take our business elsewhere. Add to that: The only reason why OpenGL currently runs on Apple Silicon is because their Intel-based implementation runs under Rosetta2 translation over a small HAL (hardware abstraction layer) to the Apple GPU. There does not exist an Apple Silicon native implementation of OpenGL, and there never will. The reason Apple only will support Metal is now they design their own CPU+GPU complex from scratch, they don't want any dependency on companies such as Khronos Group, Microsoft or NVIDIA in their implementation of the processors. They also don't want to share any IP with these companies on how they have built their GPU. For Linden Labs to stay on Apple devices, they can either reimplement their renderer in Metal or they can find a renderer that already supports Metal and jerry rig the viewer into that renderer, but in doing so they introduce a dependency on a third party that may or may not be in sync with Apple hardware and system software releases.

I posted another update to the preview viewer with more optimizations applied in addition to functional updates and fixes. Just replace previous versions with the one from the DMG. The preview is both signed and notarized with my Apple Developer ID. Minimum system requirement is macOS 10.14 (Mojave). There is also an identical Windows 64-bit build, but I have not uploaded it anywhere yet. Also it is not signed. Let me know if anyone is interested in testing it.

The only solution is to sign the code that wants to use the microphone as I have previously outlined, and is done in my viewer and the SecondLife official viewer. The only reason why the terminal workaround might work for some is that if you install the developer tools, you can exempt processes started from Terminal from restrictions. Hence the viewer, if started from Terminal, might get temporary access to the microphone. However, the SLPlugin process has a tendency to crash and get automatically restarted while the viewer is running, and will lose access to the microphone because of this. Generally you don't want users to have to install the developer tools for them to be able to run your application, and you also don't want to encourage activity that bypass system security.

Cat avatar? 🤣 – That has absolutely never happened. 😎

Currently Second Life (and Opensim) requires a persistent connection and that is less than ideal for a mobile client in that it both gobbles up (metered) traffic and prevents the client to sleep to conserve battery. It also requires login to a specific location (simulator) burning CPU and occupying agent slots. For something like this to work and scale, you probably would have to log these clients into a separate, chat-only environment, where they were not visible in the region as rendered avatars, and push messages to the client only when new messages became available without persisting the connection.

Depending on what you switch from, but the Mac Studio is only going to run the viewer slightly faster than the Mac Mini M1 since the single core performance is virtually identical on the two machines. Given that the viewer runs under Rosetta2 translation it is bound to one processor core. The additional GPU cores will help some, but only to the saturation of the core Rosetta2 runs on. You can test my preview viewer downloadable from https://www.dayturn.com/viewer/index.php?resources/ which is more optimized for the Mac than any other viewer. It is of course not Apple Silicon native. (6-10 man year effort in my estimation to write one).

Do you even understand what you are writing? MoltenGL is for OpenGL ES, and there is not a single line of OpenGL ES in the viewer, so NO, LL does not investigate it. What they have been investigating MoltenVK. Which is a dead end.

No, MoltenVK. https://moltengl.com/moltenvk/ MoltenGL is if you have OpenGL ES apps that you might want to try get running on iOS. OpenGL ES has been gone from the iOS platform for at least 5 years. I don't know if OpenGL ES on macOS even was a thing. In any case, this is even more dead in the water than MoltenVK. Also, the viewer does not contain any OpenGL ES code at all, so for this discussion it is a pointless solution.

MoltenVK is a subset of the functionality in Vulkan, and is neither supported by Apple or Khronos Group. Apple has no desire or strategy to support anything but Metal on their processors, and they can easily completely block MoltenVK by refusing to sign the drivers. In addition Apple does not provide any kind of developer documentation at all for their GPUs. Traditionally Apple only allowed the GPU hardware vendors to write a HAL (hardware abstraction layer), then wrote their own drivers and OpenGL implementation on top of that. It might be possible in the short term to make "something" work on MoltenVK, but without support from Apple it could break at any system update. It is also hopeless from a business perspective both because you are completely on your own with the implementation, but it could also thwart your business plan and make your investment in the development effort worthless overnight if it no longer works and nobody will support you. Writing a Metal renderer, costly as it will be, on the other hand makes it possible to make a viewer that both runs on Mac, iOS and iPadOS devices, expanding the potential customer base by about a 1 billion users.

That is not the issue. The issue, from a business perspective – and Linden Labs is a business selling the product Secondlife, is that recruitment of new customers from a segment of the market that are usually willing and able to pay, stops.

Sure, sounds like a smart idea given according to LL estimates 25% of their content creators use Macs. I bet the 15% Mac users are more or less all premium customers too. Most likely OpenGL will be removed from macOS this fall, after which no new machines can run SecondLife (or Opensim)

It is still shelved... 😀 and no real work has been done on the Mac viewer to make it survive the day Apple close OpenGL.

That project is for all practical purposes shelved. The need to man up to make a proper Mac viewer and what they learning from that project, they can easily use make an iOS version. Going the other way is a lot harder. That code will in reality be completely useless for making an Android version because of very significant differences in – just about everything.

That was a complete scam.

The resolution is plain in the day in code for my viewer, but one of the fundamental issues with with all viewers (perhaps with the exception of mine) is that they build for deployment target of 10.9 - 10.11, which hides a large number of deprecations in the code. Once you set a sensible deployment target like 10.14 (Mojave), there is a slew of issues that prevents the viewer code from building on Xcode 13.3, which is needed for successfully signing the viewer to run on the latest Monterey (12.3). The catch is also that Xcode 13.3 ONLY runs on Monterey (12.3), so there is a double whammy there... All this has been fixed in my repository, but the fixes must be applied to FS, Alch and so on. Only after successful build with Xcode 13.3 will you be able to apply my entitlements and signing code to both sign and notarize the viewer. The general code changes mentioned above can also be applied with Xcode 12.1 if that is easier, but the signing requires 13.3 as far as I have experienced. Also, depending on which SDK and deployment target the libraries used are built with, they may have to be recompiled with the same deployment target as the viewer to avoid all kinds of linking issues. I have seen libs built with the 10.7, 10.9, 10.11 SDK and they will not notarize or even sign.

I have uploaded a preview of my Dayturn viewer that works for SecondLife, and is tested on both Intel and Apple Silicon version of macOS Monterey 12.3. Both voice and microphone should work correct on this viewer in secondLife. Functionality-wise it lies between the SecondLife Viewer and Firestorm. The download is provided as is. It is both signed and notarized with my Apple Developer ID. Dayturn Viewer download.

Apple is tightening security on use of certain system components such as the microphone, the idea is to block an unknown developer from installing code on a Mac that could use the microphone to secretly monitor or record a user or the user environment. By forcing the developer to sign the code to use the microphone, it also makes the developer’s identity known to the user, Apple and law enforcement, if needed. You can disagree with their approach, but this how it will be going forward. Meaning viewers will have to be signed to use the microphone.

It is true, I had to fix signing for voice again after the release of Monterey 12.3. You both have to (re)sign existing signed libs in addition to provide entitlements for both the viewer app bundle and SLPlugin.app with content. You can see how I have done it in the code in http://www.dayturn.com:5000/dayturn-new (viewer still in progress, but the signing should work your Firestorm too). The entitlement files are the top level of the repository, the rest of the signing happens in viewer_manifest.py. My code will also notarize if both the bundles are set as hardened runtimes For the developers, just use ad-hoc signing or no signing at all. You only need to sign and potentially notarize on release. After signing, you can revoke all app access to the Microphone by typing "tccutil reset Microphone" in terminal. Do this with the Settings->Security&Privacy->Privacy panel opened and Microphone selected. You should see the system revoke all microphone access. Then re-run your signed viewer, or just the SL viewer to see what happens and it will ask for access to the microphone when entering the first voice enabled region. You can also test the above on opensim with my latest Dayturn viewer downloadable from https://www.dayturn.com/viewer/index.php?resources/

It needs to be signed with an Apple Developer ID. The Firestorm team does not have that, so macOS refuse to give it access to the microphone. It cost them $99 to fix it.

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).