Graphics driver problems


What we observed in our work with OCCT and graphics drivers (NVIDIA mostly) is that the application behaves differently depending on the settings/profile we use.

For example, until recently I had had a driver from December 2012 for my Quadro 1000M. In an OCCT application, which performs motion simulation I observed very high memory consumption and slowdown during the simulation was running (with opened local context). The memory was freed after returning to neutral point. No problem on my colleagues' PCs. But we had some customers who reported similar problem.

Trying to solve the issue I just switched the settings from "3D OpenGL Stereo" to "3D App - Visual Simulation". The problem was gone - no excessive memory consumtion during the simulation! Then I updated my graphics driver and switched back to the "3D OpenGL Stereo" profile. Everything works fine too!

Apparently, the problem was the implementation of the graphics driver. We also had similar issues in the past on various NVIDIAs with different symptoms (including crashes).

My question is: has anyone faced similar problem? Do you have any idea how to test the graphics driver if it is OCCT compatible or to find out which settings should be used to get maximum performance / avoid problems?


Sergey Anikin's picture

Dear Pawel,

The question you have raised is really interesting, I have to admit I do not have an immediate and clear answer.

Concerning the quick compatibility check, I can imagine:

  • A DRAW script that involves the key visualization capabilities: shape visualization in wireframe and shading using OpenGL, OpenCL ray tracing, GLSL shaders (Phong shading), stereo (if supported by HW), probably anything else?
  • A subset of existing OCCT visualization tests corresponding to the above-mentioned visualization capabilities

It would be great if you tried to check/prototype one of these solutions or some of your own ideas and shared the results with the community.

And concerning the particular NVIDIA Quadro mobile series, it seems to be a known issue that NVIDIA drivers shipped with this hardware are sometimes less reliable and contains more bugs than e.g. those for desktop and gaming solutions. Thus I would rather consider your example with Quadro 1000M as an exception. For most of graphic hardware, it is not necessary to fine-tune 3D settings, and OCCT visualization seems to work well.
However, we would be glad to accumulate experience in this area, and we are also ready to consider all your ideas to elaborate together a sort of guide for 3D visualization troubleshooting.

Pawel's picture

Dear Sergey,

I don't have any precise statistics on that but we've faced the described problems on many different graphics cards (NVIDIA and AMD) both on desktops and notebooks. Myself, I also had similar problem (resulting in a crash) on a desktop PC.


Kirill Gavrilov's picture

Quality of OpenGL drivers remains perpetual subject in many technical and user forums.

From developer point of view every vendor (AMD, NVIDIA, Intel) has noticeable bugs in their drivers. Automated OpenGL drivers testing within OCCT sound interesting, but unfortunately the fact is that vendors don't care about their bugs, if them comes not from users of the "hot" products (AA/AAA games, world-wide known CAD applications and so on), even if these bugs are obvious.

Kirill Gavrilov's picture

>> In an OCCT application, which performs motion simulation
>> I observed very high memory consumption and slowdown during
>> the simulation was running (with opened local context).
Concerning the start point of the problem - could you please describe actual scenario? Do you:
- Assign new location (transformation) for existing presentation objects.
- Re-compute existing Interactive presentations with new primitives arrays.
- Remove/create Interactive Objects.

First case should not lead to any extra memory issues.
The second one depends on memory manager of OpenGL driver; technically OCCT interface might be improved to update sub-parts of arrays to simplify GPU and CPU memory management (avoid re-creation of memory buffers, reduce possible memory fragmentation).

Pawel's picture

Dear kgv,

our simulation scenario is the following: We have a machine component that moves along a visualized path. The machine component itself has some joints so it contains movable parts that have to be visualized.

Regarding your question the answer to all of them is: YES.

During the simulation:
- there are multiple calls to AIS_InteractiveContext::SetLocation
- AIS_InteractiveContext::Redisplay triggers creation of new primitive arrays (new Graphic3d_ArrayOfTriangles)
- new InteractiveObjects are created as new sections of the tool path get visualized.

However, this simulation scenario is only one problem that I've had recently. Some time ago for instance (I think it was OCCT 6.5.0), I had a crash after importing a (BREP, I guess) model. The crash was gone after updating the graphics driver.

For me it would be interesting to create some general (and preferably automatic) guideline or tool to diagnose/avoid such problems in advance. A reasonable approach to me seems the solution proposed by Sergey: to run a subset of OCCT visualization tests on the target machine to see if anything suspicious occurs.

Best regards