wglShareLists

Hi!

I am trying to use wglShareLists in order to share textures between the pbuffer context and the window context. I define the texture in the pbuffer context (glTexImage2D), update it in the pbuffer context (glCopyTexSubImage2D) and then use it in the window context (glBindTexture). When I bind the texture nothing happens. The last binded texture stay binded.

I chechked the documentation of the function, but it relates only to sharing display list, and doesn’t mention the possibility of sharing textures.

I call wglShareLists that way:
wglShareLists(WindowRenderingContext, PBufferRenderingContext);

any ideas why it doesn’t work?

Thanks,
Shlomi.

I’ve had similar problems with wglShareLists - we even discussed it on this board.

wglShareLists should also allow sharing of textures bwtween contexts. On ATI drivers it doesn’t seem to have an effect. On NVIDIA drivers textures seem to be shared by default. We didn’t get any of this confirmed by any of the driver writers.

Why don’t you use your window render context to draw into the pbuffer and copysubimage it into a texture?
Your pbuffer doesn’t have to have a seperate render context, only a device context.
Maybe you know this already, and have another reason for doing it that way.
I haven’t checked the ogl wgl specs, but there doesn’t seem to be much documentation on wglsharelists, even though it’s an incredibly useful feature. All I can say is this - in MSDN it states that the context that is sharing its display lists should not contain any existing display lists when wglShareLists is called. Quite a limitation. The nvidia drivers seem to ignore this limitation (happily) - I’ve shared contexts textures with a newly created context AFTER the textures have been created.

Hi,

Thanks for your replies. I didn’t know that I can use the window rendering context with the pbuffer. I have tried this, but it doesn’t seem to work.

I don’t create a rendering context to the pbuffer, and when I make the bpuffer device context current I use the window rendering context.

The problem is, that glCopyTexSubImage2D and glReadPixels (I have tried that too) generates a GL_INVALID_OPERATION error (for some reason they generates infinite number of errors).

Maybe I should match the pbuffer pixel format to the window pixel format? How do I do that?

BTW: I think it will be quite usefull to have a different rendering context for the pbuffer, because then you can easily set it’s own matrixes and properties.

Shlomi.

[This message has been edited by Quaternion (edited 05-16-2002).]

Hi,
I set the stencil bits of the window to 0 and now it’s working…

knackered, I still don’t think that it’s a good idea to use the same rendering context for the window and the pbuffer… So, what about that wglShareLists?

Shlomi.

Well, yes, there are advantages to having seperate render contexts - such as keeping seperate render states (lighting, matrices etc.)…but, remember that when you switch from one context to another all the opengl states will have to be changed - unlike when you use the same context when you control what states need to change, and which don’t.
In other words, it’s faster to use a single render context.
I don’t know what’s wrong with wglShareLists for you (it works fine for me, but I don’t use it much) - what card are you running it on?

I use nVidia GeForce 2 Ultra.

And one more thing, I can think of another good reason to use a different rendering context for the pbuffer. Let’s say you want to use stencil in your window rendering, but don’t want it in your pbuffer. You must set the stencil bits in the pbuffer pixel format, and that will be a waste of memory if you don’t use them with the pbuffer.

True. And you may also not want your pbuffer double buffered, or with a depth buffer.
Ah well, keep plodding away at wglShareLists - write a simple test program to find out the problem.

[This message has been edited by knackered (edited 05-17-2002).]

Originally posted by PH:
[b]I’ve had similar problems with wglShareLists - we even discussed it on this board.

wglShareLists should also allow sharing of textures bwtween contexts. On ATI drivers it doesn’t seem to have an effect. On NVIDIA drivers textures seem to be shared by default. We didn’t get any of this confirmed by any of the driver writers.[/b]

What do you mean with “doesn’t seem to have an effect” on ATi drivers? In my experience wglShareLists() works as expected and without any problems in ATi drivers.

I figured I would throw in my 2 cents on the entire multiple contexts/pbuffers/sharelists topic.

Just to note. Depending on the video card/driver revision there is a good chance that if you request a 24 bit Z buffer it automatically allocates the other 8 bits for the stencil. Even if you don’t request it. I really believe this happens on some systems but I am not entirely sure and haven’t really thought of a way to verify if this happens.

As for sharelists it seems that nvidia drivers generate texture ids that are unique across all contexts. Regardless of whether or not they contexts belong to the same process. Basically the sharing isn’t usually necessary. Although everything would work 9 times out of 10 sometimes it would just act weird. Since then I always call glShareLists and its never been an issue. I think it might act differently with different drives and cards (All nVidia I mean).

Devulon

Originally posted by Humus:
What do you mean with “doesn’t seem to have an effect” on ATi drivers? In my experience wglShareLists() works as expected and without any problems in ATi drivers.

I may be wrong but I never really got it to work ( as I think it should function logically ). I implemented renderable textures using pbuffers/ARB_render_texture that works on both ATI and NVIDIA drivers without using wglShareLists. There are definitely some unfortunate differences between ATI’s and NVIDIA’s implementations. Try, for instance, NVIDIA’s simple_render_texture on Radeons - it simply doesn’t work ( I think this is NVIDIA’s fault ).

quoting MSDN: “All rendering contexts of a shared display list must use an identical pixel format. Otherwise the results depend on the implementation of OpenGL used.”

That means that in general it isn’t possible to share textures between different rendering contexts which use different pixel format, isn’t it?

Shlomi.

One more thing - I initially implemented renderable textures on GeForce3 using a single rendering context ( to simplify state management ) - this worked out nicely but didn’t work on Randeon 8500 ( I think this is ATI fault :slight_smile: ).

Quaternion,

That’s correct but the pixelformat I use for the main window and the pbuffer are 100% compatible. There’s another nice difference, NVIDIA doesn’t require a valid RC for using WGL_ARB_pixelformat but ATI does! Both companies can’t be right ( in this case, I have no idea who’s right ).

Originally posted by PH:
NVIDIA doesn’t require a valid RC for using WGL_ARB_pixelformat but ATI does!

What do you mean? wglChoosePixelFormatARB requires a device context not a rendering context.

Shlomi.

[This message has been edited by Quaternion (edited 05-17-2002).]

Yes, but usually a rendering context in needed to use GL functions. I guess ATI’s implementation has a bug ( you’ll get a crash if you call wglChoosePixelFormatARB without a valid RC ).

EDIT:
Correction: not a crash but an error message.

[This message has been edited by PH (edited 05-17-2002).]

For a p-buffer you dont need an RC, that;s why I call

wglMakeCurrent(NULL, NULL);

before creating the p-buffer. You need a DC as usual.

Its multisample that needs an RC for getting the function pointers (unless I read things wrong).

V-man

Originally posted by V-man:
Its multisample that needs an RC for getting the function pointers (unless I read things wrong).

You can use WGL_ARB_pixel_format to select a normal pixelformat for your window too. Yes, the temporary RC is for getting the function pointers but with ATI’s drivers the RC needs to be valid when you use the functions ( with NVIDIA’s drivers, you can delete the RC before using the functions ). After selecting a pixelformat, you can delete the temp RC ( and create a new one with the selected pixelformat ).

[This message has been edited by PH (edited 05-18-2002).]