My understanding of that OpenGL extension is to allow a single application to mix and match Direct X resources/buffers/objects with OpenGL resources/buffers/objects. No where does it mention out of address space sharing, or OS level global IDs for resources, which is required.
Additionally, this is an NV extension only, and is not supported by ATI.
Its interesting, but no where near as flexible as IOSurface is on Mac OS X, and sadly would not enable a GPU accelerated video sharing library on Windows.
Even the example code shows one application mixing and matching D3D and OpenGL resources.
If you think about it, it makes sense; Its all happening on the same hardware. Allocating a texture/buffer/resource in OpenGL makes takes up memory and exists somewhere on the GPU. One ought to ‘get access to that’ on the memory address on the hardware via a different API (in this case, Direct X). All this is doing is making a translation layer for a *single* application.
IOSurface is different.
It allows global resources to be created, which have unique handles *across applications, and GPUs* (yes, you can share resources across GPUs, so even on separate hardware, from different vendors)
It has capabilities to handle bouncing to main memory, so you can lock an IOSurfaceRef on the GPU, or on the CPU. Its ‘agnostic’ to where it lives.
Etc. Its much more robust, and meant to handle scenarios just like Syphon does. WGL_NS_DX_Interop does not come close, sadly.
Secondly, if you are mixing and matching D3D/DX and OGL in a single app and need to share resources, I question your applications architecture. This extension is there to solve a *very* specific issue for a very small portion of developers.