Gavin Hird

Given that it works fine on "first login" – meaning with clean settings, cache and log files, it has nothing to do with the network access. If the file system is corrupt (which can happen if a machine is abruptly turned off) these files will be written, but trying to re-read them the content can point to some random locations on the disk making the file useless. I have no doubt a VPN can create major issues for the connection to SL servers, but as I said above, given it works with clean settings files, the corruption happens on the machine itself.

I can't see how this has possibly anything to do with Monterey 'virtual private relay'. To me it sounds like the filesystem is corrupt, so running Disk Utility and First Aid on the system volume and then a reboot if issues are identified might clear it.

Try my preview of the Dayturn viewer which is more optimized for macOS than the rest of the viewers, and see how that runs. It is built and tested on a M1 mini, and runs under Rosetta2 emulation as there is no native viewer for Apple Silicon yet. Make sure to download Dayturn SL preview for macOS and not the one with the green badge as that is OpenSim only.

Any chance this friend runs Firestorm on a Mac?

I did notice a sharp drop of 20-30 fps after applying that single patch. – Your code, is your code.

It looks like there was a last minute change to the performance viewer that dropped the frame rate quite a lot when I applied it to my viewer code. SL-17244 to be specific.

I don't think the issue here is a question whether a security feature is wrong or not. To me the issue is a developer of an app with a large number of users not providing a fix, for which there has been a straightforward solution for at least 2 years, putting their users in a position where they might have to bypass system security to use their app. – That is what you generally expect from a developer of malware. Regrettably there is an attitude amongst developers (perhaps even LL themselves) that macOS users are not worth having, and is a real bother to support. Many even ask them to switch platform or go elsewhere (that includes core developers of the viewer in question). In general macOS offers total freedom to do with and install what you want on your system as opposed to iOS and iPadOS which is too locked down for my taste. Admittedly Apple has made it a bit harder for both users and developers to install "anything", but they have publicly stated only a few weeks ago they have no intention of locking down macOS.

They need to pay $99 (yearly) for an Apple Developer membership, generate the signing certificates need for Xcode and at a minimum sign the viewer, secondary get it notarized. LL does it for their viewer so they can copy that procedure and code, and they also has access to my repository and are free to copy my signing procedure which is slightly different from LL's simply because there are small diffs in what libraries are in use. The effort needed is less than 10 hours. Given the large number of SL users on their viewer, they would make very many macOS users happy by getting this sorted.

It was a post about how to break system security when it informs the user there is a problem. Social engineering to get people to respond in certain ways is the most common vector to installation of malware on macOS.

She did, but not every viewer out there masquerading as the viewer in question is benign. Informing people how to bypass the system security mechanisms is also a vector to install malware. The issue is easy to fix for the development team of that viewer. They are all too aware of it for quite some time.

Use Y instead till the developer gets its act together and fix X. (the fix is easy, but cost them $99/year)

Obviously you do. If not, you would not make this "recommendation". Also, what if there actually IS an issue that Apple flags? Both the two last versions of Monterey has fixed a bunch of zero day exploits, and what if some of those exist in the libraries in this viewer? – Do you want to take responsibility for fooling users into installing a compromised app? As an macOS app developer, long term Mac user and former Apple employee, I have never experienced that the gatekeeper flat out refuse to run an app unless there is a real issue with it. – Sure you are asked to jump through annoying hoops to coerce gatekeeper to run some of them if they are not signed or notarized, but flat out disabling it is irresponsible at another level.

So you ask people to disable system security to install an app which has an issue that a) can be fixed easily by the developers and b) is fixed in the official SecondLife viewer? The obvious recommendation is to recommend people use the official SecondLife viewer, that does not have this issue, till FS is fixed.

Apple made a change with Xcode 13.3 which made it only run on macOS 12.3 or higher which is a real PITA. It is required for properly signing the viewer. All the changes are in the repro. Clone it and start at the commit DAYTW-32 Fix up the Objective-C code... applied 20 jan 2022. That is a summary of a number of commits applied to the Opensim version over time. From then on and forward pick the ones you want. DAYTW-36 from May 12 2022 might also be of particular interest The Opensim version repo is on Bitbucket and has many of the same changes, but not all, as the new repo will be the new Opensim version. The new repo will also be on Bitbucket soon. I have no intention of releasing a regular SL version as that would compete with Kokua, and we agreed to the split back in 2016. There is the preview that is SL compatible that runs on both macOS and 64-bit Win.

Your viewer does not build with Xcode 13.3.1, so no, I can't build it. To your bug, it is pointless to try and analyze it before the viewer is built with a deployment target that force you to remove all the old memory management code from the viewer, like I have done in mine (all those changes are in the Objective-C code). Then next, make it build with Xcode 13.1.x which will flesh out more deprecations which needs to be sorted. If the bug still persist, then run Xcode analyze on the viewer and see it if will identify the cause of the crash (there are 10s of occurrences of similar conditions; memory is read after being released in the viewer code). By that time you might be good. – I do not see that crash, and but I have only taken a portion of the PerfViewer code, so it can of course have been introduced in the commits I have not taken. The repository is here. Xcode 13.3 only runs on macOS 12.3.x so that may not even be possible if you have a Hackintosh.

I find that the FPS counter on the Cool VL Viewer varies wildly in the same scene from way too low to spiking optimistically high, so I am not sure how to interpret it. (It might be the Mac version that behaves this way.)

I have tested it on a Mac with the Apple M1 processor and 8 GPU cores and it is faster than the current default viewer. However, at the same scene, with settings as close as possible between the two viewers on the same machine, where the SL PerfViewer renders at about 57 fps, my Dayturn build renders at about 82 fps. I have to check if the difference is the same on an Intel based Mac... Intel base Mac (3,8 GHz 8-Core Intel Core i7, AMD Radeon Pro 5500 XT 8 GB) the SL PerfViewer renders at about 61 fps, my Dayturn build renders at 71 fps. (The Intel based machine has a 5k display at 5120x2880, whereas the Mac with the M1 has a 2560x1440 display). Both tests are done in a 1680x1050 window rendered at Retina resolution which makes the rendered resolution 3360x2100.

There are new builds available for testing for both macOS and 64-bit Windows available for download. (just hit the download button and install over the older version). These builds have the functionality for MFA, some optimizations for rigged mesh from the upcoming Performance viewer, and for the macOS version some improvements to the renderer that seems to be extra favorable when running the viewer on Apple Silicon. (all versions have performance improvements). In addition there are cleanup of features.

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.

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.

I have not checked the Windows version but if you are on a Mac it will stop at 512MB because LL has not been able to figure out how to determine graphics memory on macOS. Because Apple has deprecated OpenGL they have also more or less scrubbed all documentation on it, and there are no new documented methods for getting graphics memory from the system. This does of course seem outrageously annoying to developers, but Apple's rationale is not surprising given currently 99% of all new Macs shipped (soon 100%) have Unified Memory meaning the GPU has full access to all system memory which the CPU and GPU can read and write to concurrently. In such a system architecture the traditional definition of graphics memory does not make any sense at all. It also means there is no bus the data used by the GPU needs to be transferred across, and on some of the newest machines the GPU can read memory at rates of up to 800 GB/s. Apple provides methods to a) determine system memory installed and b) determine if your application runs on a machine with unified memory. If you run on a machine with unified memory they have asked the developer to handle low memory situations and provides mechanisms to signal the application that memory is running low and act accordingly.

Current 64-bit SL Viewer has texture memory set to max 512MB. The performance viewer, currently in the works, will let the viewer use more depending on how much is detected (possibly up to 2048 – I have not checked the details)

I posted yet another update to the preview viewer (build 48762) with more optimizations applied in addition to functional updates, fixes and a couple removals. This build will reset the graphics settings for the viewer on first run. Please reapply your settings and they should stick. 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). I have also posted a build 48762 of the 64-bit Windows version which has been verified to run on Windows 10 and 11. It is feature and code identical to the macOS version, except for platform differences. It is not signed, so Windows will resist your installing it.

I have a couple running idle myself, but you will be hard pressed to find anything but the 1GB RPI4 that you can buy at the moment because of chip shortage. 😀

Apart from the fact that RPIs are very hard to come by these days, they run Debian brilliantly and is a great learning tool. I also have 2 RPIs running Opensim simulators. The RPI4 8GB version runs 7 standard regions (256x256) in 2 simulators. The RPI4 2GB version runs a 512x512 VAR.