cancel
Showing results for 
Search instead for 
Did you mean: 

Archives Discussions

murphke1
Journeyman III

AMD OpenGL Crash Issue

So I develop an OpenGL rendering and analysis tool for large-scale lidar data (VS2010, Windows, C++).  I've discovered a problem lately where if I load up a large amount of data relative to GPU RAM - say 4-5 Gb worth of VBO data on a machine with 2 Gb of VRAM - then everything renders fine but I get a crash in the AMD driver as soon as I attempt any action which would open a secondary openGL window.  Basically once I pass some threshold amount of VBO data it immediately crashes upon any call to wglCreateContext.  I've tested on a variety of machines, and the common factor is always AMD drivers.  We never get the crash on either Intel or Nvidia configurations.  What's strange is, if I load up say 500 million points worth of data everything works fine on all platforms (actual numbers on any given machine appear loosely correlated to GPU RAM).  Add another 100 million points and rendering is still fine.  I can zoom about through the data with no issues as long as I like - its not having any intrinsic issues managing the LOD structure, the VBOs, my shader programs, etc.  Its handling the hard part beautifully.  But the instant I attempt to create a secondary window to display a histogram or something I get a crash.  A try/catch block around wglCreateContext doesn't accomplish anything.  CodeXL itself crashes at the point of my app crashing, so its not providing a lot of helpful feedback either.  I'm kind of at a loss how to trace this one down.

Note that altering my LOD algorithm to produce smaller numbers of larger VBOs doesn't appear to have any affect on the issue.

I'm pretty much at the point of tracing the entire OpenGL state at the point of calling wglCreateContext to see if there is something funky being set somewhere that the Nvidia/Intel drivers ignore.  But I don't understand if that were the case why it works fine for lesser amounts of data.  And its clearly volume of data and not content - completely different data sets run into trouble at approximately the same amount of VBO data.

Thanks for any ideas,

Kevin Murphy

0 Likes
5 Replies
cgrant78
Adept III

It could be something as simple as virtual memory falling apart. With that said, this sounds like a brute force approach as why would you deliberately throw more than double the amount of data into VRAM when the system has less that that amount. Even if the virtual memory system works correctly, it would constantly be paging data in and out of memory as there is just not enough physical memory to back the allocations. This will significantly impact the performance and scale-ability of your application. The driver crashes and I agree that is an issue, but I would suggest you revisit the approach being used in your application. Throwing everything at the HW without forethought is just asking for trouble.

0 Likes

We are in the process of revamping existing software to handle larger amounts of data Longer term it will be absolutely managing its vbos more gracefully on the fly, swapping portions of the lod tree in and out of vbo memory as needed. But That doesn't help me today.

As I said. The performance is perfectly fine right now. I get acceptable framerates even with that much data loaded. Note that Im not actually rendering all 5 Gb at any one time. Thats just the size of the whole lod tree. The drivers usually do a pretty good job of swapping in the portion I need for a given area and level of detail, with minor hiccups if I suddenly jump to a different Area or zoom in or out in bug jumps.

Its just this weird issue with creating secondary windows. And that appears to be amd only.

Note that im not certain its a driver bug per se. I've seen issues like this before that boiled down to Nvidia allowing me to get away with doing something out of spec. I'm just trying to figure out if there is a short term workaround or tweak I can do to fix the crash until I have time to revamp the render engine.

Thanks,

Kevin

Sent with Good Work (www.good.com)

0 Likes

A further note after more testing. The breakpoint appears to simply be 4 Gb no matter what. If I allocate more than 4 Gb of VBOs I start getting crashing when calling wglCreateContext (and a few other odds & ends cases outside of normal frame-to-frame rendering). Regardless of how much VRAM is on the machine in question. The breakpoint is 4 Gb on machines with 500 Mb, 1 Gb, or 2 Gb (the largest amount for any AMD test box I currently have).

Kevin

0 Likes

..Good find..and do you happen to be running a 32-bit OS ?

0 Likes

Nope. X64 OS (test with win 7, 8, and 10) and x64 app. That 4 Gb number does look awful suspicous though, doesn't it?

Of course, given the way my lod algorithm divvys things into vbos it could be a "number of vbos" thing rather than a pure 4 Gb thing.

Checking out that tack as well.

Thanks,

Kevin

Sent with Good Work (www.good.com)

0 Likes