OpenGL deprecated in Mojave - is this the start of the end for the MacOS Viewer?

[Paul Hexem]

People still use Macs for more than overpriced web browsing? 

Gamers and 3D artists have abandoned Macs long ago. Apple seems fine with being a phone company. 

[Loki Eliot]

On 07/06/2018 at 5:39 PM, CoffeeDujour said:

Sansar has no plans on OSX as there is no VR.

Sansar is a radically different beast to Second Life.

Not true, i’m a Mac user and have a Vive headset and have created VR experiences natively for MacOS using Unity which supports metal along with SteamVR for MacOS. There just is’nt much content yet to consume for macVR since being a Mac VR enthusiast is  being a minority of a minority in a minority.

If i remember right, back during Lab Chats on Sansar, LL said Sansar would use OpenGL and that a mac version was ‘down the road’. I’d assume then that an openGL port of sansar to mac is definitly off the cards now. 

The most common response i hear from others about creating a native Mac Viewer for second life is ‘Mac users are like only 5%, there is no point waisting resources’. But it’s not like resources hav’nt been waisted before and im pretty sure that 5% will use that new viewer longer than users of Project Skylight, the SL Basic Viewer,  SLchat App, Patterns or Creatorverse. 

[Qie Niangao]

Given the projected market for desktops, completely re-implementing the entire SL graphics pipeline for just one desktop platform would be prohibitively expensive -- and more importantly, calendar-consuming.

The thing is, it would take years of development and testing to actually port SL to a new graphics API, even with a massive commitment of resources, during which time there's every reason to expect any particular target API to itself become obsolete. Nobody really knows how long Apple will keep supporting a separate desktop operating system, same as everyone expects Google to find a common replacement for Android and ChromeOS (presumably Fuschia, if all goes as planned). What graphics APIs do we expect those replacement OSs to support? I doubt anybody wants to make that call yet.

[ChinRey]

7 hours ago, Qie Niangao said:

The thing is, it would take years of development and testing to actually port SL to a new graphics API, even with a massive commitment of resources, during which time there's every reason to expect any particular target API to itself become obsolete.

Yes but keep in mind that this is not a SL only problem. It's probably not a Mac only problem either. Microsoft's OpenGL support is a bit lukewarm and so is their commitment to keeping DirectX cross platform. I suspect it's only be matter of time before they follow suit and stop supporting OPenGL and developing DirectX for other platforms.

But I think the fact that Linden Lab is not alone here, is the key to the solution. There is already at least one commercial Vulkan-to-Metal interpreter and there should be more than enough market for ready-made OpenGL-to-Metal and OPenGL-to-DirectX libraries too.

[Qie Niangao]

19 minutes ago, ChinRey said:

Yes but keep in mind that this is not a SL only problem. It's probably not a Mac only problem either. Microsoft's OpenGL support is a bit lukewarm and so is their commitment to keeping DirectX cross platform. I suspect it's only be matter of time before they follow suit and stop supporting OPenGL and developing DirectX for other platforms.

But I think the fact that Linden Lab is not alone here, is the key to the solution. There is already at least one commercial Vulkan-to-Metal interpreter and there should be more than enough market for ready-made OpenGL-to-Metal and OPenGL-to-DirectX libraries too.

I agree that something like this is the most likely way forward, avoiding a true port.

In my (unrelated) experience, though, libraries implementing one big API in terms of another are never entirely satisfactory. For one thing, it's never turn-key, with obscure bugs to detect and remedy, both in the library and residual in the application uncovered when using the library instead of the native API. (Kinda like working with different implementations of the API, in spades.) For another, performance is never quite as expected, not because the library is poorly implemented but because a programmer will always take advantage of a platform's peculiarities when they're available, and whatever tricks made API-x sing and dance won't work in API-y with its own bag of tricks.

[ChinRey]

1 hour ago, Qie Niangao said:

In my (unrelated) experience, though, libraries implementing one big API in terms of another are never entirely satisfactory.

You're right of course, it's not an ideal solution. In addition to the problems you mention, no matter how well written the interpreter is, it is still one more step to go through in the rendering process. Still, it's better than nothing and may be the only realistic solution.

[Coffee Pancake]

Wrapper libraries are universally terrible as a direct "by the book" translation is never ever enough to actually guarantee compatibility. They have to pick up and include bugs fixed in the drivers (for which there is no source and no documentation), bugs worked around in applications (undocumented at best) and bugs in the new target API or it's implementation.

The older forum members will remember the steaming pigs mess we had with running OpenGL games on Voodoo hardware (which didn't support OpenGL). Wrappers were made by a few people, but none were perfect, and often getting a game to run involved swapping between half a dozen different DLL's in order to find the one that worked and performed acceptably on a game by game basis. More often than not it was a choice between Nope, dead dog slow but mostly ok or Fast & badly glitched. The best wrapper for one app would hard crash your PC on another.

In the end everyone just gave up and bought new hardware, the old voodoo titles were abandoned.

 

[Callum Meriman]

On 6/10/2018 at 9:31 AM, CoffeeDujour said:

The older forum members will remember the steaming pigs mess we had with running OpenGL games on Voodoo hardware (which didn't support OpenGL). Wrappers were made by a few people, but none were perfect, and often getting a game to run involved swapping between half a dozen different DLL's in order to find the one that worked and performed acceptably on a game by game basis. More often than not it was a choice between Nope, dead dog slow but mostly ok or Fast & badly glitched. The best wrapper for one app would hard crash your PC on another.

Although not so old, my RL partner has a rather strong interest in old computers. A whole room dedicated to hardware from the 1980s onwards.

He has resurrected one authentic to the time Voodoo 3, Glide API, machine with two cards in SLI. It was quite a task getting that running, and indeed, the shims and debug level patching of games to fool them into running on that happily-dead API is rather hit and miss.

Sad thing, that one computer cost more to put together then a modern gaming machine. There is a huge market in ancient computers, some rare cards of the day fetching thousands of USD on ebay.

I digress. Yes, Glide was horrible.

But to re-iterate the larger Mac issue, any effort is wasted effort. In 2020 they won't be running Intel chips, SL is likely to be very broken at that point anyway. No Sansar, No SL, No OpenSim... Apple will cement it's position for glorified web browsing. I cna't see how there is sense in even wasting even a minute on Apple stuff. Send OS X support the way of XP.

[Coffee Pancake]

8 minutes ago, Callum Meriman said:

He has resurrected one authentic to the time Voodoo 3, Glide API, machine with two cards in SLI. It was quite a task getting that running, and indeed, the shims and debug level patching of games to fool them into running on that happily-dead API is rather hit and miss.

Sad thing, that one computer cost more to put together then a modern gaming machine. There is a huge market in ancient computers, some rare cards of the day fetching thousands of USD on ebay.

Now I have vintage computer epeen envy. All my stuff is in boxes, in my parents loft .. in another country .... and they refuse to mail any of it because the postage would be high, even though I would be paying for it  

[Callum Meriman]

14 minutes ago, CoffeeDujour said:

All my stuff is in boxes, in my parents loft .. in another country .... and they refuse to mail any of it because the postage would be high

If you do recall what you had, it could be worth checking your stored parts on ebay. Some of the prices you can get really are insane. 

[Coffee Pancake]

17 hours ago, Callum Meriman said:

If you do recall what you had, it could be worth checking your stored parts on ebay. Some of the prices you can get really are insane. 

This is why I haven't just re-bought stuff here,  prices are insane.

[Whirly Fizzle]

Blog post from Firestorm developer Tonya Souther.

http://secondden.blogspot.com/2018/06/at-apple-worldwide-developers.html

[Fionalein]

Just a silly question: in the distant past it was possible to install Linux or Windows on Mac machines ... is that still possible? Might be a way out for some...

Edited June 18, 2018 by Fionalein

[Loki Eliot]

16 hours ago, Fionalein said:

Just a silly question: in the distant past it was possible to install Linux or Windows on Mac machines ... is that still possible? Might be a way out for some...

My love for SL will quickly diminish if i'm forced to use the windows operating system for one application after 25 years of using MacOS. As much as i love SL and the community i don't think i could change my computing habits to Windows just to keep in it. After all SL is 15 years old, it's not cutting edge technology anymore, maybe the OpenGL Apocalypse will push me towards newer things. In Second Life over the years I've learnt a lot about creating 3D content and scripting and creating stories and fun experiences. Instead of struggling to stay connected to SL, maybe i should look to new horizons when the time eventually comes.

[Greywolf Tsunenaga]

Apple announced some time back the these legacy technologies would be replaced with Metal (not Metal 2).  

 

To say there is no VR in macOS is ignorant, Mojave is full of resources.  

 

Apple has established a "professional users" group of industry leaders to lay the roadmap for future pro app development.  So that argument is ignorant of the facts, also.

 

Linden Labs has known about Metal for a long time, and can choose to move to it, or not.  If they do, they'll be able to easily build a SecondLife viewer for iOS, also.  It would be very short sighted of them not to.  And since Mojave is still only beta now, no one is releasing apps publicly for it.  You'll see that after the public release.  It has always been this way, for any OS developer.  The panic in this thread is unfounded.

 

But I'm just a retired IT engineer, what do I know?

[Alyona Su]

11 hours ago, Greywolf Tsunenaga said:

Apple announced some time back the these legacy technologies would be replaced with Metal (not Metal 2).  

 

To say there is no VR in macOS is ignorant, Mojave is full of resources.  

 

Apple has established a "professional users" group of industry leaders to lay the roadmap for future pro app development.  So that argument is ignorant of the facts, also.

 

Linden Labs has known about Metal for a long time, and can choose to move to it, or not.  If they do, they'll be able to easily build a SecondLife viewer for iOS, also.  It would be very short sighted of them not to.  And since Mojave is still only beta now, no one is releasing apps publicly for it.  You'll see that after the public release.  It has always been this way, for any OS developer.  The panic in this thread is unfounded.

 

But I'm just a retired IT engineer, what do I know?

Home run, sir!

This is, more or less, what I was trying to say in another thread where the OP was complaining to LL that their viewer was crashing on public beta 2. LOL

[Macrocosm Draegonne]

On 6/6/2018 at 8:03 PM, CoffeeDujour said:

It would still require a rewrite for Vulkan,  just porting existing opengl over leads to a worst of both worlds result.

• Do nothing. Tell OSX SL users not to update their OS. 
• Stick with OpenGL and hope 3rd parties to cover any gaps in upcoming Apple support (anyone who remembers the mess we had with glide and wrappers is probably terrified of this option).
• Drop OSX and leave it up to TPVs to mangle something together .. ala Linux.
• Add and commit to supporting a second Metal render pipeline just for OSX users.
• Port all platforms to Vulkan and drop support for rendering hardware >10 years old.

Building a Metal render engine is pretty much the same amount of work as building a Vulkan one, so it seems silly to do that for a minority platform. The later option does deliver the better viewer and long term maintenance load, but would cut out people on very old hardware. To be fair ... writing a new render pipeine for vulkan is probably a really good idea at this point and overdue, but that's not the kind of easy project the Lab can just pull out of the hat.

Have you seen this?  https://www.collabora.com/news-and-blog/blog/2018/10/31/introducing-zink-opengl-implementation-vulkan/

Its an interesting read, something like that could create a gateway into another setup over time, as opposed to a hard switch all at once.   It will be interesting to see how good it gets and if others jump in.

[Skate Foss]

sorry Im late to this, but I updated to mojave a month ago, since then on my home ISP, SL stopped seeing the driver for my Space Navigator 3D mouse. With it plugged in, theres no option for it in Preferences / Movement. Yet, logging in to SL from a different ISP, on my same macbookpro, SL sees the driver and option is available. Linden Lab is No help.

This happened when I upgraded my macbookpro to mojave. The ISP that allows SL to see the driver has has a download speed of 210Mbps and upload of 37Mbps.

My home ISP just has speeds of 117Mbps and 11.6Mbps. Can this be the answer? You all know about how good SL Support is.

Thank you

[Solar Legion]

Your ISP has nothing to do with the Second Life client seeing your hardware or drivers. At all.

That is software/machine/OS level.

Edited December 15, 2018 by Solar Legion

[Skate Foss]

Its frustrating that the same MacBookPro works differently at 2 different locations

 

[Solar Legion]

Thing of it is that the location/ISP connection doesn't actually matter - the client has to poll your machine to see what is connected to it. If the machine never tells the client you have a Space Navigator connected, the client cannot make use of it.

Windows, Mac, Linux .... No matter the Operating system there can be odd quirks and such introduced when updates occur.

Prior to the most recent Kernel update on this machine (Linux based) a few software side audio sinks had to be manually started. Now they seem to start by themselves again.

On an old machine that ran Windows, the audio system itself occasionally failed to initialize on boot and had to either be started manually or would force a reboot.

Whether you're shutting your Macbook down before moving it or not, it really does seem as though the OS itself is occasionally not recognizing you've got that Space Navigator plugged into it. Unfortunately this can be a purely OS side issue or the hardware itself (the port it is being plugged into, the cable, the connector) is simply wearing out - which can happen.

I wish I could be of more help but I'd have to have the machine in front of me to do much more than suggest.

Edited December 16, 2018 by Solar Legion

[Skate Foss]

Solar would you know which port the Space Navigator uses for SecondLife? 

Edited December 19, 2018 by Skate Foss
typo

[Solar Legion]

It doesn't. It connects to your machine. Your machine processes the inputs, uses a driver (software on the OS) to interpret those inputs. That data is then passed to whatever program wishes to use it.

The problem is not network related thus no ports - beyond a USB port - are involved.

You're assuming it is somehow network related based on happenstance.

According to your own OP over on VVO, you've already contacted 3Dconnexion and they've told you the driver they have for Mac is still new/buggy and that they are looking into it.

That is pretty much it, Skate. It has nothing to do with Second Life, nothing to do with your internet connection and by the hardware manufacturer's own words is a driver issue.

I'm not trying to sound like an arse here - really I'm not. All you can do is wait to see if the driver itself gets updated and see if that fixes the issue.

[Wulfie Reanimator]

Personally, I'm mostly okay with this. Not because I don't use Mac, but..

OpenGL has been around since at least 1992. 26 years. Sure, it's been iterated on over time, but for how long is it reasonable to demand support for old tech when newer, probably better alternatives have come around. Obviously I can't compare between different API choices, but I think Apple's choice to stop maintaining support for something as old as OpenGL is reasonable.

For example, if you go and read Tonya's blog post about this, she says this in relation to "segregating OpenGL" in the code:

Quote

To understand the magnitude of the problem, let me lay a couple of numbers on you. Firestorm currently consists of 25,649 files of source code, containing well over 1.2 million lines. I don’t know just how much of that is OpenGL code. What I do know is that there is no clean boundary in the viewer’s source code between the parts that use OpenGL and the parts that don’t; OpenGL is scattered throughout the entire codebase. This is true of every viewer based on the Linden Lab code, which is all of them that do graphics (with the notable exception of Lumiya, which was a ground-up implementation for Android, and a remarkable technical achievement in its own right). Some of that code is over 20 years old at this point.

While she's talking from the viewpoint of a Firestorm developer and their viewer code, you can apply this same logic to Apple developers and keeping their hardware/OS compatible. OpenGL is still around and being used, but it's built iteratively on top of very old code. It takes a lot of time to implement new things in a way that doesn't break old things. New things that may be more benefitial in the next 20 years than OpenGL when it turns 45+.

I also come from the background of following a game for 6+ years, and watching it drop support for DirectX 9 (2002) and 32-bit systems mid-development after the game was already released for sale. Their reasons for these choices were the same. "These things are too old and limit what we're able to do."

P.S. In case anybody missed it, also from Tonya's blog post:

Quote

Again, I must remind you that Apple has deprecated OpenGL on OS X. All that means is that they will stop supporting it at some point in the future. That point is not today, and they have not said when that point is. Until they do, Second Life, and Firestorm, will run on OS X as well as it does now.

 

Edited December 20, 2018 by Wulfie Reanimator

[Ansariel Hiller]

Sorry, @Wulfie Reanimator, but the reason that Apple tries to shoot down what they called "old tech" is primarily to push creators into a platform lock, hoping they will exclusively develop for Apple's Metal API. If they wanted to replace an old API, they could have switched to the platform-independent Vulkan API instead! And secondarily it's most likely that Apple doesn't want to spend any money and development time in fixing their super bugged OpenGL implementation. So they simply said it's old and have it gone, knowing that the Apple fanboys will shut up and swallow the pill.

Edited December 21, 2018 by Ansariel Hiller