the Fiddler's picture

Multithreading test crashes on Windows 7 x64 / Nvidia 260.99

Project:The Open Toolkit library
Version:1.0-2010-10-06
Component:Code
Category:bug report
Priority:normal
Assigned:Unassigned
Status:won't fix
Description

The crash occurs as soon as the second thread calls MakeCurrent. Extensive testing indicates that this might be a driver bug - need to test on different hardware.

Windows 7 x64 Professional. Nvidia 9500GT with 260.99 drivers.


Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
the Fiddler's picture

#1

Version:0.9.x-dev» 1.0-2010-10-06

Can someone please run the Example browser and check whether TK -> Multithreading works for him? Don't forget to post your OS and drivers, too!

swiftcoder's picture

#2

'Multithreading Test' or 'Threaded Rendering'? Both run fine here, although the Multithreading Test is extremely choppy when the two windows are overlapped.

Windows 7 x64, Radeon 5770, Catalyst 10.10

the Fiddler's picture

#3

Thanks, "Multithreading Test" is the one. I tested on an Intel 945 (notorious for its awful drivers) and it also works fine there. I thought Nvidia was supposed to have stable OpenGL drivers...

swiftcoder's picture

#4

Quote:

I thought Nvidia was supposed to have stable OpenGL drivers...

That was certainly true a few years ago (or at least they were more stable than ATI's terrible drivers), but I haven't found it to be the case for the past couple of years...

Inertia's picture

#5

works fine, latest trunk on Windows 7 x86 / Catalyst 10.10(c?)

I can confirm that AMD's Catalyst is way better than it's reputation, it earned that rep a decade ago and it somehow stuck till now.

nythrix's picture

#6

Yay! If you launch a random example (not multithreading) first and then multithreading second, everything works. Does that help?

Win7 x64, nv260.99

the Fiddler's picture

#7

Hm, why would that be? OpenTK actually creates and destroys a least to contexts at startup (one for WGL entry points and one for GraphicsMode detection) so why does this affect behavior at all? (Just talking to myself).

I guess the sane thing to do would be to write a native test case and see if that crashes, too.

c2woody's picture

#8

Crash happens for Win7/64bit and a Geforce GTX285 as well, both the multithreading example in OpenTK and for another multithreaded OpenTK application.

the Fiddler's picture

#9

This is indeed a driver issue: http://forums.nvidia.com/index.php?showtopic=187788

Apparently, Nvidia 260.xx drivers crash if you try to use OpenGL from multiple threads that were created before calling LoadLibrary.

c2woody's picture

#10

Hm if this really goes away with the non-auto settings of the multithreading optimizations, this is very likely a driver bug. Hopefully there'll be an official statement from the nVidia side.

But I'm not yet sure about the preconditions for this to happen, since I've experienced bugginess with the 260+ drivers when a thread (that was created *after* the initialization has happened) took over the OpenGL context. Can't tell the exact location of the crash because I don't have any such machine at hand at the moment.

The Fiddler, were you able to isolate the problem (OpenTK/standard OpenGL application)? Like by moving thread creation you were able to work around the bug?