DX11 Info (DX11.texture 2D) Unreliable

I have been chasing my tail on this for a day now. Sometimes Info returns all -1s on its output pins, even though the texture will display perfectly well in a Preview (DX11.Texture) window.

At first I thought it was some other code corrupting things, and would delete some nodes, and then it worked, but I finally realized that was just random and I was going down false paths. I can load a texture with FileTexture (DX11 2D), it will return -1s, then load another file, all OK, then load another, -1s, all of them showing fine in the preview window. It seems the more temp renderers etc. I have in my patch increases the odds of it failing. The real pain is that this is causing the OpenVR renderer to fail as the Compisitor is getting a -1 resource handle.

I seem to have some dim memory of a signed/unsigned issue a while back on texture handles, but maybe that was DX9.

This is on beta 40, DX11 1.3.1, Win10 Enterprise 1909, dual nVidia 1080s, latest driver (471.41). I am unable to create a patch that reliably shows the problem sadly other than it almost always seems to fail after OpenVR is loaded - but not always. Any ideas folks? Thanks

Got the same behavior on an Alienware laptop with GTX 1060 on Win10 and an older Intel GFX laptop on Win7. Seems to be related to loading a model with the Assimp nodes; the model loads and displays fine, but then the Info troubles start. Could some Assimp memory leak be screwing up the DX11 contrib code somehow? This happens even if I load none of the textures associated with the model file, just get the geometry out of it.

Use GetDimensions inside shader, that’s reliable

That’s a thought, and will help with my modules that do proper texture scaling on quads, but the issue I’m having now is OpenVR will not work because the Renderer module has an Info node inside it to get the handle to the texture to pass into the compositor. Any other way to get that? Thanks!

Recently had same problem and had to do the tests, I think it worked only if you had temptarget in between.
You have two options here.
First, to provide resolution from patch directly.
Second is to do compute with texture input and get dimensions and read back.

There is also third option to debug it with visual studio…

Guess I wasn’t clear enough - Info also provides a shared handle to the texture, which is what the OpenVR Compositor uses, not the texture dimensions.

Seems like a proper pain in the b…t…
Don’t see any way but fixing source…