twod
Glad you found a workable solution. No idea why it works.

EDIT: update to the below. Looks like you can trick Houdini to have all the features of the Nvidia driver, full quality OpenGL, but with the stability of the AMD driver. You have to RMB on the dock icon, set the ‘Desktop on Display 2’ which is the AMD screen, then when you launch Houdini on the Nvidia monitor it does not crash. So perhaps if we had an env variable like ‘set OpenGL vendor’ then we could force Houdini to be stable on all OsX GL systems…

EDIT: OLD-> Looks like it enforces all the same disabled AMD features i.e. no anti-aliasing, dithered transparency etc on the Nvidia card. Glad for the stability but not so pretty…

tiny particle
Is opencl acceleration still out of question on Mac OSX platform ?

OsX/OpenCL GPU is working since H14. Unfortunately OpenCL CPU is still out on OsX.

Hi, for what it worth…

I'm runing some test from some times now with houdini on OSX and i found the obvious isn't OSX but ATI cards.

My old MacPro with a PC recent Nvidia card is WAYYY more stable than a latest 2015 macbookpro (the ones with two video cards ATI+intel). Houdini behave just like on linux ;-)

On the MBP even the selection “highlight” cause big troubles and lead to a hang of somes seconds.

Did you try it by disabling the integrated graphics card and use only the dedicated one ?

NNois
Hi, for what it worth…

I'm runing some test from some times now with houdini on OSX and i found the obvious isn't OSX but ATI cards.

My old MacPro with a PC recent Nvidia card is WAYYY more stable than a latest 2015 macbookpro (the ones with two video cards ATI+intel). Houdini behave just like on linux ;-)

On the MBP even the selection “highlight” cause big troubles and lead to a hang of somes seconds.

NNois
My old MacPro with a PC recent Nvidia card is WAYYY more stable than a latest 2015 macbookpro (the ones with two video cards ATI+intel). Houdini behave just like on linux ;-)

Agreed! Happily binned Windows and Linux currently as there has been only one GL crash, today, in the last 8 days.

A bit surprised that native Nvidia is working well for you, though, as if I place a bone, viewport tab-> bone, it's instant GL crash, whereas if I do the weird setup where you set the Dock Icon to launch Houdini on the AMD screen but then use it on the Nvidia screen, there is no crash. :roll:

H15.0.340, OsX 10.11.2, AMD 7950, Nvidia 980Gtx.

MartybNz
A bit surprised that native Nvidia is working well for you

I use the nvidia web driver and a flashed bios on the nvidia card.

But excuse me but how can you have more than one graphic card on the macpro without adding an extra power source ?? more exactly, why using the old ati one ?

Yes, external PSU. Using it for openCL compute, whilst Octane/Substance/openGL use the main Nvidia card. OsX OpenCL in Houdini runs more efficiently on AMD, so the AMD computes as fast as the Gtx980 even though on Windows/Linux the Nvidia is much faster.

Surprisingly the card may be damaged now after crashing the system whilst leaving OpenCL on running a large water sim; the system now randomly freezes whilst doing simple things, more testing needed though. Hopefully it's something else!

Guess Houdini is so stable now it can be pushed to breaking the machine

PS. have had a few more GL crashes using Flip fluids but still more stable than native Nvidia.

EDIT: looks like you can get around the bones crash by using the shelf instead of the tab menu

EDIT 2: ‘bone’ crashes but ‘bones’ doesn't, using the tab menu in the viewport. Creating bone in the Network view is fine.

Looks like the solution to the problem I was having with H15 on the Mac Pro versus Windows, with strange busy pointers updating Alembic Archives, has to do with Houdini's default near clipping plane, which is why none of the cameras embedded within the Alembics coming from Soft or Maya caused any issues, as their cameras are completely jacked up apart from focal length and spatial transformation.

Creating a new camera and using the default of 0.001 immediately causes severely decreased performance, in any viewing mode, if looking through that camera at Alembic geometry. Drop it to 0.01 and, voila, no more problems.

Stability has been pretty good for me since figuring this out. Now the only annoyance I've had is this pesky Orbolt shader that breaks if you copy->paste it from one HIP into another. Insult to injury is that it appears that saving presets for shader networks is currently busted (Win or OSX it shows me a pop-up menu for adding markers).

Sean Cunningham
Creating a new camera and using the default of 0.001 immediately causes severely decreased performance, in any viewing mode, if looking through that camera at Alembic geometry. Drop it to 0.01 and, voila, no more problems.

What hardware are you running? I tried this and couldn't reproduce the slowdown.

What is happening is that the far:near ratio is getting too large, and z-buffer precision would be adversely affected (objects would start to overlap in odd ways). So the viewport turns on depth clamping which eliminates the near/far clipping, and does the clipping manually using 2 clip planes. This way, z-buffer precision is preserved but it's also only applied to part of the near:far range - objects near both planes might not be Z-resolved correctly, but at least the vast majority of the viewing frustum will be resolved correctly.

For some reason that method appears to cause the OSX driver to drop to software.

MartybNZ
EDIT: looks like you can get around the bones crash by using the shelf instead of the tab menu Smile

EDIT 2: ‘bone’ crashes but ‘bones’ doesn't, using the tab menu in the viewport. Creating bone in the Network view is fine.

Unfortunately I can't reproduce a bone crash on 10.11.2 with a Quadro 4000, using the above method (or any other method).

twod

Sean Cunningham
What hardware are you running? I tried this and couldn't reproduce the slowdown.

SESI couldn't either when I put the ticket in, supplied an Alembic, etc. It's a MacPro 6,1 or the “Late 2013” with 6-core 1650 v2 Xeon and dual D500 graphics with 32Gb.

I swapped systems with another artist and had been running a 5820K with the same RAM and a 780Ti so this Mac should be a slight bump in power computationally on the CPU, for float, and a fairly substantial bump in GPU…if this weren't, from a driver and Apple priority standpoint, a massively over-engineered system for 2D software. It's a shiny black can if irony is what it is.

Sean Cunningham
I swapped systems with another artist and had been running a 5820K with the same RAM and a 780Ti so this Mac should be a slight bump in power computationally on the CPU, for float, and a fairly substantial bump in GPU…if this weren't, from a driver and Apple priority standpoint, a massively over-engineered system for 2D software. It's a shiny black can if irony is what it is.

Yeah. It's unfortunate that they put so much design effort into the hardware of the new MP, and then seemingly forgot about the software (driver).

I'll swap a Rad 5770 into my cheese grater Mac and see if I can reproduce the problem with that card.

twod
Unfortunately I can't reproduce a bone crash on 10.11.2 with a Quadro 4000, using the above method (or any other method).

Cool, thanks for testing it! Please let us know if there is a way to force Houdini to use the AMD driver when booting too. That way I move the external PSU and AMD card 8)

twod
Yeah. It's unfortunate that they put so much design effort into the hardware of the new MP, and then seemingly forgot about the software (driver).

I'll swap a Rad 5770 into my cheese grater Mac and see if I can reproduce the problem with that card.

And it's not like AMD has a great reputation at the consumer level for drivers on the Windows side either. My mom actually works at AMD as an admin in the division that does about 80% of their total business that nobody talks about, which is the custom and semi-custom applications.

I feel bad generally having nothing but criticism for the company despite the fact that the hardware itself kicks ass but, like her previous employer Motorola, they don't really “get” the importance of software or that all Nvidia has to do is just have slightly more reliable drivers (or even just the perception of more reliable drivers) to keep “winning”.

They do better in the custom/semi-custom sphere and with landing corporate clients, like for the game consoles, where it's implicit that the buyer is perhaps doing all of their own tailored narrow focused software.

I was hoping that the upgrade to El Capitan was going to magically make it better but no such luck. In the meantime, all I have to do is drop my near clip to 0.1 or 0.01 and I'm good and haven't run into a problem yet where I need something closer to the camera. I'm sure it'll happen but, worse comes to worse, I can have different settings for rendering and different settings for interactive.

And in all likelihood this MacPro will move to being an extremely over-qualified editorial workstation and I'll get another PC (sniff!).

Thanks

MartybNz

twod
Unfortunately I can't reproduce a bone crash on 10.11.2 with a Quadro 4000, using the above method (or any other method).

Cool, thanks for testing it! Please let us know if there is a way to force Houdini to use the AMD driver when booting too. That way I move the external PSU and AMD card 8)

If I figure something out on that front, I'll let you know. Unlike OpenCL, you're at the mercy of what GPU the OS decides to give you.

I still find it somewhat baffling that your method of forcing AMD-then-Nvidia works on OSX, which may point to my complete misunderstanding of how the GL layer works on that platform. Apple unfortunately doesn't make much of that public. But I'm glad you've found a workaround regardless of how bizarre it is

Sean Cunningham
I feel bad generally having nothing but criticism for the company despite the fact that the hardware itself kicks ass but, like her previous employer Motorola, they don't really “get” the importance of software or that all Nvidia has to do is just have slightly more reliable drivers (or even just the perception of more reliable drivers) to keep “winning”.

I came across an interesting blog post on the GL driver issue a few weeks ago. The links in the article are pretty informative as well.

http://blog.mecheye.net/2015/12/why-im-excited-for-vulkan [blog.mecheye.net]

AMD unfortunately gets a lot of flak because Nvidia's GL implementation is very forgiving, and AMD sticks closer to the actual GL spec (though there are some bugs too, esp. on Linux and OSX). Apple's GLSL compiler is also very literal when it comes to the GLSL spec, but also rather buggy too so sometimes it's difficult to determine who's actually at fault (I'd much rather be at fault, since I can fix it rather than waiting for a third party to fix it).

Vedi, vedi interesting!

Fwiw - I can confirm that the ‘bone’ crash does not happen with the ‘OsX Default Nvidia Driver’ with the GT120. Unfortunately I can't force the 980Gxt to use the same trick with it, as I do with the AMD driver.

MartybNz
Fwiw - I can confirm that the ‘bone’ crash does not happen with the ‘OsX Default Nvidia Driver’ with the GT120. Unfortunately I can't force the 980Gxt to use the same trick with it, as I do with the AMD driver.

Yep, definitely the Nvidia proprietary driver - I can reproduce it on the Q4000 when I download it from Nvidia. Oddly enough, it's crashing when drawing the arrow of the Length handle that the Bone state uses (but Bones does not).

Also 10.11.3 was just released, but with the usual extra-lean release notes. It hasn't hit my App store upgrade section yet.

Edit: Same crash on 10.11.3 with the Nvidia proprietary driver. I'll raise this issue with Nvidia.

twod
Yep, definitely the Nvidia proprietary driver - I can reproduce it on the Q4000 when I download it from Nvidia. Oddly enough, it's crashing when drawing the arrow of the Length handle that the Bone state uses (but Bones does not).

Dug into this; commenting out line 130 of lighting_model_fast.func, # vec3 V = -normalize(P); stops the web driver crashes.

OsX 10.10.5, Nvidia 980Gtx 346.02.03f05, H15.0.426.

NB. Was going to log the bug but the webform still doesn't work on Safari. No Captch appears.

MartybNz
Dug into this; commenting out line 130 of lighting_model_fast.func, # vec3 V = -normalize(P); stops the web driver crashes.

Probably because the shader will no longer compile if you do that, avoiding the problem altogether. Your geometry won't appear if you do that, so not exactly a good workaround.

I'll keep an eye out for viewport issues but it's all looking fine so far - geo, shader, lights etc. Will give a good test over the coming times. Just happy to not to be crashy, well not yet so far

The old AMD card launching trick won't work anymore as the card was fried by an OpenCL sim! TDR not so foolproof on OsX it appears!