Jump to content

Gavin Hird

Resident
  • Content Count

    1,296
  • Joined

  • Last visited

Community Reputation

10 Good

About Gavin Hird

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. LOL I have not been in the market for a rendering engineer, preferably with Metal experience. Linden Lab has!
  2. Mavericks is 10.9 and there was no Metal till 10.11. 10.11 is when the crashes started, and this is when the NSOpenGLProfileVersionLegacystarted to be enforced strict. So what you reported for Mavericks is pretty much irrelevant. ;-)
  3. The NVIDIA driver does not support Metal, which is the reason why users will see a significant reduction in system frame rates over using the Apple driver on macOS 10.11 and 10.12. More importantly, the NVIDIA driver does not impose the restrictions of the Apple NSOpenGLProfileVersionLegacy where before Metal it was possible to call the OpenGL functions supported by the hardware directly, whereas after Metal in macOS 10.11 you can't do that any more with the Apple driver. This is why the code started to fail in 10.11.
  4. As opposed to you Cinder, I have an open acknowledged bug report with Apple Software Engineering on the subject and it is NOT the driver, it is the Linden code that is not being updated for deprecated functionality.
  5. No, they do not. Stop spreading misinformation Whirly! The crashes occur in the Linden code beaches it is using OpenGL extensions not available not the OpenGL 2.1 profile all viewers (including Firestorm) use on macOS. So it tries to write to GPU memory illegally, causing a GPU MMU reset. The good thing is that in out testing of Kokua and KokuaOS, these are significantly more stable on macOS 10.12.4. The same is the case with the SecondLife official viewer. The other viewers tested still crash or have strange mesh artifacting. I have sent an large number of stack traces to Apple the last year, and it seems they have been able to eliminate some of the conditions leading up to the crash, but in busy scenes the viewers will crash as before.
  6. There is a development build for the macOS version of Kokua at my Bitbucket that many find more stable than other viewers. It does not have Jelly Dolls and Bento, but otherwise it should work in SecondLife for now. If you have 512 Mb or less GPU memory, lowering this to 384 in the grapichs settings often increase stability. Also this version will crash in scenes with lots of mesh and many avatars, particularly with shadows and ambient occlusion turned on. These builds are signed with my Apple developer ID so you know where they come from.
  7. ChinRey wrote: LinuxGod4u wrote: That is a useful post. Are Mac Os(s) anything like Linux?? A good question and not easy to answer. Mac OS X is based on FreeBSD which of course is very similar but not identical to Linux. So there are many similarities but also significant differences. No it is not based on FreeBSD. It has a BSD subsystem that originally was based on FreeBSD, but was certified as Unix 03 later. The Mach kernel, the IO system, the Frameworks, the UI and development tools, including Swift are not Linux like at all. When the viewer was originally started, this was more true, and is what the viewer code is largely still stuck in making it increasingly incompatible for each version of macOS.
  8. Hi Thanks! Usually we have test builds every week and sometime more frequent depending on how big changes are. Right now we have a Bento Test build. If you want to file tickets and comment on them, you would have to create a user on SourceForge. It is not entirely unlikely there will be a JIRA from the beginning of 2017.
  9. We have another round of builds for the Kokua viewer that in our own testing lowers GPU reset rates from "will crash within 5 minutes" to "no crash in 2 1/2 hours" in the same test scene. Obviously we don't have a large selection of Apple hardware to test on so YMMW, but we encourage you to test the new builds. For these builds we also find that if you have 512 Mb or less graphics memory in your machine you will get a more stable system by setting the texture memory slider to 384 Mb in Graphcis Advanced preferences (Advanced - Hardware for OpenSim). You get the SecondLife version and the OpenSim version from SourceForge. NOTE, the GPU will still be reset under certain conditions, but this cannot be fixed unless the renderer is rewritten to support OpenGL 3.2.
  10. There are now SecondLife version builds of the Kokua viewer at Sourceforge that have the same code changes as the OpenSim version. This version should have the same functionality as the latest Linden release version. (most recent uploads) These versions should work better on macOS 10.11 and 10.12. As stated before they will crash the GPU in some scenes so ymmw.
  11. I am glad it improved the situation for you. We shall have to update the SecondLife version of Kokua too. Cheers!
  12. It is one of the dmg files at the top. (with and without RLV support). It is hard to say eactly why there is no priority of fixing the Mac version of the viewer, as in many ways the code it is made up of have rotted on root void of all the changes Apple have gone through since leaving the GCC compiler behind 6 major macOS versions back. Most of this time I have been an observer, rather than an active contributor to a Mac version of the viewer, but my major observation is there is an inbred disdain of anything Apple both in Linden Lab, which also extends to the much larger section of the user base and developers.
  13. Whirly Fizzle wrote: If you are using the Nvidia web drivers though, you won't crash. The crash only happens if the system is using the Apple Nvidia drivers. You can use the NVIDIA drivers, but they are both a bit hard to find, and tied to a specific macOS build so they break at just about every update. They are only meant for the Mac Pro, but they happen to work on other machines too. Here is a link to a site that maintains links to the drivers. Make sure you download the one for the macOS build number (can be easiest found from the System Report function linked to "About This Mac" on the Apple menu. This is, however, only a stopgap, and no excuse for LL not to fix the viewer code (that 25% of their contet developers relies on in one for or another.)
  14. No,it is not viewer specific, but GPU specific. As far as I know the Radeon GPUs are not affected like the NVIDIA ones. – Which is why your iMac is good. The crash is more pronounced on macOS 10.12 than on 10.11. Per my findings the crash on 10.11 occurs in the culling code; the code that caclulates what part of the scene is visible and shall be rendered. It manifest itself in scenes with medium to high content of mesh items when shadows are turned on. On 10.12 in addition the code that calculates ambient occlusion will crash the viewer, and this can be provoked by only turning ambient occlusion on. There is a jira for the crash, but as far as I know nothing have been done but acknowledge the fact. More important Apple Engineering has been able to repro the crash on the SecondLife viewer with the OpenGL 2.1 profile that the Mac version of all viewers use. To fix it, the Mac version must use a OpenGL 3.2 profile for the renderer as a minimum (and be made Metal aware). We have a development version of Kokua for OpenSim where the ambient occlusion issue is partly squashed. You can still log on to SecondLife with this version of the viewer.
  15. Krystal Iridescent wrote: I am surprised that nobody has recommended Alchemy Viewer yet? I have run it for at least two years on my Macbook Pro mid 2012 model and now that I updated to Sierra, it is still by far the best viewer to use. Depeding on your Macbook Pro model it may only have Intel graphics, and is therefore not affected. Macs with descrete grapichs (and some of them also have Intel graphics in addition) will also crash the Alcmehy viewer in the same manner as the other viewers. Turning on Ambient Occlusion will crash the viewer as the crash happens in the occlusion code overwriting memory in the GPU leading to a GPU reset. Turning on shadows will accomplish the same, but usually faster the busier the scene is.
×
×
  • Create New...