260.xx & OpenGL & LoadLibrary & Multithreading
Sorry for the cross post. I realized this would be the correct forum for my topic:

In my application I open the OpenGL DLL using LoadLibrary. I found out that with current drivers (260.x) OpenGL cannot be used in any thread that has been created before the OpenGL DLL was loaded (crash in wglMakeCurrent). With earlier drivers (or with ATI drivers) this works fine. Will this be fixed or must I create all my threads after I loaded OpenGL?
Some kind of documentation in the release notes on this change of behavior would be nice.
Sorry for the cross post. I realized this would be the correct forum for my topic:



In my application I open the OpenGL DLL using LoadLibrary. I found out that with current drivers (260.x) OpenGL cannot be used in any thread that has been created before the OpenGL DLL was loaded (crash in wglMakeCurrent). With earlier drivers (or with ATI drivers) this works fine. Will this be fixed or must I create all my threads after I loaded OpenGL?

Some kind of documentation in the release notes on this change of behavior would be nice.

#1
Posted 12/10/2010 08:59 AM   
this has been an issue since nvidia optimised the driver threading.

the program shouldn't crash if you set the driver to Threaded optimisations On, rather than auto. but you can work around it by handling your threads after the dll is loaded.
this has been an issue since nvidia optimised the driver threading.



the program shouldn't crash if you set the driver to Threaded optimisations On, rather than auto. but you can work around it by handling your threads after the dll is loaded.



In Memory of Chris "ChrisRay" Arthington, 1982-2010

CPU:Intel i7 920 @ 3.8(D0), Mainboard:Asus Rampage II Gene, Memory:12GB Corsair Vengeance 1600
Video:EVGA Geforce GTX 680+ 4GB, Sound:Creative XFI Titanium Fatal1ty Pro, Monitor:BenQ G2400WD
HDD:500GB Spinpoint F3, 1TB WD Black, 2TB WD Red, 1TB WD Black
Case:NZXT Guardian 921RB, PSU:Corsair 620HX, OS:Windows 7 SP1

#2
Posted 12/11/2010 11:53 PM   
this should be fixed in Release 265 drivers.
this should be fixed in Release 265 drivers.



In Memory of Chris "ChrisRay" Arthington, 1982-2010

CPU:Intel i7 920 @ 3.8(D0), Mainboard:Asus Rampage II Gene, Memory:12GB Corsair Vengeance 1600
Video:EVGA Geforce GTX 680+ 4GB, Sound:Creative XFI Titanium Fatal1ty Pro, Monitor:BenQ G2400WD
HDD:500GB Spinpoint F3, 1TB WD Black, 2TB WD Red, 1TB WD Black
Case:NZXT Guardian 921RB, PSU:Corsair 620HX, OS:Windows 7 SP1

#3
Posted 01/04/2011 09:27 PM   
Thank you, stefanw, for reporting this and to Sora, for the work-around.

The problem seems to be related to the "Threaded optimization" setting being in the Auto mode. If it is changed to On or Off, then our OpenGL programs work correctly.

We make a framework and Level Editor and related tools for many Sony PS3 and PSP 1st party game developers, so this crash bug has been very expensive. Our tools group is spreading the word to not upgrade to 260.99 or to use this work-around.

Our code is structured to create separate threads after OpenGL is first initialized, so our application is structured differently than stefanw's.

Here's one view of the crash:
(948.1f08): Access violation - code c0000005 (first chance)
nvoglv32!DllMain+0x5efe:
098936ee ff979c000000 call dword ptr [edi+9Ch] ds:002b:0000009c=????????
nvogl32!dllmain+0x5efe
nvogl32!dllmain+0x640d


Here's the crash as viewed within Visual Studio 2010:
> nvoglv32.dll!0bb236ee()
[Frames below may be incorrect and/or missing, no symbols loaded for nvoglv32.dll]
nvoglv32.dll!0bb23bfd()
nvoglv32.dll!0ba9d67a()
nvoglv32.dll!0ba9e7ed()
nvoglv32.dll!0bb18989()
kernel32.dll!75ad3677()
ntdll.dll!77859d42()
ntdll.dll!77859d15()

Registers:
EAX = 00000000 EBX = 0766C2A0 ECX = 0766C2A0 EDX = 0766C2A0 ESI = 076C9098 EDI = 00000000 EIP = 0BB236EE ESP = 0F33F8F0 EBP = 0F33F900

EFL = 00010202

0000009C = ????????

Disassembly:
0BB236BF int 3
0BB236C0 push ebp
0BB236C1 mov ebp,esp
0BB236C3 push ecx
0BB236C4 mov eax,dword ptr ds:[0C220DA8h]
0BB236C9 test eax,eax
0BB236CB push esi
0BB236CC push edi
0BB236CD je 0BB236D4
0BB236CF mov esi,dword ptr fs:[eax]
0BB236D2 jmp 0BB236E5
0BB236D4 mov eax,dword ptr ds:[0C1F823Ch]
0BB236D9 push eax
0BB236DA call dword ptr ds:[0C1F8030h]
0BB236E0 add esp,4
0BB236E3 mov esi,eax
0BB236E5 mov eax,dword ptr fs:[00000BF0h]
0BB236EB mov edi,eax
0BB236ED push edi
0BB236EE call dword ptr [edi+9Ch]
Thank you, stefanw, for reporting this and to Sora, for the work-around.



The problem seems to be related to the "Threaded optimization" setting being in the Auto mode. If it is changed to On or Off, then our OpenGL programs work correctly.



We make a framework and Level Editor and related tools for many Sony PS3 and PSP 1st party game developers, so this crash bug has been very expensive. Our tools group is spreading the word to not upgrade to 260.99 or to use this work-around.



Our code is structured to create separate threads after OpenGL is first initialized, so our application is structured differently than stefanw's.



Here's one view of the crash:

(948.1f08): Access violation - code c0000005 (first chance)

nvoglv32!DllMain+0x5efe:

098936ee ff979c000000 call dword ptr [edi+9Ch] ds:002b:0000009c=????????

nvogl32!dllmain+0x5efe

nvogl32!dllmain+0x640d





Here's the crash as viewed within Visual Studio 2010:

> nvoglv32.dll!0bb236ee()

[Frames below may be incorrect and/or missing, no symbols loaded for nvoglv32.dll]

nvoglv32.dll!0bb23bfd()

nvoglv32.dll!0ba9d67a()

nvoglv32.dll!0ba9e7ed()

nvoglv32.dll!0bb18989()

kernel32.dll!75ad3677()

ntdll.dll!77859d42()

ntdll.dll!77859d15()



Registers:

EAX = 00000000 EBX = 0766C2A0 ECX = 0766C2A0 EDX = 0766C2A0 ESI = 076C9098 EDI = 00000000 EIP = 0BB236EE ESP = 0F33F8F0 EBP = 0F33F900



EFL = 00010202



0000009C = ????????



Disassembly:

0BB236BF int 3

0BB236C0 push ebp

0BB236C1 mov ebp,esp

0BB236C3 push ecx

0BB236C4 mov eax,dword ptr ds:[0C220DA8h]

0BB236C9 test eax,eax

0BB236CB push esi

0BB236CC push edi

0BB236CD je 0BB236D4

0BB236CF mov esi,dword ptr fs:[eax]

0BB236D2 jmp 0BB236E5

0BB236D4 mov eax,dword ptr ds:[0C1F823Ch]

0BB236D9 push eax

0BB236DA call dword ptr ds:[0C1F8030h]

0BB236E0 add esp,4

0BB236E3 mov esi,eax

0BB236E5 mov eax,dword ptr fs:[00000BF0h]

0BB236EB mov edi,eax

0BB236ED push edi

0BB236EE call dword ptr [edi+9Ch]

#4
Posted 01/06/2011 07:36 PM   
it would appear this is resolved in Release 265/266 drivers, as virtualbox and opengl extension viewer tests run fine without the change to the profile.

however i would not advise upgrading to these beta drivers in production environments at this time, as there are issues that remain unresolved which can cause instabilities.
it would appear this is resolved in Release 265/266 drivers, as virtualbox and opengl extension viewer tests run fine without the change to the profile.



however i would not advise upgrading to these beta drivers in production environments at this time, as there are issues that remain unresolved which can cause instabilities.



In Memory of Chris "ChrisRay" Arthington, 1982-2010

CPU:Intel i7 920 @ 3.8(D0), Mainboard:Asus Rampage II Gene, Memory:12GB Corsair Vengeance 1600
Video:EVGA Geforce GTX 680+ 4GB, Sound:Creative XFI Titanium Fatal1ty Pro, Monitor:BenQ G2400WD
HDD:500GB Spinpoint F3, 1TB WD Black, 2TB WD Red, 1TB WD Black
Case:NZXT Guardian 921RB, PSU:Corsair 620HX, OS:Windows 7 SP1

#5
Posted 01/10/2011 11:16 PM   
Scroll To Top