Shared lists bug on NVIDIA?

OpenGL OpenGL: Advanced Coding
1

We have an app that has worked for ages on NVIDIA cards, and recently we discovered that shared lists (two rendering contexts) do not work properly on some Intel and ATI cards.

It turned out that we had been doing bad things all along, but the NVIDIA drivers were very forgiving. What we did was that some display lists were created and drawn to in the “child context” BEFORE calling wglShareLists. According to the spec. that is not allowed.

The hglrc2 parameter should not contain any existing display lists when wglShareLists is called.

As I see it, this is a bug in the NVIDIA drivers.

Please correct me if I’m wrong.

2

NVidia has historically been forgiving in their drivers, that’s why I typically use an ATI card for programming. Id say that this isn’t a bug, it’s just a form of out-of-spec kindness.

3

I’ve had a similar experience, except this time, the code works fine on ATI cards according to specs but not on NVIDIA cards.

Specifically, I am trying to share fragment programs (arbfp1.0) across two or more contexts. NVIDIA’s drivers (nvoglnt.dll) give me a memory access violation. It is weird. The code can be as simple as scaling the pixel intensities or any one line pixel color manipulation, or whatever, and the program crashes. However, if I put in an empty FPO (e.g. simply copying the result.color to itself), the program runs fine. Of course, it doesnt’ do anything remotely useful.

Has anybody else had similar issues, and can I get an idea how to report this bug to NVIDIA engineers?

4

My 2c are, that Microsoft’s documentation is about their implementation and this is not a spec. Then they say “should not”, not “must not” and the success or failure of the sharing was correctly indicated by returning TRUE or FALSE, so all the implementations behaved correct by the letters of the manual.
Rule of thumb: Just do wglShareLists immediately after the creation and this wouldn’t be an issue.
From my own experience the second context must not be current during wglShareLists or you get a “resource in use” from GetLastError.

5

UDPATE:

I’ve narrowed down the problem to somewhere within my fpo. If I use the following program:

!!ARBfp1.0
TEMP R0;
TEX R0, fragment.texcoord, texture, 3D;
MOV result.color, R0;
END

everything’s ok. The program looks up the texture and renders it unchanged.

However if I add one piece of redundant code:

!!ARBfp1.0
TEMP R0;
MOV R0, program.env[0];
TEX R0, fragment.texcoord, texture, 3D;
MOV result.color, R0;
END

now the program crashes after I call wglShareLists (but would run fine standalone). My theory: It’s as if NVIDIA maintains separate program variables/environments for each rendering context, and forgets to copy it over after wglShareLists is called. The result is a memory violation access, as I mentioned in the post above.

I’d like to use program.local or program.env to get dynamic inputs into the fpo. For instance, I could use it to modify result.color after texturing.

Can anyone else help me verify this, or post workarounds?

Thanks in advance.

6

UPDATE:

I’m sorry to have derailed this thread… but, I’ve found the workaround. It turns out that in NVIDIA’s implementation, before calling wglShareLists(hglrc1, hglrc2), hglrc2 must NOT have any lists or program objects initialized. I tried deleting the lists and program objects before calling wglShareLists, but that apparently doesn’t work.