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
Originally posted by Aeluned:
[b]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.[/b]
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)…
Originally posted by yooyo:
[b]Just guessing… Did you try to set WS_OWNDC during registration window class?
yooyo[/b]
thanks, 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…
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)
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
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…
