This question was created in reference to: [Multi Second Freeze in FD3D12PoolAllocator::CreateNewPool / CreateCommittedResource after upgrading to [Content removed]
Hi everyone,
I came across an older thread discussing long hitches related to FD3D12UploadHeapAllocator::AllocUploadResource, but it was closed without any final answer. Before we start digging deeper on our side, I wanted to check if there have been any updates or recommended approaches since then.
We’re on UE 5.6.1 with no custom changes to the rendering code. From time to time we see noticeable stalls, usually inside FTexture2DStreamIn::DoAsyncCreateWithNewMips. VRAM usage at the time is around 7 GB out of 24 GB, so we’re not hitting any limits. The callstack is essentially the same as the one people reported in the previous thread - the upload heap allocator waiting while a new pool is created.
Are there any newer advice or known workarounds for these stalls since that thread was closed?
sorry for the late reply. There is sadly enough not a real solution for this problem yet. Sometimes it just takes very long to allocate upload heap space on Windows I assume due to internal memory defragging/remapping.
Ideally we should move this off the critical path and no rendering jobs should sync with this and assume it can just sometimes take multiple frames for a single allocation without causing a hitch. For async texture creation this should be possible.
But 50 to 100msec is rare and I assume only happens with very big textures? What’s the size of the upload resource you are trying to allocate here? A possibility is to preallocate a few upload heap pools and make sure at least certain amount of heaps are always allocated. This will work if at least no super big outliers allocated.
Since you increased the frame lag already to max value I am assuming you don’t clear any of the previously allocated upload heap pools - which I guess makes sense because those shouldn’t take VRAM directly and should get paged out by the OS if they are not needed anymore and application can keep them alive. This is something we wanted to try as well locally. But since you are still running into the issue with above settings I assume a lot of extra pools are allocated in a single frame when many NPC mips come in during a single frame.
I wonder if the streaming upload can’t be limited and time sliced itself and thus making sure we don’t need more than x amount of upload memory coming from the texture streaming system during a single frame. I don’t know a lot of details of that system but I will ask around.
Can you try r.Streaming.MaxNumTexturesToStreamPerFrame and/or r.Streaming.AmortizeCPUToGPUCopy and limit the amount to a reasonable number and see if that helps?
We basically ran into the same issue. Our project basically doesn’t use VT and has many NPCs generated in real time, which means there are many textures (such as NPC clothing) mips need to be updated in real time.
These help mitigate the issue, but don’t completely solve it.
Based on the logs I printed inside
`FD3D12UploadHeapAllocator::AllocUploadHeap()`, when many NPC mips need to be updated/created (AllocUploadResource insize shows most of them are 4MB or 8MB mips), and when we are running high VRAM usage (though not over budget ), this problem tends to occur with a high probability even with changes above.
Could you please introduce a bit more about upload heap pools preallocating or do you have any other suggestions?