You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm writing a background application that accesses the compositor output every frame. The application opens both eye mirror textures using GetMirrorTextureD3D11, reads the mirror texture SRVs with a compute shader, and copies a set of output to the CPU, blocking with the Map function until completion.
If I call ReleaseMirrorTextureD3D11 on the mirror textures directly after waiting on Map and copying the data, when I the next frame call GetMirrorTextureD3D11, it gets stuck serving the textures from the original frame over and over. This goes on for about three seconds until it serves fresh textures, and then repeats the cycle. Debugging with Nsight Systems, the committed VRAM ramps up to about 26GB under those seconds before evicting the allocations and allowing the new textures in. It does not actually fill up the VRAM, it only seems to retain the SRVs which show up as committed memory.
When shutting down the application with the D3D debugging layer, it reports a large number of live objects with refcount 0, seemingly matching the current number of SRVs.
D3D11 WARNING: Live Producer at 0x000001FF9F8BC110, Refcount: 835. [ STATE_CREATION WARNING #0: UNKNOWN]
D3D11 WARNING: Live Object at 0x000001FF9FBBCFB0, Refcount: 0. [ STATE_CREATION WARNING #0: UNKNOWN]
D3D11 WARNING: Live Object at 0x000001FF9FB14440, Refcount: 0. [ STATE_CREATION WARNING #0: UNKNOWN]
D3D11 WARNING: Live Object at 0x000001FF9FB207D0, Refcount: 0. [ STATE_CREATION WARNING #0: UNKNOWN]
...
If I call ReleaseMirrorTextureD3D11 on the next frame immediately before calling GetMirrorTextureD3D11, I get the correct compositor textures, but still get the same behavior with the SRVs being retained.
The weird part is, if I don't call ReleaseMirrorTextureD3D11 at all, everything behaves as expected, with no ramping up of committed VRAM, and no live objects when exiting. I'm still hesitating to refrain from calling it, since it has to have some purpose, right?
Tested with a Valve Index on SteamVR 2.10.1 on Windows 10, using a RTX 4070 with driver version 560.94
The text was updated successfully, but these errors were encountered:
I'm writing a background application that accesses the compositor output every frame. The application opens both eye mirror textures using
GetMirrorTextureD3D11
, reads the mirror texture SRVs with a compute shader, and copies a set of output to the CPU, blocking with theMap
function until completion.If I call
ReleaseMirrorTextureD3D11
on the mirror textures directly after waiting onMap
and copying the data, when I the next frame callGetMirrorTextureD3D11
, it gets stuck serving the textures from the original frame over and over. This goes on for about three seconds until it serves fresh textures, and then repeats the cycle. Debugging with Nsight Systems, the committed VRAM ramps up to about 26GB under those seconds before evicting the allocations and allowing the new textures in. It does not actually fill up the VRAM, it only seems to retain the SRVs which show up as committed memory.When shutting down the application with the D3D debugging layer, it reports a large number of live objects with refcount 0, seemingly matching the current number of SRVs.
If I call
ReleaseMirrorTextureD3D11
on the next frame immediately before callingGetMirrorTextureD3D11
, I get the correct compositor textures, but still get the same behavior with the SRVs being retained.The weird part is, if I don't call
ReleaseMirrorTextureD3D11
at all, everything behaves as expected, with no ramping up of committed VRAM, and no live objects when exiting. I'm still hesitating to refrain from calling it, since it has to have some purpose, right?Tested with a Valve Index on SteamVR 2.10.1 on Windows 10, using a RTX 4070 with driver version 560.94
The text was updated successfully, but these errors were encountered: