Jump to content
Tholan Nohkan

Could "moltengl" solve the Mac opengl problem

Recommended Posts

probably not. I think LL will go with their own Metal implementation. And if they were to go with a open standards middleware layer then probably something Vulkan

Share this post


Link to post
Share on other sites

The solution to the Mac OpenGL "problem" is for Apple to continue to use/support OpenGL and to properly support the system agnostic Vulkan protocol instead of trying to enforce their oh so lovely lock in.

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites
3 hours ago, Solar Legion said:

The solution to the Mac OpenGL "problem" is for Apple to continue to use/support OpenGL and to properly support the system agnostic Vulkan protocol instead of trying to enforce their oh so lovely lock in.

Yes. Autodesk called Apple's bluff. Autodesk has said they will not support Apple's private graphics API.

Share this post


Link to post
Share on other sites
13 hours ago, animats said:

Yes. Autodesk called Apple's bluff. Autodesk has said they will not support Apple's private graphics API.

There is no bluff. OpenGL on all Apple platforms are depreciated for Metal 2 which yields 2-10x draw calls over OpenGL on the same hardware. 

While I not necessarily think this is a good move by Apple, it is what will happen, and OpenGL should be gone in macOS 10.16 which can be expected in 2020 if they are on the same yearly release schedule as they have been. All new non iOS hardware introduced even this year have HW support for OpenGL still. 

Share this post


Link to post
Share on other sites
14 hours ago, Fionalein said:

Well played Autodesk - well played ...

 

15 hours ago, animats said:

Yes. Autodesk called Apple's bluff. Autodesk has said they will not support Apple's private graphics API.

Remember when QuarkXpress tried that ultimatum business a while ago because they thought they were "all that"? How did it turn out for them? LOL

Whatever the tech they choose to use, I'm pretty confident the LL Viewer will work on Catalina (the the TPVs will follow suit.) Someone posted a thread that it was working fine on the public beta, so... Perhaps no need for Chicken Littles, okay? LOL

Share this post


Link to post
Share on other sites
1 hour ago, Alyona Su said:

 

Remember when QuarkXpress tried that ultimatum business a while ago because they thought they were "all that"? How did it turn out for them? LOL

Whatever the tech they choose to use, I'm pretty confident the LL Viewer will work on Catalina (the the TPVs will follow suit.) Someone posted a thread that it was working fine on the public beta, so... Perhaps no need for Chicken Littles, okay? LOL

Most of the viewers work on Catalina (beta versions). 

The challenge is the macOS version following Catalina where, reading the tea-leaves from WWDC 2019, OpenGL will not only be deprecated but also completely unsupported. 

Share this post


Link to post
Share on other sites
8 minutes ago, Gavin Hird said:

Most of the viewers work on Catalina (beta versions). 

The challenge is the macOS version following Catalina where, reading the tea-leaves from WWDC 2019, OpenGL will not only be deprecated but also completely unsupported. 

So still 15 months away, at least. Plenty of time to find whatever solution they decide on.

Share this post


Link to post
Share on other sites
3 hours ago, Alyona Su said:

Remember when QuarkXpress tried that ultimatum business a while ago because they thought they were "all that"? How did it turn out for them? LOL

Autodesk said no to Apple for the entire PowerPC era. Autodesk products were never ported to PowerPC. They've done it before when Apple did something stupid.

Share this post


Link to post
Share on other sites
1 minute ago, animats said:

Autodesk said no to Apple for the entire PowerPC era. Autodesk products were never ported to PowerPC. They've done it before when Apple did something stupid.

It's Autodesk; It's no loss except to a very tiny percentage of macOS users. Thus, Apple won't care (and neither should they.) Moving forward with newer better technologies is a "stupid" move because is it preferable to remain with crusty old legacy methods? If you say so. Rhetorical question as food for thought. ~shrugs~

  • Like 1

Share this post


Link to post
Share on other sites
3 hours ago, Alyona Su said:

So still 15 months away, at least. Plenty of time to find whatever solution they decide on.

Completely rewriting the renderer for Metal in 15 months is probably not doable both because there are significant dependencies between all LL content and OpenGL 2.1 currently used by all viewers. 

The other issue is that the Lab has had an open position for a rendering engineer for a very long time without being able to find anyone. The individuals out there who are capable of lifting the current OpenGL 2.1 code in to Metal are few and far between. Probably very expensive to hire too. 

Of course, succeeding to write a Metal renderer makes the road to an iOS version of the viewer very short. So hopefully...! 

Share this post


Link to post
Share on other sites
5 hours ago, Alyona Su said:

So still 15 months away, at least. Plenty of time to find whatever solution they decide on.

Unless LL are neck deep in brand new render code .. no, it's not even nearly plenty of time. It would be a huge undertaking.

At this stage of the game, sinking everything into an entirely new niche platform render engine would be a massive blunder. If future proofing is the goal, then refactoring the asset/render pipeline to use multi threaded vulkan is the sensible choice with limited time and resources.

OSX users represents a tiny percentage and it's 3D performance is woeful. The only thing in it's favor is that Oz is an OSX user.

Share this post


Link to post
Share on other sites
8 hours ago, CoffeeDujour said:

Unless LL are neck deep in brand new render code .. no, it's not even nearly plenty of time. It would be a huge undertaking.

At this stage of the game, sinking everything into an entirely new niche platform render engine would be a massive blunder. If future proofing is the goal, then refactoring the asset/render pipeline to use multi threaded vulkan is the sensible choice with limited time and resources.

OSX users represents a tiny percentage and it's 3D performance is woeful. The only thing in it's favor is that Oz is an OSX user.

According to LL 15% of SL users are on macOS, and closer to 25% of the content creators are. So dropping the macOS viewer will impact their financial performance. 

What you tend to forget is that a Metal renderer will potentially broaden the market to the 1 billion iOS users. Not to be underestimated. Today's iOS HW is in many ways more capable than the desktops that ran SL only am few years back. 

Share this post


Link to post
Share on other sites
Posted (edited)
11 hours ago, Gavin Hird said:

According to LL 15% of SL users are on macOS, and closer to 25% of the content creators are. So dropping the macOS viewer will impact their financial performance. 

What you tend to forget is that a Metal renderer will potentially broaden the market to the 1 billion iOS users. Not to be underestimated. Today's iOS HW is in many ways more capable than the desktops that ran SL only am few years back. 

Also, though there is still 15 months to go (give or take a couple) - people who don't follow macOS news tend to forget (or not know at all) that the removal of OpenGL was announced a long time ago (at least a year, if not two) - Apple does not turn on a dime. They tend to warn people (developers, specifically) of game-changing affects being made to the system with plenty of time to adapt. Surely, Linden Lab is not stupid; they have likely been working on this for quite some time already. If not then I recant the "not stupid" bit. :)

Edited by Alyona Su

Share this post


Link to post
Share on other sites
11 hours ago, Gavin Hird said:

According to LL 15% of SL users are on macOS, and closer to 25% of the content creators are. So dropping the macOS viewer will impact their financial performance. 

I like to see some hard numbers for both of those. Sources ?

 

11 hours ago, Gavin Hird said:

What you tend to forget is that a Metal renderer will potentially broaden the market to the 1 billion iOS users. Not to be underestimated. Today's iOS HW is in many ways more capable than the desktops that ran SL only am few years back. 

 

Quote

2.4.2 Design your app to use power efficiently and be used in a way that does not risk damage to the device. Apps should not rapidly drain battery, generate excessive heat, or put unnecessary strain on device resources. source

 

While you might technically be able to render more polys with newer iOS GPU's. Do not mistake these pocket sized devices running on a couple of watts with <4gb ram to be in any way comparable to the processing required to make SL run badly on a desktop pulling hundreds of watts from the wall.

It's going to take a LOT more than metal to make rendered SL world scale content on iOS even remotely viable and that's assuming you can get it past the apple censors .. there is no way in hell it will not run the cpu pegged to 100%, run hot, or run your battery down in minutes.

 

Share this post


Link to post
Share on other sites

 

24 minutes ago, Alyona Su said:

Also, though there is still 15 months to go (give or take a couple) - people who don't follow macOS news tend to forget (or not know at all) that the removal of OpenGL was announced a long time ago (at least a year, if not two) - Apple does not turn on a dime. They tend to warn people (developers, specifically) of game-changing affects being made to the system with plenty of time to adapt. Surely, Linden Lab is not stupid; they have likely been working on this for quite some time already. If not then I recant the "not stupid" bit. :)

They have been trying to hire a graphics developer for a very long time now without success and currently have no code in place or even a public decision on what happens when Apple drop OpenGl. There are existing rendering changes that have been stuck on the pending pile, half complete, for months now because they have no spare graphics dev to work on them.

The ONLY confirmed positive sign that OSX will not just get dropped entirely is that Oz Linden is a Mac user. That is literally all we have. The guy running the developers uses a Mac.

There is a TPV meeting today, will ask.

Share this post


Link to post
Share on other sites
15 minutes ago, CoffeeDujour said:

There is a TPV meeting today, will ask.

Thank you. Though I do have a PC (which is what I am forced to use because Catznip outweighs the rest) - I do have hopes for continued macOX support. Because the LL Viewer on macOS is so much more pleasant to use (it just feels smoother and is certainly more beautiful to look at and SL is all about the visuals for me). :)

Share this post


Link to post
Share on other sites
3 hours ago, CoffeeDujour said:

I like to see some hard numbers for both of those. Sources ?

Numbers given as estimates by Oz in a TPV meeting. Ask them in the next for an update.

It was up for discussion when the Linux client was put on the back burner. Usage for Linux was said to be less than 1% of the user base. 

Share this post


Link to post
Share on other sites
4 hours ago, CoffeeDujour said:

I like to see some hard numbers for both of those. Sources ?

 

 

 

While you might technically be able to render more polys with newer iOS GPU's. Do not mistake these pocket sized devices running on a couple of watts with <4gb ram to be in any way comparable to the processing required to make SL run badly on a desktop pulling hundreds of watts from the wall.

It's going to take a LOT more than metal to make rendered SL world scale content on iOS even remotely viable and that's assuming you can get it past the apple censors .. there is no way in hell it will not run the cpu pegged to 100%, run hot, or run your battery down in minutes.

 

You'd run them in connected mode with a console keyboard plugged in for the iPhones.  The recent iPads would be useful as they are, but obviously powered if running anything but shorter sessions.

With no OpenGL you'd also have to completely redo all UI, which would be most efficient both memory wise and cooling speed wise to do in native iOS frameworks. These are also optimized the heck out of on Apple processors and GPUs. 

Most scenes will run comfortably in 2 GB application memory and far less GPU memory.  

Share this post


Link to post
Share on other sites

That's totally neglecting the whole "Design your app to use power efficiently ..." part of the Apple rules. 

Running from the mains is not a solution due to the way battery based power circuits in handheld devices are designed. SL on an iPad plugged into the power will dramatically shorten it's life and turn your irreplaceable battery into a balloon. The performance rules exist for very solid technical reasons that no amount of native iOS code woowoo can change.

Any mobile device left plugged in will have it's battery catastrophically fail. This is why you see bulging store displays - and those devices spend their short lives idle and cold. Running  hot and stressed will push the cells to fail significantly faster. This happens because of how the power delivery is designed.

SL is not just GPU heavy like a game, it's computationally heavy in ways the will peg the CPU to 100% and GPU heavy. This can not be avoided without major systemic changes to the way SL stores images server side .. which will never happen.

Power storage and delivery in mobile devices are not designed with this use case in mind.

Even Apple's own laptops are not designed with this use case in mind.

You can not expect a platform designed around a couple of chips with a max burst TDP of under 5W to stand it's ground with a desktop that can happily dump hundreds of watts all day every day.

 

 

 

Share this post


Link to post
Share on other sites
7 hours ago, CoffeeDujour said:

That's totally neglecting the whole "Design your app to use power efficiently ..." part of the Apple rules. 

Running from the mains is not a solution due to the way battery based power circuits in handheld devices are designed. SL on an iPad plugged into the power will dramatically shorten it's life and turn your irreplaceable battery into a balloon. The performance rules exist for very solid technical reasons that no amount of native iOS code woowoo can change.

Any mobile device left plugged in will have it's battery catastrophically fail. This is why you see bulging store displays - and those devices spend their short lives idle and cold. Running  hot and stressed will push the cells to fail significantly faster. This happens because of how the power delivery is designed.

SL is not just GPU heavy like a game, it's computationally heavy in ways the will peg the CPU to 100% and GPU heavy. This can not be avoided without major systemic changes to the way SL stores images server side .. which will never happen.

Power storage and delivery in mobile devices are not designed with this use case in mind.

Even Apple's own laptops are not designed with this use case in mind.

You can not expect a platform designed around a couple of chips with a max burst TDP of under 5W to stand it's ground with a desktop that can happily dump hundreds of watts all day every day.

 

 

 

You completely forget this is the mode a lot of high end games on iOS operate. 

No, it does not peg the CPU 100% - in case it does the machine is very weak or the viewer code is hozed. On my Macs - even if the GPU might be hovering at close to 100% utilization, the CPU runs pretty cool mainly utilizing one core only. The same will be the case on iOS, while Metal will offload even more to the GPU.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...