NVIDIA's simple_render_texture

The demo doesn’t work on Radeon 8500 for some reason. If I’m not mistaken, it shouldn’t even work on GeForce cards. The texture object that the pbuffer is bound to is not shared by calling wglShareLists - isn’t that required for sharing textures between contexts ?

If I remove the line glBindTexture(…) in display(), it works on Radeons. Adding wglShareLists to the code didn’t solve anything…

Also, in the spec it says WGL_ARB_make_current_read modifies the definition of the extension but it doesn’t say in what way ( I couldn’t find it ).

I’m starting to wonder what the correct usage of the extension is ( it should be obvious ).

You can share a rendering context between a pbuffer and a regular window as long as the format for your desired pbuffer is the same as the existing window. When you do this you no longer have to call wglShareLists as there is only one rendering context.

Yes, that’s true. I used to use that method but DanO from ATI said it wasn’t much faster that creating a seperate context. It was a lot easier to manage state though. I took it out because it wasn’t documented anywhere ( except being mentioned in some NV presentation ). My code worked on GeForce3 but it failed on Radeon 8500 .

The simple_render_texture creates a context for the pbuffer so it should really be using wglShareLists. To share the context should it not call wglGetCurrentContext(…) for instead of wglCreateContext(…) ?


I’ve got a test app that uses wglShareLists() as I believe it should, and it runs on both GeForces and Radeons. I just tried commenting out the wglShareLists() call, and it continued to work on my GF3 – very peculiar. Although I don’t see how it could work without it, wglShareLists() isn’t mentioned anywhere in the extension spec?!?

– Tom

That’s exactly what I thought. It even works on Radeons without the wglShareLists which I’m pretty sure is required when creating a seperate context for the pbuffer. Very strange.

The reason why you don’t need wglShareLists is because the render-texture object was created in the main windows rendering context. So when you call wglBindTexImage you pass in the handle to the pbuffer which then “fills” the texture object.

Ok, that makes sense. I got my own code to work on multiple hardware now. The problem in my own code was actually due to the texture object not getting shared by calling wglShareLists ( I bound it in the pbuffer context but had created it in the windows context ).