Strange/broken shared texture behavior
mediadog opened this issue · comments
The following is with 50beta35.2_x64 and DX11 1.0.1, have not tried other combos yet.
I have found that using shared texture feature of the Renderer (DX11 TempTarget) is unreliable, while using the AsSharedTexture node with it always works. I discovered this when using the OpenVR node, which uses the Info node to get a handle to the shared renderer texture to pass into the compositor, in a patch that uses shared textures in other places to talk to other processes.
When I am using that patch with projectors, I have saved the patch with the Evaluate pin of the OpenVR node set false. When I am using it with the Vive for development, if I turn the OpenVR Evaluate pin on after the patch has loaded and the other textures are being shared, the OpenVR node fails as the Info node for the Renderer in it returns -1. If I load the patch saved with Evaluate true, it gets a good handle. (I am seeing similar failures with the Writer (Raw SharedMemory) node failing, which I'm still exploring, so this may be a general vvvv issue.)
If I modify the Renderer (OpenVR DX11) node to replace the Info node that has the exposed Resource ID pin with AsSharedTexture, everything works just fine; no matter the saved state of the OpenVR Evaluate pin. This is in a large complex patch, so I have not yet been able to isolate it down to small patch, but can try if needed.
Another odd thing is that an Info node of the Renderer (DX11 TempTarget) buffer output shows a resource ID even with the renderer Shared Texture input pin set to false, and toggling it causes the Resource ID to change when turning it both off and on.
And one last oddity, and this is with DX11 shared textures whether the ID is sourced from Info or AsSharedTexture: if the process reading the shared texture (with the ID passed via raw shared memory) was already running before the vvvv instance sharing the texture, it cannot read the texture. It has to be started after the sharing process. If the reader process is started first, then the writer loads, the FromSharedTexture node will blink red and the console will show:
ERR : Exception occured in TMPluginWrapperNode.Evaluate
ERR : Attempted to divide by zero.
With the attached zip file, start the writer patch, then start the reader in a different vvvv instance, and things are fine. Kill the writer, then restart it in another instance, and the reader does not work. I'm guessing the Nil going into FromSharedTexture before the writer process loads is causing it to get into an unrecoverable state.
ACK! STILL won't let me upload a zip file! Find it here:
http://old.noirflux.com/xfer/SharedBug.zip
Info (DX11) returns only the resource pointer, not a shared handle.
This was used for debug purposes (double check that temp target does or does not reallocate, or that file textures got reloaded).
It has nothing to do with shared handle.
On the OpenVR side, it expects a raw texture pointer (since it decided to use a debug pointer instead of having standard texture input), so using a shared handle might be supported by openvr or not (likely not).
On the temp target side, there was a pr for adding this shared toggle, I should quite have declined it, AsSharedResource is the only supported way to do so.
As a side note to have this sorted properly, should submit an issue to the OpenVR repo so the compositor uses a standard Texture input instead of debug pointer, which would solve this confusion (and also not blast up the render graph).
"I see!" said the blind man to his deaf dog - thanks for the explanation.
But there is still the bad behavior of getting -1 from the Info node after other textures are shared (I'll see if I can get get example patch), and the sequencing problem demonstrated in the zip file - were you able to confirm that?
I just checked code, seems FromSharedTexture would not like nil as it is now.
Better to leave a zero handle instead i'd say for now