How to prevent the increase in the number of LockedPages for RuntimeVirtualTextures

(This is a translation of a [Japanese [Content removed] by Kimura.)

Thank you for your continued support.

I would like to ask about the issue of the increase in the number of LockedPages for RuntimeVirtualTextures (RVT), which congests the pool.

I have created Landscape materials using RuntimeVirtualTextures, and placed the Landscape and a RuntimeVirtualTextureVolume in a World Partition level. (I have enabled Adaptive Page Table for the RuntimeVirtualTextures.)

I have confirmed that in UE5.5, continuously moving within this level results in a continual increase in the number of LockedPages. Also, even after returning to the original position, the number of LockedPages does not decrease as long as the level continues.

In contrast, when testing in UE5.6, the number of LockedPages could decrease even while the level continued.

So, I would like to ask about the following:

(1) Is it correct that the behavior where the number of LockedPages for RuntimeVirtualTextures does not decrease in UE5.5 is a known issue? Or is there a possibility that the way of my testing was wrong?

(2) Is there any way to prevent the increase in the number of LockedPages for RuntimeVirtualTextures, or to explicitly release LockedPages?

Thank you.

再現手順
1) Use a Landscape material using a RuntimeVirtualTexture.

2) Place the Landscape and a RuntimeVirtualTextureVolume.

3) Enable Adaptive Page Table for the RuntimeVirtualTexture.

When starting:

[Image Removed]

After running around:

[Image Removed]

Hello,

In 5.6 we made some changes to our Virtual Texture defaults:

r.VT.MaxUploadsPerFrame = 2 (reduces cost of RVT updates) r.VT.MaxUploadsPerFrame.Streaming = 32 (separates out the budget for VT streaming updates) r.VT.MaxReleasedPerFrame = 5 (reduces maximum cost for world partition streaming scenarios) r.VT.PageFreeThreshold = 15 (better balance for keeping VT pages in the cache vs blowing VT residency)There were also several fixes that went into 5.6 and changes to the feedback system. I’m passing this onto my colleague who is more familiar with what changes may affect LockedPages.

Hi,

We did observe similar behavior when initially working on the Witcher tech demo for UnrealFest.

RVT Adaptive Page Tables rely on a grid of dynamic allocated virtual textures (FAdaptiveVirtualTexture::AllocationSlots in the code). Each element of that grid can generate locked pages and only releases them when the grid element is fully released. In 5.5 the default settings for releasing allocations was very conservative. This is because each release triggers a page table remapping which is a potentially expensive operation. In 5.6 we tweaked the logic for a better trade off:

* We changed r.VT.AVT.AgeToFree from 0 (never free) to 1000 (free at age 1000)

* We added r.VT.AVT.PoolResidencyToFree which changes the heuristic to take both age and pool residency into account.

With the 5.6 code changes in AdaptiveVirtualTexture.cpp and the 5.6 default settings you should still see the locked pages taking a proportion of the pool residency, but hopefully you should also see it reducing when not moving through the world for a long time. You can tweak the two console variables mentioned above if you need more control.

It’s probably worth mentioning another 5.6 change that might have had some small impact here:

https://github.com/EpicGames/UnrealEngine/commit/ee4b1cff3bbe9f7cf0bc35e60f1d5d7e6a259855

I only mention it because it has an impact on allocation behavior, but it’s not as important as the main changes already mentioned above.

And I’ll also mention an unrelated but very important 5.6 change that fixes potential temporary page corruption with adaptive page tables:

https://github.com/EpicGames/UnrealEngine/commit/218af0adc51412680eb35472ae96425e4321c794

Best regards,

Jeremy

(This is a translation of a Japanese post by Kimura.)

Thank you very much for the information.

I’ll be confirming if it works when the project is updated to UE5.6.

Thank you.