It happens when you create a PBuffer; after creating the rendering context, you call wglShareLists with the main rendering context's, to share textures/vertex programs/etc..
However, all textures created by the main context before, are not valid when the PBuffer's context tries to use them. All textures created after can normally be accessed by both the main and the PBuffer's context, though.
It doesn't happen on NVidia cards.
It's especially tricky for my impostor manager, since it doesn't know at load time how many impostors (so how many PBuffers) will be needed. So it's technically not possible to create all the PBuffers at load-time, so that all OpenGL texture objects are created after, and ignore the problem.
Second thing: i got a new beast today at work... an NV 6800. Nice little thing. I'll take a few hours in the next days to play with pixel shaders 3, it's gonna be fun.
However my clouds demo didn't run very well on it - approximately 40 fps, against 250 fps on my old Radeon 9700 Pro. Weird. I tried to track the problem, and discovered that for some unknown reason, using a dynamic IBO (index buffer object) cuts the framerate by a factor of more than 4. I "fixed" the problem by disabling IBOs, and using system-memory index buffers instead, but i do not feel comfortable with that solution. The update is done by calling glBufferSubDataARB, so there is no video memory readback (or other obvious pitfalls). What's even more strange is that for a few seconds it runs well - the slowdown occurs after a few IBO updates. The driver's IBO memory manager might be at fault here, but i'd love to get a confirmation of that.