- This topic has 7 replies, 3 voices, and was last updated 9 years, 6 months ago by
.
-
Posts
-
so faq says:
“Does Syphon work on Windows or Linux?Unfortunately, the underlying technology the Syphon Framework utilizes does not exist on any platform other than MacOS X. Syphon leverages MacOS X’s IOSurface API, allowing memory on the graphics card to be shared between applications. Other platforms are restricted to sharing main memory, which is much slower for video tasks.”
then what’s this?:
http://developer.download.nvidia.com/opengl/specs/WGL_NV_DX_interop.txtif i understood well this wddm feature, windows is very capable of a thing like syphon just it’s not as simple as syphon yet. so at least the question or the answer should be corrected.
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.
wddm allows sharing resources over applications through these share handles though the link i provided is not the best example of usage of them (i’ve just got into this stuff lately) but aero’s taskbar thumbnail previews works that way (and ms provided a higher level api (in the dwm) for accessing/replacing them or creating new ones).
http://en.wikipedia.org/wiki/Windows_Display_Driver_Model#Cross-process_sharing_of_Direct3D_surfaces
this says also wddm has the capability to share resources so not just textures or framebuffers but vertexbuffers or complete meshes as well (i guess that works through multiple hardwares too but i’m not sure about it). it’s in the windows sdk so it should be vendor independent.
and here’s the reference: http://msdn.microsoft.com/en-us/library/dd327290.aspx
this whole thing is terribly documented though. it’s obscure and it seems ms doesn’t really have a robust idea about its practical usage (like syphon targeted rather vj’s and av performers and other realtime purposes ms hasn’t targeted anybody (and it doesn’t look like they will ever target the same audience as syphon)however it works only in dx9 and above and win7 only and this nvidia extension could translate them to opengl applications (so ffgl plugins as well) but unfortunately i haven’t find an alternative from ati.
well i guess if someone does an easier higher level api for this wddm stuff (so a syphon clone for windows) that will be a completely different story. i doubt microsoft will ever support opengl with this (so no ffgl flexibility in the near future for windows) 🙁Oh, well shit. I stand corrected, but this is more a WDDM OS thing than an OpenGL extension. Thats awesome either way.
Actually, looking into this, it looks like you need specific user rights to do this, according to a tech-note from MS, but its cool that its possible at all. 🙂
(the priviliges is required for some cross process communication, not directly for the sharing)
maan this is busted, it’s like microsoft doesn’t want people to use it. anyway i’ll definitely go deeper into this stuff next month probably. i have an application for windows where the user interface and the output are 2 separate processes. if i could find out how to use this feature in wddm the gui wouldn’t have to do the same image processing again for the previews (shared memory was even slower) and that could solve some performance problems.Looks promising. If you (or anybody else with some experience of programming on Windows) are interested in exploring this, keep us posted.
found this http://msdn.microsoft.com/en-us/library/bb219800(v=VS.85).aspx#Sharing_Resources
turns out when you create a surface you just have to give it a yet unused handle and put it in D3DPOOL_DEFAULT memory class. opening happens with the same function using an existing handle. if that handle is NULL the surface is private. i will test it in vvvv with textures. if it really works this simple the only task will be creating an ffgl plugin (for flexibility) what converts a dx surface to an opengl one or converts an opengl surface to a shared dx surface and find a vendor-independent solution for that.
- You must be logged in to reply to this topic.