SVT Streaming Behavior Question: One Oversubscribed Pool Appears to Stall Streaming in Other Pools

Development Rendering
, ,
1

Hi everyone,

We are currently investigating a Streaming Virtual Texture (SVT) streaming issue and would like to better understand whether the behavior we are observing is by design or indicative of a potential problem.

Observed Behavior

In our project, we have multiple SVT pools configured (different page table / physical pools). We noticed the following:

  • When one SVT pool becomes oversubscribed (i.e. hits its physical page budget and starts evicting or throttling),
  • Streaming in other SVT pools appears to stop or significantly stall,
  • This happens even though the other pools are clearly not full and still have available physical pages.

As a result, virtual textures backed by the non-oversubscribed pools stop improving in resolution, despite having valid requests and sufficient free space.

What We Have Verified

  • The affected virtual textures reside in different pools than the oversubscribed one.
  • Pool sizes, formats, and VT types remain unchanged between runs.
  • Increasing the oversubscribed pool size (or reducing pressure on it) immediately allows all pools to resume streaming.

Question

Is this behavior intended in the VT system design?

More specifically:

  • Is SVT streaming globally throttled when any single pool is oversubscribed?
  • If so, what is the rationale behind coupling streaming progress across otherwise independent pools?
  • Are there any recommended approaches (configuration or code-side) to prevent one problematic pool from blocking streaming in others?

We are trying to determine whether we should treat this as expected behavior and adjust our pool budgets accordingly, or if this might indicate an unintended interaction or limitation in the current implementation.

Any clarification would be greatly appreciated. Thanks in advance!

[Attachment Removed]

2

Hi,

the throttling you are seeing when a single pool is oversubscribed is due to the fact that the virtual texture system is using a single feedback buffer (generated by the GPU) for all VT sampling. The CPU must parse this buffer to determine which tiles are needed. If one pool is thrashing, the system may be overloaded by the amount of continuous IO requests leading to repeated eviction and reloading of tiles which ultimately will defer or deprioritize the processing of non-oversubscribed pools.

[This [Content removed] outlines some console variables that can be tweaked to diminish throttling of VT streaming, although increasing the pool size is still the best solution to prevent oversubscription.

I hope this helps answer your question, but if you have more questions please let me know.

Regards,

Sam

[Attachment Removed]