[entrox]

I recently swapped my trusty old GeForce Ti4600 for a Radeon 9800 in my MDD PowerMac in hopes of getting better support for modern 3D capabilities (yay for fragment programs!). Although I was burned in the past by shitty ATI drivers, I thought their Mac division would produce something which doesn't crash and burn all the time. I should've known better...

It works fine for day to day work and playing games, but as soon as I try to do advanced things like resizing an OpenGL window, I get a 100% kernel panic. Attaching the OpenGL profiler from Apple to my applications is also a risky operation. The usual response to things like clicking on some buttons is either a black screen or an instant panic (it panicked 10 minutes ago after opening the preferences menu).

I never ever had a single panic with the GeForce, so I don't blame memory or similar things. Interestingly, I can play games like WoW for hours without crashing either fullscreen or windowed, but as soon as I try to resize an OpenGL view I get greeted by a KP.

Does anybody have an idea? Naturally, I've installed the newest firmware and drivers.

[arekkusu]

Originally posted by entrox:
as soon as I try to do advanced things like resizing an OpenGL window, I get a 100% kernel panic.

What application(s) are you talking about here?

KP'ing while resizing is indicative of incorrectly written multithreaded GL apps. That's a bug in the application that the developer should fix. (Although, I agree it totally sucks that a user-space app can take down the whole OS like this.)

[entrox]

Originally posted by arekkusu:
What application(s) are you talking about here?

It happens with my own applications, but I also noticed it happening in PCSX. Something like this was mentioned in the change logs now that I think of it.

KP'ing while resizing is indicative of incorrectly written multithreaded GL apps. That's a bug in the application that the developer should fix. (Although, I agree it totally sucks that a user-space app can take down the whole OS like this.)

I also had a similar hunch. I'm drawing from a separately spawned thread and it's possible that the amount of locking is not adequate. Since I'm on a SMP system, I've disabled the second CPU using the CHUD tools and the panic when resizing disappears, so it most certainly is a synchronizing bug. I'll try the profiler later (it sucks having to reboot 5 times a day...).

But, why didn't this happen on my GeForce? And why does it PANIC? Can I file a bug without having a paid ADC membership?

[Angus_D]

I'd imagine that not synchronising stuff is causing the ATI drivers to fubar, whereas the nVIDIA ones managed to cope for whatever reason. This isn't really unusual, threading problems tend to manifest themselves in configuration-dependent circumstances (making them a bitch to trace).

You can file bugs with ADC with a free Online account, see here.

[wadesworld]

The best thing to do is to work wth ATI directly.

Their Mac developer support is outstanding.

Wade

[arekkusu]

Originally posted by entrox:
I also noticed it happening in PCSX.

Funny you should mention PCSX; I submitted fixes for the threading KP and various other problems in the rendering window to Gil a week ago. Wait for the next release.

I'm drawing from a separately spawned thread and it's possible that the amount of locking is not adequate.

That's definitely the problem here. You must lock around every method that submits GL commands. I.e. in a NSOpenGLView subclass, init, dealloc, reshape, drawRect, update, fullscreen, willMinimize, etc. It can be tricky to find all of the methods since some of them are triggered internally-- update was the one Gil had missed.

But, why didn't this happen on my GeForce? And why does it PANIC?

Different hardware, different driver. Rule #1 of OpenGL programming: test your app on all the hardware. There are many hardware- and driver-specific differences, causing minor or major rendering differences. nVidia happens to handle this issue better than ATI, but it is still a programming error-- GL contexts must be treated as shared resources when multithreading.

Can I file a bug without having a paid ADC membership?

Yes, get a free account. Please do log a bug about the KP-- it is really bad that it is so easy to bring the system down. Also, you might log a feature request asking for sample code specifically showing how to implement completely safe multithreaded GL, since there is no such sample now.

[entrox]

Thank you all. I fixed the problem in my app.

Originally posted by arekkusu:
That's definitely the problem here. You must lock around every method that submits GL commands. I.e. in a NSOpenGLView subclass, init, dealloc, reshape, drawRect, update, fullscreen, willMinimize, etc. It can be tricky to find all of the methods since some of them are triggered internally-- update was the one Gil had missed.

I am aware that Cocoa & OpenGL aren't thread-safe, but I assumed that I could avoid extensive locking by making sure that there is only a single thread issuing GL commands. It works as long as you don't muck around with the profiler or resize the window.

Oh well, a single lock a frame won't kill me.

Please do log a bug about the KP-- it is really bad that it is so easy to bring the system down. Also, you might log a feature request asking for sample code specifically showing how to implement completely safe multithreaded GL, since there is no such sample now.

Will do. Debugging such a problem gets quite interesting if you need to reboot every time you trigger it...

[arekkusu]

Originally posted by entrox:
I assumed that I could avoid extensive locking by making sure that there is only a single thread issuing GL commands. It works as long as you don't muck around with the profiler or resize the window.

Your assumption is correct-- as long as only one thread draws, you're safe. But when you resize (or drag, or hide, or minimize, or change screen resolutions etc) the main thread triggers an update/reshape/draw in response to the user action. So you need to lock around all of those things to make sure that only one thread is drawing.

[Devin Lane]

Two things:

1. Turrning on glTexParameteri(GL_TEXTURE_RECTANGLE_EXT, GL_TEXTURE_STORAGE_HINT_APPLE , GL_STORAGE_CACHED_APPLE) == kp's galore.
2. You don't need a lock: I have my gl app (iSight video -> GL) threaded, and I don't use locks. All you have to do is call [[self openGLContext] makeCurrentContext] at the beginning of each function that uses GL comands.

[arekkusu]

Devin:

1) I've not experienced any KP using GL_TEXTURE_STORAGE_HINT_APPLE, and I've used all three settings in several apps. Have you submitted a bug with sample code showing the panic?

2) You need to lock.

[Devin Lane]

No, I have not submitted the bug as of yet. Should I?

I believe that we are talking about different threading situations with the drawing thing. I have not found any need to lock.

[arekkusu]

If you can reliably panic the OS, you should submit a bug. The OS should never panic!

The rule for locking is: only one thread can make a context active and submit commands at a time. So there are cases where you don't need to lock. For example, if you make a context on a second thread, and that context is used for an offscreen buffer that is never shown in a window the user can interact with, you're fine without locking since there is no way the main thread will ever use that context. But if your second thread renders into a window, all the user has to do is resize the window to panic. See the above posts.

[Devin Lane]

arekkusu

Ok, I will try to submit the bug report soon. I haven't done it before: what information do they need? There was no panic log.

Here's how I have my threading set up. At the beginning, the app launches a new thread to the video capture method. that methods creates a timer, and runs the new run loop that was created by the thread. This allows the video to play while the mouse is down, resizing a window, etc. Each time the timer fires, in the separate thread, a method is called on the gl view that updates a texture and calls [self setNeedsDisplay:YES];.

I do not use locking at all, and the program does not panic at all. Is my main thread just never drawing the gl view? Am I getting lucky? I don't know all that much about threads and locking, I just tried this and it worked .

Thanks,

[arekkusu]

Originally posted by Devin Lane:
what information do they need? There was no panic log.

There are formatting guidelines linked from the new bug page. Your system profile and steps to reproduce the panic are a start. If you can give them your app source, or reduce the problem to simple sample code, even better.

that methods creates a timer, and runs the new run loop that was created by the thread. This allows the video to play while the mouse is down, resizing a window, etc.

An NSTimer in the main thread can fire during mouse down/resizing-- just add it to both NSDefaultRunLoopMode and NSEventTrackingRunLoopMode modes. Of course, if you are doing a lot of heavy video processing (QuickTime etc) that work is best done in a second thread.

I do not use locking at all, and the program does not panic at all. Is my main thread just never drawing the gl view? Am I getting lucky?

Have you tested your app on a wide range of hardware, and resized the window while the video is animating?

You can check which thread is doing the drawing with [NSThread currentThread].