Texture streaming rework#5829
Conversation
This is a big one: - Reworks the discard signal almost entirely. Now has a normalized 0..1 discard signal: distance x size x channel exponent, floored by staleness and background app state. Shaped by VRAM pressure. - Textures can now scale down to the smallest GPU mip (1×1), independent of the codec's encoded mip count. - Terrain texture LOD now works. Useful for 2K textures and PBR on terrain. Based upon camera distance to nearest terrain patch. - New texture quality setting. Low/Medium/High/Ultra - Caps texture resolution on Low to 1024, and otherwise shifts the discard signal around. Makes distance based texture LOD work a lot more predictably. - We now track last bind state for textures, and discard accordingly. We progressively discard based upon last bind time. - Avatar textures get a residency boost to stay loaded in VRAM longer under pressure.
…oser to the camera.
| auto iter = sTextureAllocs.find(texName); | ||
| if (iter != sTextureAllocs.end()) | ||
| { | ||
| iter->second += size; |
There was a problem hiding this comment.
I take it something substructs the old value? Where does it happen?
| desired_discard = llmin(desired_discard, getMaxDiscardLevel()); | ||
| // Clamp the fetch request to what the codestream encodes; deeper | ||
| // discards are served from the GL mip pyramid via scaleDown. | ||
| desired_discard = llmin(desired_discard, (S32)mCodecMaxDiscardLevel); |
There was a problem hiding this comment.
This might need to be conditional.
Ex: Some texture (profile icons) get intentionally requested at max resolution and then scaled down (icons) to a reasonable size. Some textures aren't JPEG2000 and don't discard well.
There was a problem hiding this comment.
Good point - and FWIW the discards now better relate to how they work on the GPU with mip levels and such. I'll go ahead and add some guard rails to make sure profile images and similar (like picks) don't get accidentally downrez'd.
New "high res" bubble near the camera, minimum discard settings, and discard scaling.
…ssure, halve last-ditch floor inside bubble.
…a configurable high water mark for VRAM.
|
Why is this reverting the J2C size calculations back to the previous "pre-aug 2024" method? Was there an issue with the updated method? Why is this action not described in the scope of the PR? |
|
@TommyTheTerrible So some of that might've been messing with some of the KDU code stream stuff which had a bit of a knock on effect in other parts of the texture pipeline. It's also not quite accurate to say that it reverts it - we just use a different code path for KDU vs. OpenJPEG now. |
I'm quoting your commit which states "Bring back the pre-aug 2024 byte estimation for j2c streams". Why would the amount of needed file loaded be different between the two decoders? What "knock on" effects are you alluding to? And if these effects are a problem then why is KDU still being supported when OpenJPEG works? I think this is going to cause KDU to under-decode textures again and then viewers using KDU will miraculously use less VRAM all of a sudden without telling users that all those 2k textures they are paying to upload are never being decoded fully in 2k on KDU viewers. |
|
RE: 2k textures - those still appear to work to me. And I do have quite the library to test with. And the knock on appears to be overallocation on the KDU end of things - I'm still profiling and validating various parts of this part of the pipeline. |
Alright, well it would be nice to have an explanation but I guess I don't deserve one. I wish you luck with your tinkering. |
3 participants
Reworks the texture streaming system for more consistent signal composition and better VRAM accounting.