Contrary to another user's post about the Catalyst 11.2 drivers solving the segmentation fault inherent in 11.1, I'm still finding Houdini crashes out with a segmentation fault quite regularly on 11.2.

It's definitely the video drivers, as rolling back to 10.9 fixes the problem on my system. This in itself is of course a solution, but I'd like to be able to keep my graphics drivers up to date *and* work with Houdini (perhaps too much to ask?).

Both AMD customer care and SideFX support told me to buy a workstation-class graphics card (!) which I think is appalling advice for software that costs $99 (Apprentice HD).

So the question is: is there anything I can do to fix AMD's OpenGL drivers? I noticed a developer post something about playing with the Catalyst application profiles to get 11.2 to correctly display viewport normals; does anyone know how I might customize a Houdini profile to test out some different OpenGL parameters?

In the meantime I'm stuck using HOUDINI_OGL_SOFTWARE = 1 until the next Catalyst release or my playing around fixes this, which is ridiculous when there's a £200 graphics card sitting there.

Most thankful for any suggestions,

Andrew

P.S. This *never* used to happen on my nVidia cards…

Contrary to another user's post about the Catalyst 11.2 drivers solving the segmentation fault inherent in 11.1, I'm still finding Houdini crashes out with a segmentation fault quite regularly on 11.2.

Is there anything that you've noticed triggers this? What graphics card is installed?

It's definitely the video drivers, as rolling back to 10.9 fixes the problem on my system. This in itself is of course a solution, but I'd like to be able to keep my graphics drivers up to date *and* work with Houdini (perhaps too much to ask?).

That's definitely a rocky road when dealing with consumer drivers. They are released quite frequently and seem to be more feature-laden than the pro drivers, which I've found to be more stable over time. Could be the amount of testing and types of applications tested that is a factor. We also don't get access to early versions of these drivers, as we are considered a workstation-class software developer by AMD and Nvidia and receive workstation support instead (though they will both fix OpenGL spec violations and bugs on any driver).

Both AMD customer care and SideFX support told me to buy a workstation-class graphics card (!) which I think is appalling advice for software that costs $99 (Apprentice HD).

We recommend professional cards mostly because of driver stability, though the extra VRAM and performance improvements for workstation apps doesn't hurt. I know price is a big factor in the decision there, but luckily both vendors are beginning to introduce mid-range and low-end parts at a more reasonable price point than they were in the past.

Driver regressions are more common in consumer drivers than the pro drivers, which translates into hassle for the user. That is why we also state on the systems requirement page, “Non-workstation cards, such as GeForce and Radeon, can be used at your own risk. They may be used for learning and personal use but they are not supported as you may experience display problems, slow performance, and the software exiting unexpectedly”. But we certainly couldn't recommend any hardware under those circumstances.

IMO, I suspect AMD and Nvidia recommend pro cards because a) they likely don't want to spent a lot of effort supporting professional apps in drivers targeted to games, b) they already have pro drivers specifically designed for workstation apps, and c) directly supporting workstation-class apps in consumer drivers would cut into their higher-margin pro card sales, which doesn't make much business sense.

We do try to avoid features that are definitely professional-class, such as overlay and underlay planes, but some desirable pro features are restricted to workstation hardware, such as windowed, stereoscopic 3D with shutter glasses.

So the question is: is there anything I can do to fix AMD's OpenGL drivers?

If you notice a pattern to the crashes, that might help me workaround whatever is causing the problem, or at least isolate it enough that I can report it to AMD. You can also try disabling some of Houdini's OpenGL3 features:

- disable Material Shaders in the 3D Display Options
- if that fails, try setting the environment variable HOUDINI_OGL_DISABLE_FBO = 1

In the meantime I'm stuck using HOUDINI_OGL_SOFTWARE = 1 until the next Catalyst release or my playing around fixes this, which is ridiculous when there's a £200 graphics card sitting there.

Agreed. HOUDINI_OGL_SOFTWARE is a last ditch effort, and should not be necessary with a discrete graphics card purchased in the last 5 years.

twod, thank you so much for your comprehensive response - it's a real pleasure to be able to engage directly with developers on technical matters such as this.

I have thus far identified no pattern in the segmentation faults; they’ve occurred when manipulating the viewport as well as simply saving the hip file (!). The crash logs always seem to trace back to graphics related function (such as a UI event or, most recently, a DrvPresentBuffers event). My graphics card is an ATI Radeon HD 5870 (1GB), supplied with my brand-new Sandy-Bridge system from Dell only a month ago. (Yes, the motherboard is going to need replacing in time, but that’s another problem…)

I appreciate that Houdini is designed to run on workstation-class hardware, and that consumer parts are ‘at our own risk’ and I totally get why it’s not in AMD’s interests to spend much time debugging their OpenGL drivers, especially when they can eek out an additional FPS or two in some-game-or-another. That said I’m most grateful for your support.

Since posting I’ve tried bastardizing ATI’s OpenGL drivers by manually replacing several ati*.dll files in System32, and in every case Houdini failed to load stating that the various dlls were non-executable. I used Process Monitor to identify the unique ati dlls called upon by Houdini, but without further assistance I don’t think I’m going to have any luck proceeding with this approach. I don’t suppose you’d know how to replace the specific OpenGL files used by Houdini with those from Catalyst 10.9?

I’ve disabled both Material Shaders in the viewport and also set HOUDINI_OGL_DISABLE_FBO = 1. Thus far no segmentation faults although I haven’t thoroughly tested my scenes yet, and the only perceptible difference is that the display options dialog complains that the beauty composite failed to compile and color correction is not supported. Can you tell me a little more about what HOUDINI_OGL_DISABLE_FBO actually does? If this fixes the problem I’d like to know if there are any specific implications to Houdini’s feature set.

Again, thanks so much for your assistance so far.

Andrew

Nope: still crashing. I think I was working in the parameters pane when it happened this time. Latest crash log - which incidentally is quite typical of the segmentation faults I'm getting - is as follows:

Caught signal 11
+0x730759da
+0x731ae3a4
+0x702afc0f
+0x7025438f
+0x702544bf
+0x702545b8
+0x70232f10
+0x711da8ff
+0x711daebf
+0x4000187c
+0x777ff56d
+0x77a32cc1

Does this shed any light on what the problem might be?

Could be front buffer rendering - if you box select in the viewport or network editor, does it crash?

No, box selecting in viewport or network editor doesn't cause a segmentation fault. Just had another one whilst I was switching desktops from Image to Build, and the crash log looks just like the last.

(Incidentally, now just noticed what the 11.2 drivers do to material shading in the viewport: hence your suggestion to switch off Material Shading in the display options I presume?).

Is there anything I can do to trace what's happening from the operating system side? Are there any system utilities you would recommend using to capture the specific set of calls that lead up to the segmentation fault, or does the crash log explain all?

Andrew

I don't know if that particular crash is video related; I'll have to do a bit of digging first.

Turning off Material Shaders cuts out almost all of the shaders in the viewport, and the shading uses the old OpenGL 1.x fixed function pipeline. It's a surefire way of avoiding any GLSL compiler issues and bugs that might be present in an OpenGL 2 or 3 implementation.

I'm still getting segmentation faults with the same crash log:

Traceback from Fri Mar 18 12:17:10 2011
Caught signal 11
+0x730759da
+0x731ae3a4
+0x702afc0f
+0x7025438f
+0x702544bf
+0x702545b8
+0x70232f10
+0x711da8ff
+0x711daebf
+0x4000187c
+0x76c6f56d
+0x76ea2cc1

Does anyone have any suggestions to prevent this from happening? Does it actually have anything to do with the graphics drivers or not?

Okay, here's some thoughts:

Is there any way of dynamically switching graphics drivers (I suspect not, as a google search on the subject didn't turn anything up of relevance).

What about running Houdini in a virtualized environment, with legacy graphics drivers installed on the virtual machine? Has anyone tried running Houdini on a virtualized OS? Were there any problems?

Finally, I suppose I could dual-boot two installations of Windows - using one just for Houdini with the legacy video drivers installed. I have no idea how my OEM license of Windows 7 would react to that, however (might not activate).

Any thoughts?

Is there any way of dynamically switching graphics drivers (I suspect not, as a google search on the subject didn't turn anything up of relevance).

I don't think so, I've never heard of it being done for the same hardware.

What about running Houdini in a virtualized environment, with legacy graphics drivers installed on the virtual machine? Has anyone tried running Houdini on a virtualized OS? Were there any problems?

If you can find virtualization software that properly virtualizes graphics… it's not very common.

Finally, I suppose I could dual-boot two installations of Windows - using one just for Houdini with the legacy video drivers installed. I have no idea how my OEM license of Windows 7 would react to that, however (might not activate).

If Win7 was already installed, it should work ok. If not, you'll have to install it to a new drive and switch boot drives in the BIOS, or grab a bootloader that will allow you to pick the OS.

I installed Win7 64b on a machine that had a Vista32 installation on a separate drive, and then used the install disk to recover that installation. Now the boot process gives me the option to load either one.


However, I think the best route it for me to try to get it resolved with AMD or isolate the issue and attempt a workaround. I haven't encountered a crash yet, though. The normal shading issue has already been worked around as of 11.0.688.

Thanks, twod.

Would it help if you had more information about my system? I'll happily post or PM you my complete system spec if necessary. In summary, it's an uncustomized Dell XPS 8300 with a Sandy Bridge H67 platform, i7-2600K CPU, HD5870 GPU, and 8GB RAM running Windows 7 Home Premium 64-bit. All my software, including anti-virus, is exactly the same as my previous system - on which Houdini worked practically flawlessly - with the exception of certain drivers to support the new hardware (including the troublesome Catalyst drivers).

Are there any diagnostic tools you'd recommend I try myself? I've been using Sysinternals' procmon and some of the Debugging Tools for Windows (adplus) to identify the problem, however the former doesn't seem to tell me anything useful and the latter refuses to dump any useful information without the appropriate ‘symbols’. Something to do with a .pdb file? (This is where I start reaching the limits of my debugging knowledge). Are pdb's for the libOPUI.dll file available in the SDK? Does what I just said even mean anything?

I've read a little about dual booting the same copy of Windows 7 from two seperate partitions, and I understand that Windows itself would then give me the option of which partition to boot from. Unless you / I / anyone else comes up with an alternative workaround I'll probably try this approach in the short term, and keep an eye out for new Catalyst drivers and Houdini releases (I only ever download the production builds). That said, I still appreciate any further support you can offer.

Regards,

Andrew

Thought I'd draw a line under this thread and document my workaround to this problem.

I succeeded in re-installing identical images of Windows 7 onto two seperate partitions on my hard drive; one with the legacy Catalyst Drivers (10.9) for running Houdini and another with the latest drivers and software for everything else. My OEM Windows licence doesn't seem to mind this and both installations are regarded as ‘genuine’.

And it works. I simply have to select which installation of Windows I want to use at boot time (or let it time out to the default). Learn't how to do it all by googling ‘dual-boot’ and whatnot. It turns out there's a built-in boot manager in Windows 7 that you can use to configure your different Windows installations.

Of course this means that one can't ‘hot-switch’ between operating systems, but a short reboot is all that is needed to switch from one to the other. Far better than virtualisation as each OS has direct access to the hardware, keeping performance as high as possible.

Maybe one day AMD's catalyst drivers will work again with Houdini. I'll keep testing. Thanks, twod, for your assistance.