Re: [opensource-dev] Mac viewer and Apple maintained opensource libraries

[Henri Beauchamp]

On Thu, 2 Feb 2017 08:14:21 +0100, Geir Nøklebye wrote:

> The viewer still crash in the occlusion code, but not as often as
> without these changes.

Meaning you actually didn't fix anything...

Stupid question: what happens if you disable the Objects occlusion
setting in the graphics preferences ?

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Mac viewer and Apple maintained opensource libraries

[Geir Nøklebye]

This is the typical anatomy of the crash that accompanies the GPU reset.  It 
also crash even if you turn of shadows and ambient occlusion, but then with 
much lower frequency, 


Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   com.apple.GeForceGLDriver   0x906aeb6c 0x9037e000 + 3345260
1   com.apple.GeForceGLDriver   0x905a9c99 gldGetQueryInfo + 77
2   GLEngine0x981decd0 glGetQueryObject_Core + 311
3   GLEngine0x981deda2 glGetQueryObjectuiv_Exec + 47
4   libGL.dylib 0x97590a00 glGetQueryObjectuivARB + 29
5   org.kokuaviewer.KokuaOS 0x01342ef7 
LLOcclusionCullingGroup::checkOcclusion() + 2071
6   org.kokuaviewer.KokuaOS 0x015d3cf3 
LLPipeline::stateSort(LLCamera&, LLCullResult&) + 1539
7   org.kokuaviewer.KokuaOS 0x015f85f1 
LLPipeline::renderShadow(glh::ns_float::matrix4&, glh::ns_float::matrix4&, 
LLCamera&, LLCullResult&, bool, bool, unsigned int) + 705
8   org.kokuaviewer.KokuaOS 0x015ff3e6 
LLPipeline::generateSunShadow(LLCamera&) + 17350
9   org.kokuaviewer.KokuaOS 0x011bf1c0 display(int, float, int, 
int) + 12304
10  org.kokuaviewer.KokuaOS 0x003055b3 LLAppViewer::mainLoop() + 
9523
11  org.kokuaviewer.KokuaOS 0x00347edb runMainLoop() + 43
12  org.kokuaviewer.KokuaOS 0x002b4543 -[LLAppDelegate mainLoop] + 
19
13  com.apple.Foundation0x95e11796 __NSFireTimer + 97
14  com.apple.CoreFoundation0x946bacc6 
__CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 22
15  com.apple.CoreFoundation0x946ba7dd __CFRunLoopDoTimer + 1213
16  com.apple.CoreFoundation0x946ba27e __CFRunLoopDoTimers + 350
17  com.apple.CoreFoundation0x946b1de0 __CFRunLoopRun + 2192
18  com.apple.CoreFoundation0x946b12ea CFRunLoopRunSpecific + 506
19  com.apple.CoreFoundation0x946b10db CFRunLoopRunInMode + 123
20  com.apple.HIToolbox 0x93db0d36 RunCurrentEventLoopInMode + 
268
21  com.apple.HIToolbox 0x93db0b22 ReceiveNextEventCommon + 494
22  com.apple.HIToolbox 0x93db091b 
_BlockUntilNextEventMatchingListInModeWithFilter + 83
23  com.apple.AppKit0x9257bfed _DPSNextEvent + 1227
24  com.apple.AppKit0x92ce0274 -[NSApplication(NSEvent) 
_nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1742
25  com.apple.AppKit0x92cdfb9e -[NSApplication(NSEvent) 
nextEventMatchingMask:untilDate:inMode:dequeue:] + 132
26  com.apple.AppKit0x92570c88 -[NSApplication run] + 943
27  com.apple.AppKit0x9253dc26 NSApplicationMain + 1368
28  libdyld.dylib   0x9f7883b5 start + 1


I forgot to mention I always build with RelWithDebInfo and -O3 optimization to 
get Apple’s crash reports. I have turned off as much of Breakpad as possible 
without ripping it completely out. To debug macOS applications without Xcode 
debugging and the system generated crash reports is almost impossible.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Mac viewer and Apple maintained opensource libraries

[Whirly Fizzle]

We already tried getting Firestorm users to disable Object-Object occlusion.

This didn't affect the frequency of the crashes at all.


As Geir said, lowering the texture memory does seem to lessen the frequency of 
the crashes, but this causes increased texture thrashing so it is not really a 
good workaround, though I guess increased texture thrashing is preferable to 
crashing all the time.

The only "good" workaround found so far is switching to using the Nvidia web 
drivers.

This is not always possible though, for example the guy on 
https://jira.secondlife.com/browse/BUG-40674 is stuffed because there are no 
web drivers available for his card.

His only option is to roll back to Mavericks to fix the crashes.



From: opensource-dev-boun...@lists.secondlife.com 
 on behalf of Henri Beauchamp 

Sent: 02 February 2017 12:42
To: opensource-dev@lists.secondlife.com
Subject: Re: [opensource-dev] Mac viewer and Apple maintained opensource 
libraries

On Thu, 2 Feb 2017 08:14:21 +0100, Geir Nøklebye wrote:

> The viewer still crash in the occlusion code, but not as often as
> without these changes.

Meaning you actually didn't fix anything...

Stupid question: what happens if you disable the Objects occlusion
setting in the graphics preferences ?

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
OpenSource-Dev - Second Life 
Wiki
wiki.secondlife.com
Posting Policies and Guidelines. The opensource-dev mailing list is for 
development issue related to Second Life open source code. The following 
policies ...


Please read the policies before posting to keep unmoderated posting privileges
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Mac viewer and Apple maintained opensource libraries

[Geir Nøklebye]

Henri said:

> Meaning you actually didn't fix anything...

> Stupid question: what happens if you disable the Objects occlusion
setting in the graphics preferences ?

The root cause of the problem is not fixed, no. It put some bandaids on it to 
reduce the crash frequency. The autoreleasepool issues are “real” fixes, as it 
is both deprecated and won't even compile on Xcode 8. 

If you turn off shadows but with Ambient Occlusion turned on, with the latest 
KokuaOS builds I can stay in a scene even for hours. Other viewers will crash 
after a few minutes with only Ambient Occlusion turned on.  With Shadows turned 
on in addition I can use the viewer for extended periods in some scenes (more 
than 10 minutes) that before would crash it within 2 minutes. Latest Cool VL 
will crash within 30 seconds of turning on shadows. – InstaCrash™  For the user 
it is immaterial of you crash after 30 seconds of 2 minutes, the viewer is for 
all practical purposes useless. 

I have SL users who have been on the brink on reverting to macOS 10.10, but can 
stay in SecondLife with the KokuaOS builds. 

If you turn off Objects occlusion it does not make any difference. It is 
Ambient occlusion and shadows that is the big killer (see the crash signature I 
posted before.) 

We have also made some adjustments to the NSOpenGLPixelFormatAttribute attrs[] 
statement such as turning on supersampling as that will help on Retina displays 
in particular as the scene will be rendered at much higher resolution and then 
downsampled to the screen resolution in the desktop compositing phase. 
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Mac viewer and Apple maintained opensource libraries

[Cinder Roxley]

On February 2, 2017 at 9:08:44 AM, Geir Nøklebye (geir.nokle...@dayturn.com 
 ) wrote:
 
Henri said:

> Meaning you actually didn't fix anything...

> Stupid question: what happens if you disable the Objects occlusion
setting in the graphics preferences ?

The root cause of the problem is not fixed, no. It put some bandaids on it to 
reduce the crash frequency. The autoreleasepool issues are “real” fixes, as it 
is both deprecated and won't even compile on Xcode 8. 


It actually isn’t, as was already discussed on this list several months ago at 
length… but keep sipping that koolaid from the company who can’t even implement 
fork() properly and removes features from its own OS because it crashes their 
3D driver.

-- 
Cinder Roxley
Sent with Airmail
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Mac viewer and Apple maintained opensource libraries

[Geir Nøklebye]

@Cinder

With reference to Xcode 8 release notes, section Deprecations it reads:

 OS X 10.11 was the last major release of macOS that supported the previously 
deprecated garbage collection runtime.  Applications or features that depend 
upon garbage collection may not function properly or will not launch in macOS 
Sierra. Developers should use Automatic Reference Counting (ARC) or manual 
retain/release for memory management instead. (20589595)

https://developer.apple.com/library/content/releasenotes/DeveloperTools/RN-Xcode/Introduction.html

This was enforced in the Xcode 8 beta program, but was eased at release, but I 
believe it will be reintroduced in the forthcoming 8.3 release as it again 
appears in the 8.3 beta release notes. 

Referring to Apple developer notes on deprecations and changes as koolaid 
pretty much says it all.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Mac viewer and Apple maintained opensource libraries

[Cinder Roxley]

On February 2, 2017 at 2:57:13 PM, Geir Nøklebye (geir.nokle...@dayturn.com 
 ) wrote:
 

@Cinder 

With reference to Xcode 8 release notes, section Deprecations it reads: 

OS X 10.11 was the last major release of macOS that supported the previously 
deprecated garbage collection runtime. Applications or features that depend 
upon garbage collection may not function properly or will not launch in macOS 
Sierra. Developers should use Automatic Reference Counting (ARC) or manual 
retain/release for memory management instead. (20589595) 

https://developer.apple.com/library/content/releasenotes/DeveloperTools/RN-Xcode/Introduction.html
 

This was enforced in the Xcode 8 beta program, but was eased at release, but I 
believe it will be reintroduced in the forthcoming 8.3 release as it again 
appears in the 8.3 beta release notes. 

Referring to Apple developer notes on deprecations and changes as koolaid 
pretty much says it all. 


Please see last July when you were already banging this drum and it was 
explained multiple times that the viewer never used GC so your claim was 
misinformed and the deprecation irrelevant to sl viewer:
https://lists.secondlife.com/pipermail/opensource-dev/2016-July/thread.html#10248

I won’t waste any further time on this. Enjoy spamming the list and pulling our 
changes. :)

-- 
Cinder Roxley
Sent with Airmail
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges