FVirtualTextureSystem::GatherAndSubmitRequests appears to be waiting almost a full frame for IO to complete, which in turn is blocking the render thread.
This thread references keeping streaming levels to the loaded state (i.e. not visible) for a few frames (we are streaming during this capture)
[Content removed]
I’ve done this and it hasn’t alleviated the problem. I’m also unsure of what a few frames means as there doesn’t seem to be any way to query the virtual texture system whether it’s “cool down”
I’ve also tried setting r.VT.SyncProduceLockedTiles to 0, but that didn’t seem to help either.
The solution to this _should_ be to set r.VT.SyncProduceLockedTiles=0 (which is the default from 5.6 onwards). This will prevent stalling on IO when filling the “root pages” of a virtual texture.
You said you had tried this. Was that in editor or a cooked build? In editor we ignore the cvar and always stall. We do that because the occasional hitches are usually less problematic in the editor, and the editor is often used for baking processes where correctness of the root pages becomes important.
If you are seeing the hitch in a cooked build with r.VT.SyncProduceLockedTiles=0 then it could be that you are using some synchronous function such as LoadPendingVirtualTextureTiles(). Do you see that in the callstack? That function is meant to be used when forcing some virtual texture tiles to become immediately resident.
Otherwise maybe you are hitting some bug. If that is the case, could you break in FVirtualTextureSystem::SubmitRequests() and look to see when bForceProduceTile gets set to true?
r.VT.SyncProduceLockedTiles=0 Did in fact fix the issue. I mixed up the VT stall with another stall on the render thread in later traces, but after looking back I’m not seeing any stalls related to VT IO anymore.