pouët.net

hi, i hope this is the right place to ask this:

is it possible to share a texture between to independent processes? each having their own directX context.

the idea is that one process renders to a texture and the other one actually displays it.

i already googled around and found some hints that it could work, but only if the contexts are spawned from the same process. it's even possible to share from OpenGL to DirectX:
https://www.opengl.org/registry/specs/NV/DX_interop.txt

it is possible since dx9: https://msdn.microsoft.com/en-us/library/windows/desktop/bb219800%28v=vs.85%29.aspx#Sharing_Resources

thanks!

Basically it's only possible if the process makes its resources shared. Which it generally doesn't, unless you are the one who writes both processes.
In which case it's generally more efficient to just put all functionality into a single process (even if you use multiple APIs. MS has a sample somewhere of D3D9 and D3D10 running from the same process, and sharing textures. Not sure why you'd ever want to do something like that, but it is possible).

I believe the functionality was mainly added for efficient sharing of resources between different GPUs/drivers, eg for things like having a multi-GPU, multi-monitor setup, where GPU 1 renders on a monitor that is connected to GPU 2. Or for things like nVidia Optimus. Not so much for regular application development.

What exactly are you trying to do? Just curious as it seems like a less than sensible solution to most of such problems (e.g. host -> renderclient type things) :)

Scali: well, off-the-cuff I'd say that sharing rendering resources between processes could be useful for web browsers which could sandbox each rendering context in a separate process, just for extra security measures. Something like that is not possible in OpenGL at all.

How would it be useful? Like in Chrome, the process takes care of rendering what's in the client area. What needs to be shared, realistically?

My first hunch would be running plugins and addons in a separate process (Firefox-style)

superplek: What gargaj said + a special compositor process, which:

* has access to the rendered contents of each page, hidden under each tab
* lets the user quickly switch between the tabs (remember: each page is rendered in a separate process, so if the compositor does not have access to worker process resources, it's screwed).
* perhaps exposes contents of many tabs at once, if you have a large display? I bet the UI folks would come with a plethora of use cases for such a work environment :)

Now, I'm not saying that distributing workload between separate processes is the first thing you'd do in your demo; all I'm trying to convey is that there may be uses for such concepts but they're sadly very difficult to define in a cross-platform manner.

Another use case that I'm using: C++ intro rendering windowless, C# tool analyzing the intro frames in realtime (histogram etc.) and displaying the intro at the same time. Interprocess DXGI surface sharing with WPF Dx9 interop (and additional hacks for dx11).

xTr1m: out of curiosity - are you seeing any performance penalties owing to the inter-process architecture of your software?

Seems to be the long way round though :)
I put a .NET wrapper around my C++ code, so it can be hosted from a C# app.
When using SlimDX or SharpDX, you can also get access to the D3D resources of the engine in C#.

That was clear. If it's a very sane level of abstraction is another matter though :)

I haven't done any measurements. For me it's sufficient to know that: If the intro runs at <60FPS in release, it runs at <60FPS in the tool. If it runs at ~60FPS in release, it runs at ~60FPS in the tool. Therefore, any performance costs are negligible for me.