I am trying to use ARB_vertex_program together with shared display lists on multiple rendering context’s (rc).
Extensions documentation for ARB_vertex_program says this
should be working.
With one rc everything goes well. A little after a second rc is created and displayed (I see my vertex program allready correctly working on both rc) I get errors ranging from GPF at address (access to hex 0 or hex 4 or sometimes other in nvogl.dll)
up to strange messages from ogl subsystem (“Out of memory”).
Has anybody ever tried to use a ARB vertex program together with shared display lists on Nvidia hardware and can confirm
(or not) this ? Is there anything one must take special care of when doing so ?
(driver is 40.72 or 41.09 on W2K)
I haven’t used shared display lists, but I’ve used shared vertex programs (both NV_v_p and ARB_v_p) with multiple rendering contexts and have not had the problems you mention.
i only worked on one multi-rc project… basically windows suck a bit when you’re using more than one context. from what i can recall, you have to make sure that all gl windows are created from a class that has CS_OWNDC style as well as clip siblings/clip children styles.
that done, when you’re switching contexts, you might have to call wglMakeCurrent(NULL, NULL) first, before calling it for the correct context… explanation: dunno why, but msdn docs changes slightly over the past few years regarding this func - it’s now supposed to release the dc as well which is obviously utter idiocy but there you go… this comes from .net msdn (so reasonably up-to-date), but i’m pretty sure that’s not what msdn said back in 96/97… i only found out this discrepancy a few weeks ago - what might be happening is that your dc gets released without your knowledge (when you think all you’re doing is switching glrc’s)…
i remember having quite a few low-level gotchas like that in a multi-rc app… my advice would be to insert some run-time checks for the dc and glrc variables (wglGetCurrentContext() and wglGetCurrentDC()) - compare your vars with what you get from those func calls - in my case i found out that they frequently get messed up (this was on 9x, should be much better on 2k/xp)…
finally, sharing display lists shares all other “objects”, so textures as well as vertex/fragment programs become shared too…
Thanks for your reply. Just an observation:
It needs from 30 to 80 frames rendered in the
first rc after the second rc is used when this crash happens. So I can move the window with the second rc a little around. The crash happens when the first window gets invalidated. I think the error address (h00 or h04) and the non immediate nature of this error indicates a buffer overflow or so in the driver. For now I will disable arb_vertex_program for any other than the first rc.