We are experiencing problems on Intel GM45 and G965 (not G945 or other card vendors) with our application which shares context ( for textures and others ressources ) over multiple window.
This problem occurs in single threaded application with the lastest Intel drivers available, and with different kind of hardware notebook platform (ie: Lenovo thikpad R500 (GM45), Panasonic CF-19 Mk-III (GM45) , Panasonic CF-19 Mk-II (G965) )
So we decided to create a sample application to report this problem by modifying a common NeheGL example basecode and adding multiple render window which shares some textures.
I join these files to this report which includes sources and exe, I also join a GLView report for my notebook.
To observe the problem you'll have to launch NeheGL.exe and then create multiple window by pressing 'F1' key, the new window has always good textures but the old ones may have corrupted textures. For GM45 this problem can occurs after the second window creation and for a G965 it occurs in less than 10 windows.
(note: if you resize a window with corrupted textures, this window recovers good looking textures but other windows get wrong)
This example has been compiled using Mingw, a basic makefile is provided but must be adapted to your configuration.
We have aso experienced this problem with Intel graphics cards on both Dell machines and the CF-19. Thank you very much for writing the code to demonstrate/isolate the problem. I was in the process of doing exactly the same thing when I came across your post.
Excuse me for this late answer, I posted the first message a long time ago whithout any reply, even from Intel (Is there still a support on these chipset ?).
A fallback solution:
When I detect an Intel chipset, I bypass this issue by reusing the same GL context for all the windows, so I just create and use only 1 context , and so I don't have to share textures.
In fact, you can use only one GL context over multiple windows by attaching your context to a different window with wglMakeCurrent, but beware to reset all GL states to match your current window after calling wglMakeCurrent(), as you always use the same context for all windows...
Hope it will help people...
PS: I saw that Intel published a new driver for GM45, but I can't test and install them because Lenovo didn't include this one in their driver support for my Lenovo ThinkPad test machine...Did anyone tried ?
I believe I am also experiencing this issue on Ubuntu Karmic Koala. My application initiates a GLX context, then provides that context to the GLUpload plugin provided with the GStreamer OpenGL plugins package.
GLUpload uses GLX context sharing to share textures with my application's context. It passes textures back to the application which I then render. On Intel systems the result is corrupted rendering. The textures seem to render almost anything in VRAM including textures from other applications or the composite manager. And no, using a non-Composite windowing manager does not affect the behavior of the application.
I stripped my application into a self-contained test case. When I ran the test case on an Ubuntu system with an NVIDIA graphics adapter, the corruption disappears and video frames are visible (though the playing process is buggy so video plays too fast and such).
I know NVIDIA provides their own GLX while Intel uses the common Mesa/DRI stack, so I would venture a guess that this is a Mesa problem?
Here's the testcase: GLVideoTest.tar.bz2
EDIT: I should also mention that disabling direct rendering causes the test case to crash.
Resizing shared texture issue or black texture might be seen after texture modification.
Intel 4 Series Chipset Family