Jump to content
  • Advertisement
Sign in to follow this  

Diagnosing GL crash ?

This topic is 2110 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

What's the best way to diagnose a GL crash?


I mean a specific "kind" - which typically happens at a render call such as glDrawArrays/glDrawElements... And only on "specific" hardware. Not all systems. Same code usually works just fine on modern nvidia/ati cards, but usually older intel laptops that support 2.1 have this problem - even though this is (as far as i know) 2.1-compliant code... And yet again, SOME older intel laptops also DO work, aswell as most modern ones.


I know the "usual" candidates: ...


Assure there are no GLerrors - there are none.


Use a GL debug context - usually the systems that crash like this actually also usually crash on simple context creation when specifying debug context.


Sometimes I hear "GLDebugger" - But, 1) I've never used that, and 2) am assuming you'd have to know specifically what to look for as i think it just provides general state information and probably wouldn't have anything specific/highlighted to a crash within the GL render function call ?


There have been things in the past that have also caused this that I've actually sorted out... For example, if you have a GL client state enabled and you don't send that attribute - it will crash on some (even modern, usually nvidia) cards. Even though ati card probably won't crash.


So it seems like it might be something similar to that. So for example - other than "knowing" that you should not -have a GL client state enabled when not sending that attribute- ... How would someone be able to successfully diagnose this issue?

Edited by 3TATUK2

Share this post

Link to post
Share on other sites

glFinish is your friend. It will block until all previous calls are completed. This will let you pinpoint exactly which call is the problem, as it might not be the one you think it is. But debugging random Intel issues is a real pain, and I really wish there was a magic solution to making it suck less. If you haven't learned to navigate Intel support for developers, I guess that is one thing that makes it more manageable.


The only other thing I can recommend is avoiding as many features as possible for your lowest graphics settings. It makes the amount you have to debug more manageable.


It's also worth mentioning that a lot of small developers, and even some large ones, just don't support Intel chipsets due to the issues. Even Minecraft failed to run on Q45 a few years back (no clue if they fixed it). Intel has made remarkable progress though, so their newer chipsets are miles better and might be worth trying to support since Intel chipsets are a huge portion of the market.

Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!