Gaxtrope

Yes indeed that was my reference.

2010, more likely. It'll still be the OpenGL 4.1 driver until that part is updated too.

A bunch of cleanups of unused code including macOS Rez files have now been merged into the Maintenance-A branch, as well as whole scale conversion of BOOL/TRUE/FALSE, most of it by Ansariel. Boost is slowly getting replaced by its C++17 counterparts elsewhere, so... it's moving forward, albeit slowly. Once we have it merged, I'm planning to persuade LL into making an Apple Silicon build - the main challenge is that this needs to be done for all the 3rd party libraries as well.

That makes so much sense - thank you 🙂

Then it just baffles me, 1) Why LL have not seized this obvious optimization opportunity a long time ago themselves. But then again I found Rez files in the repo, which harkens back to the time when we had resource forks in our filesystems, so priorities/resources must be somewhere else. 2) Why none of the many forks that have gone through this arduous process have been successful in having this obvious optimization merged to the main base a long time ago, massively reducing the amount of retro-merging when pulling from the main base. I think I'll have a go at replacing them once I have the time 🙂

Yeah, those BOOL definitions puzzled me too. Why would you represent boolean values as integers??? By the way, @Erik Kundiman - your Megapahit build works here on my M1 🙂

Oh sorry, I didn't mean rewriting all of the Viewers C++ code in Swift. I meant rewriting the 8 .mm and .h files in Swift, including bridging code. And then, through sse2neon simply make the code build and run natively on Mx processors. That was the scope of the original post here, as I see it. I wanted to take that - admittedly small scoped - idea, and submit it to the official viewer. I agree completely on the need to separate the OpenGL to an in-world render so as to make it easier to replace engines, and to offload a lot of work to the more optimized OS. That way, the usual time and resources constraints can determine if there will be a dedicated Metal or MoltenVK or whatever renderer first. As for Apple never accepting Vulkan - maybe. But they've kept the shamefully ancient OpenGL implementation around for far longer than anyone thought they would. The only way I can see they can nix OpenGL is to make sure small developers who still want to make cross-platform titles have a viable alternative. Metal only runs on Apple devices. Of course, the announcement of a mobile Unity-based viewer might imply that the open source desktop viewer as we know might be replaced with a closed Unity Viewer 😕

So Gavin, do you think there could be a point for us macOS users to take on the following tasks in order? 1) To prepare things, convert the Objective-C++ base to Swift, taking into account that a Swift/C++ bridge must work. Merge this into the SL official GitHub - I have had a few macOS patches accepted recently. 2) Test a method for mapping the SSE optimizations to Neon. There is an sse2neon.h out there, don't know if it's any good. This should be the biggest obstacle in the viewer itself - the rest seems to be easy in XCode. 3) Push for automatic (at first unsupported) builds of Apple Silicon (but for now still OpenGL) Viewer. This will not only require building the viewer itself, but also the various third-party libraries. But the last holdout as I see it, Vivox/SLVoice, now exists in an Apple Silicon version. Later: Engage with Linden Lab on the effort to move from OpenGL to Vulkan, and in that process use MoltenVK for the macOS viewer. Don't know if their current effort to make Unity-based mobile viewers might supercede/surpass this.