Jump to content

  • Log In with Google      Sign In   
  • Create Account

Diagnosing GL crash ?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
2 replies to this topic

#1 3TATUK2   Members   -  Reputation: 730

Like
0Likes
Like

Posted 12 January 2014 - 03:53 AM

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, 12 January 2014 - 03:55 AM.


Sponsor:

#2 3TATUK2   Members   -  Reputation: 730

Like
0Likes
Like

Posted 12 January 2014 - 11:52 AM

One specific instance is the intel "Q45/Q43" chipset



#3 richardurich   Members   -  Reputation: 1187

Like
0Likes
Like

Posted 12 January 2014 - 02:36 PM

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.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS