Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Xavier_Courant
Beginner
135 Views

G45 and G965 OpenGL texture corruption with multiple context/window

Hello,

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.

GLIntelContextTextureCorruption.zip

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.

glview-Intel+Cantiga.XML


Thank you.

 

0 Kudos
9 Replies
guillaumeavril
Beginner
135 Views

We have the same problem with a GMA4500HD with the latest driver from Intel. With this card you need only to open two windows and resize one and the bug appears!
Do you have a solution or any thought?

Thanks for the test program


Quoting - xavfr
Hello,

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.

GLIntelContextTextureCorruption.zip

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.

glview-Intel+Cantiga.XML


Thank you.


 

 

graphicscontext
Beginner
135 Views

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.

Xavier_Courant
Beginner
135 Views

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 ?

graphicscontext
Beginner
135 Views

We talked to Panasonic about this, and they managed to get a corrected video driver from Intel, version 6.14.10.5215, that fixed this and another problem we were having. I also tested version 6.14.10.5225 - worked on our Panasonic CF-19.
wilahti
Beginner
135 Views

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.

135 Views

Sorry for the late response.

But in case somebody comes to this thread regarding the issue,this seems to have been fixed in the latest Intel graphics driver. The corruption issue doesn't show up after numerous context creations in parallel using the above linked test apps.
fredrischter
Beginner
135 Views

Hi everybody,

We're developing an OpenGL enabled aplication that use multiple contexts and having the same problem: texture corruption.

- My application is multi-threaded but the rendering process is synchronized to all context, no concurrency there.

- I'm sharing resources (textures) on the contexts.

- I've tested the application in many machines, PCs and notebooks, hardware accelered and rendering by software, everything ok. I experienced this problem only on some notebooks, that are GM45 (3 notebooks, dell inspiron 1545) and G965 (one notebook compaq 2510p), all suposed to have the most recent drivers.

- As somebody described upthere, the textures start perfect, after some resizing some context corrupts some textures (not all), after resizing again, it get back to be correct. The corruption ocurrs too when creating/finishing new contexts or when the scene is repainted.

So, i see my problem is very similar to the others, i'm looking for any intel answer, if i get some reply i'll post here, feel free for asking about my case.

Thanks for the people that studied this bug.

Best Regards,
Fred





fredrischter
Beginner
135 Views

Ganesh,

In my application, that i posted about above, this bug happens. But in the test application that is developed by our friend upthere here in my GM45 works perfectly, it share perfectly to 32 contexts.

If the bug doesnt show on this test aplication doesnt mean that the bug is solved, i noticed in my application with not much textures/vertexes the problem happens more rarely, but with more textures and more vertexes, primitives, the problem happens fastly.

I'll continue looking for any new drivers to test here,

thanks,
Fred
fredrischter
Beginner
135 Views

Hi Everybody

I have sucess fixing the problem looking for new driver.

Was using driver version 6.14.10.4990, this is the version distributed and recommended by DELL, and having the texture problem.

I got a new version of the driver, 6.12.10.5218 that fixes the problem, in the release notes are our issue, under number 2855464, in the isues resolved section, with the following text:

2855464

Resizing shared texture issue or black texture might be seen after texture modification.

OpenGL*

Intel 4 Series Chipset Family


Thanks,
Fred
Reply