I have a repeatable crash in the latest driver for the Intel 945GM. Here’s the outline of what I’m doing:
Create window and GL context 1
Create window and GL context 2
Share textures between the two contexts (wglShareLists)
Make context 2 current
Create and upload a texture object
Render a triangle
Destroy window/context 2
Make context 1 current
Delete the texture object (glDeleteTextures)
That should work, right?
Is there any developer channel for reporting bugs to Intel?
there are plenty of threads here about Intel graphics and that they are amazingly unstable. couple of threads are by me actually. maybe a search on the forums will help you out. one thing that would bother me right away is that you already updated to latest drivers.
I have not playing myself with several RC in the same program so I don’t know if what you are doing is the correct a safe way but reading you it looks like a driver bug and it is not surprising from intel one.
the only thing you could probably do if you care about your app running on Intel is to use GLIntercept log to see where it crashes. this will give you some hints where to start digging. also GLIntercept can warn you about various GL errors which might be ignored on one driver and crash on other.
“Share textures between the two contexts” might be the problem with context. i never used wglShareLists but multiple context need alot of care to make them work properly. most of the time a driver bug indicates a bug in your code though and if nothing else gets released you have to rethink it. maybe you should delete the textures under context 2 where you created them or delete them in an alternate way one by one or with one call (array).
btw, i had to change line stipple pattern once to avoid a BSOD, funny like that.
In this simplified example, there is no particular point. In general, I do use textures in multiple contexts, and as far as I know you can’t share just some textures among contexts.
I just re-read the docs on wglShareLists, and I don’t see anything to support what you’re saying. It just makes the contexts share display list and texture space. Sounds pretty symmetrical to me. The statement
When the last rendering context of a shared display-list space is deleted, the shared display-list space is deleted.
seems to support my belief that there’s nothing special about the first context.
I’ll grant that it’s not unheard-of for an implementation to deviate from its documentation.
I’m not saying that. The docs do say that when you call wglShareLists( RC1, RC2 ), RC2 should not contain any existing display lists, so of course I do it just after creating RC2. But after sharing has been put into effect, I don’t know why there should be any asymmetry.