PDA

View Full Version : extensive pbuffer use == system hangs (ATI)



valoh
10-17-2004, 03:06 PM
Hi,

I have the problem that with extensive pbuffer and render_to_texture use my system hangs and I need to do a hw-reset (sometimes the VPU recovery can recovery the system).
I check for OpenGL Error and lost pbuffer but no problems there and the pbuffers all get created without problems.
Basically my pbuffer wrapper seem to be ok and simple examples work without problems. But with using several pbuffers (RGBA8 1024x1024 + two RGBA32 float 1024x1024) I get the system hangs always when rendering to the later pbuffers.
I use wglShareLists for all pbuffers and use glsl shader for rendering. wglShareList and wglMakeCurrent return without errors.

Till now it seem that the crash only happen with rendering to the later created pbuffers (2nd float pbuffer).
And depending on the pixel format of that 2nd pbuffer my system crashes with first few frames rendered to it, or only after I switch to taskmanager or other applications.

My first guess was that perhaps there was not enough graphic memory for the pbuffer or the buffer get lost during the application switch. But the pbuffer is created without errors and I check for lost pbuffer. And according ARB spec rendering to a lost pbuffer nevertheless should work without crashing.

I guess it's a strange driver bug but I'm not sure what exactly causes the crash... Has anyone else also such system crashes with using several pbuffers?
Any ideas what can cause this crashes or how to find it out?

using: Radeon 9800 + catalyst 4.10

zeckensack
10-17-2004, 04:09 PM
Is your application single-threaded or multi-threaded?

valoh
10-17-2004, 04:30 PM
single-threaded

MattS
10-18-2004, 12:07 AM
I have had similar problems to this (on a 9800 too). The only way I could get around it was to call glFinish at the end of every frame.

valoh
10-18-2004, 12:50 AM
mhh, I already had a glFinish after my SwapBuffers. Putting it before doesn't change anything. As I render lots of things before SwapBuffer I also tried to put a glFinish in the render loop where the crash happens, but it still crashes.

valoh
10-18-2004, 06:50 AM
Ok, after some testing and countless reboots it seem to be a problem related to pbuffer/glsl.

One combination of pbuffer and a specific glsl shader crashes my system, if I use the same shader in other pbuffers or other shaders in the same pbuffer it works without problems :confused:
It seem somehow be related to vertex shader attributes, because if I modify the crashing shader and add another vertex attribute the shader don't crash anymore. Or I can disable all the vertex arrays with glDisableVertexAttribArrayARB and it doesn't crash.

So what can this mean? I'm totally out of ideas how to find and fix this bug. The strange thing is that till now this only happened with this special combination of specific pbuffer with specific glsl shader.

Are there any known problems with pbuffer/glsl on ati hw?
Any ideas what can cause this crashes?

GKW
10-18-2004, 10:29 AM
Originally posted by zeckensack:
Is your application single-threaded or multi-threaded?Are there any known bugs with respect to ATI/pbuffers/multithreading?

ZbuffeR
10-18-2004, 10:46 AM
valoh, can you give the details on what specific pbuffers parameters and glsl program are causing these crashes ?

zeckensack
10-18-2004, 11:22 AM
Originally posted by GKW:

Originally posted by zeckensack:
Is your application single-threaded or multi-threaded?Are there any known bugs with respect to ATI/pbuffers/multithreading?None that I'm aware of. But there are a few gotchas with Windows GDI and user functions in multi-threaded applications. Worst case is an application hang.

GKW
10-18-2004, 12:31 PM
Originally posted by zeckensack:
None that I'm aware of. But there are a few gotchas with Windows GDI and user functions in multi-threaded applications. Worst case is an application hang.[/QB]Can you elaborate on these gotchas? I have a very simple pbuffer app that works just fine using nvidia but fails with ATI. wglCreatePbufferARB returns false with an error of 0 on ATI cards. All the function inputs are valid and the context is current only on the calling thread.

gator
10-18-2004, 12:52 PM
Do you actually check what you get back after you create the pbuffer? Maybe you might get
back something that you didn't request if it wasn't possible. You can use wglQueryPbufferARB()
to get info about the pbuffer you just created.

gator
10-18-2004, 12:54 PM
Probably should also use WGL_PBUFFER_LOST_ARB to determine if your surface was lost during rendering too. Anything could happen to it after it gets created.

zeckensack
10-18-2004, 02:49 PM
Originally posted by GKW:
Can you elaborate on these gotchas? "The system creates a thread\'s message queue when the thread makes its first call to one of the USER or GDI functions." (http://msdn.microsoft.com/library/en-us/dllproc/base/attachthreadinput.asp)
Sometimes you don't want that. The system may place messages in that queue for your thread to pick up. Problems can arise if you don't regularly run a "message pump", in that thread, i.e. the well known GetMessage/PeekMessage plus DispatchMessage stuff, because messages in the queue will not be processed.
At a minimum, you'll have an extra "not responding" application listed in the task manager, for every thread that has called a GDI/user function and does not have the "pump". But that's harmless most of the time.

Worst case:
a)You start two threads.
b)You create a window in thread A, but don't run a pump. The window will work fine. Resizing/moving/destroying/whatever will actually work without the pump.
c)You SendMessage(anything) to that window from thread B
The process will at that point hang because SendMessage is specified to not return before the message has been processed. But it will never be. The window procedure will not catch the message automatically. The system will only deliver it to a GetMessage or PeekMessage call.

And there are a lot of things you can only do with a window from the thread that created the window, setting active window status, keyboard/mouse focus, destroying the window etc. AttachThreadInput can relax some of these restrictions, but not all.

I actually tried to replace a remote DestroyWindow (which isn't allowed) with WM_DESTROY and WM_NCDESTROY messages a few days ago, and ended up with a hung application instead of a memory leak. That's why it was still on my mind.

GKW
10-19-2004, 11:01 AM
Leaving the message pump running seems to have fixed my problem. I guess ATI does things a little differently than Nvidia. Thanks.

valoh
10-19-2004, 03:50 PM
@zeckensack:

As I said single-threaded I meant that I use my OpenGL stuff within one thread. No different pbuffers or render contexts across several threads. But I use the Windows.Forms which I guess internally are multithreaded, I also link to multithreaded runtime libs.

The hangs/crashes are somehow non determininistic I've done lots of testing and can't find the exact reason...

I don't understand your gotcha explanation and how this relates to pbuffers. The problem first arises with the extensive use of pbuffers and there also only in some cases.
Could you perhaps elaborate a little bit more ;) I don't know much of this win32 stuff, with Windows.Forms you only have to create some event-handlers. The main questions I have are: how does this relate to pbuffers, how can I fix it? What does it mean (in source code) "Leaving the message pump running"?

1024
10-19-2004, 09:56 PM
Originally posted by valoh:
... using: Radeon 9800 + catalyst 4.1Why not start with downloading new drivers ... 4.9 are out.

valoh
10-20-2004, 01:37 AM
Originally posted by 1024:
Why not start with downloading new drivers ... 4.9 are out.[/QB]there are already the 4.10 out, which I'm using if you would reread my post ;)

1024
10-20-2004, 01:05 PM
Dooh! Weird - somehow i got the impression that the new drivers i downloaded were 4.9, but it appears to be 4.10. LOL. (did 4.1 actualy have glsl support?)

valoh
10-20-2004, 01:43 PM
Originally posted by 1024:
Dooh! Weird - somehow i got the impression that the new drivers i downloaded were 4.9, but it appears to be 4.10. LOL. (did 4.1 actualy have glsl support?):D

afaik there was already beta glsl support in catalyst 3.8 or 3.9, but it was really really beta/experimental *shudder*.

can anyone help me with the pbuffer crashes?

I didn't exactly understand the explanation with threading and message pump and relation to pbuffers. But with some further testing I have now identified following driver crash behaviour:

it crashes only during a special pbuffer rendering during application start if I switch application. If I don't switch it runs without crashing. As this is a somewhat longer preprocessing rendering it is really annoying not being able to switch to other apps now.
The strange thing is not every pbuffer rendering crashes the driver. For the preprocessing I use several pbuffers and only with one it crashes with application switches.
So its really a weird behaviour. And I'm really sure it is not a problem with my pbuffers or shaders as with other cases they work fine, I test for all error states and lost pbuffers, shader validation and so on, plus it only crashes with this application switches...

Could it be related to that thread message thingy? How could I fix it?

GKW
10-21-2004, 07:14 AM
I am doing some offscreen rendering so I created a thread with a hidden window. I then set up a DC and a RC and grabbed the extension string for the driver. After that I figured that there would not be any user input so I freed the context I created and then explicitly paused that thread. I should have just let GetMessage run and since there is no user input it would in effect pause that thread. I discovered yesterday that it didn't totally fix my problems but it is better.

valoh
10-21-2004, 09:33 AM
Originally posted by GKW:
I am doing some offscreen rendering so I created a thread with a hidden window. I then set up a DC and a RC and grabbed the extension string for the driver. After that I figured that there would not be any user input so I freed the context I created and then explicitly paused that thread. I should have just let GetMessage run and since there is no user input it would in effect pause that thread. I discovered yesterday that it didn't totally fix my problems but it is better.mhhh, I still don't understand how that relates to the pbuffers. Does the driver use the message pump for GPU managment? But as I don't create any threads or pause them I guess there has to be another problem.

I'm really pissed off :mad: , don't have the slightest idea whats going wrong other than some strange don't-use-pbuffers-too-much-on-ATI-bug... Perhaps the pbuffer gets lost during rendering to it? I have no idea and I test all return values and error codes I know (general ogl errors, pbuffer lost, shader validation)...
What does make such a huge difference that with lots of pbuffer rendering the driver crashes with a task switch, don't crash without task switch and doesn't crash at all with only some pbuffer renderings :confused:

GKW
10-21-2004, 10:16 AM
Sorry I forgot to say I use the DC/RC I created to make some pbuffers.

Aeluned
10-21-2004, 10:42 AM
If there's a resolution mismatch between your pbuffer and your onscreen rendering context it maybe the cause of crashes...

I really have no idea what you're trying to do but are you certain you're not trying to access some bogus memory locations?

are you getting access violations? stalls? what's happening?

sorry i skimmed the post...hope i didn't miss anything crucial.

valoh
10-21-2004, 11:32 AM
Originally posted by Aeluned:
If there's a resolution mismatch between your pbuffer and your onscreen rendering context it maybe the cause of crashes...

I really have no idea what you're trying to do but are you certain you're not trying to access some bogus memory locations?

are you getting access violations? stalls? what's happening?

sorry i skimmed the post...hope i didn't miss anything crucial.what do you mean with "resolution mismatch"? The pbuffer are more or less independent from the onscreen context. At least I use own rendering contexts for the pbuffers.

Principally my pbuffer wrapper works without problems, so I guess the problem lies somewhere else.

The System freezes and the ATI VPU recovery resets the GPU, without VPU recovery the system freezes.
But only if I switch to other task during the preprocessing (with extensive pbuffer renderings). Without task switch the preprocessing completes fine and without the preprocessing and task switches all works fine too. It definitely crashes during a pbuffer rendering, because if comment parts of them out my application is immune to task switch crashes. But after the extensive precproccessing at the start rendering to the same pbuffer works again fine without crashes (despite task switches)...

yooyo
10-22-2004, 01:45 AM
Just guessing.. Did you try to set WS_OWNDC during registration window class?

yooyo

valoh
10-22-2004, 04:33 AM
Originally posted by yooyo:
Just guessing.. Did you try to set WS_OWNDC during registration window class?

yooyothanks, I appreciate all guesses, because I'm completely out of ideas :(

I guess you meant CS_OWNDC? I don't know if and how this is used with the windows.forms. But a just hacked a win32 windows app together using CS_OWNDC and it doesn't make a difference. Still the same behaviour :mad:

btw: I just tried to do some of the preprocessing per frame. And with lots of pbuffer renderings the application then also crashes with task switches, so it doesn't have to do with problems during application start-up. It's somehow related to extensive pbuffer renderings and task switches...

any other ideas?

zeckensack
10-22-2004, 05:30 AM
valoh,
Regarding the "gotchas", I'm afraid that was more or less an off-topic hijacking of your thread. As you've said your code is strictly single-threaded, it shouldn't be an issue for you. Sorry.

Well, "shouldn't" ... even though I'm not sure about windows.forms (.NET, right?) work internally, this type of issue would bring down the visible render context first of all. That doesn't happen. So we can scratch the idea.

Next guess:
1)Does your pbuffer wrapper use wglGetPbufferDCARB to get persistent, unique device contexts for the pbuffers?
(i.e. don't reuse the DC you got from the visible window for the pbuffers, use that function to get one for every live pbuffer, and keep it around until the pbuffers is destroyed)

valoh
10-22-2004, 12:36 PM
yes, I use wglGetPbufferDCARB for the pbuffer device context. Every pbuffer gets its own render and device context. And they are only released together with the pbuffer.

I just made some simple test with glsl variations. And if I don't tricked myself somewhere it seem to be somehow related with glsl. I just switched to fixed pipeline rendering and it doesn't crashed and if I use the built-in OpenGL attributes rather than generic vertex attributes it doesn't crash neither...

But with other pbuffer renderings with glsl and generic attributes it doesn't crash. So it seem somehow dependend on how extensive is rendered to pbuffers with glsl :confused:

I already send an email to devrel@ati but unforunately ati dev support is always a little bit slow and unreliable :(

Imo to be a normal bug in my code it is too nondetermistic. All uses same pbuffer/shader wrapper code base. Crashing caused by task switches, depending on a shader and pbuffer combination. No crashing without task switches...