Reporting back, I have converted all files to dds (with TextureWriter though, not TexConvGui, as it would need to be an automated process in the end and this was faster for a quick test), but that didn’t seem to give me much of a boost.
Sampling some FileTexture.IsLoading timings in a stopwatch + queue gave me this comparison for the first few textures. While it might pile up to something noticeable and I might make use of it in the end, I would like to focus on other things first.
Careful, wall of text ahead - just taking notes on my findings here so it can help others or I can be corrected/educated ;)
FileTexture
Is there a way to force the stride asset pipeline to unload textures once seen?
Stepping through a directory with all files one by one will eventually fill up my 12GB as it holds on to them, making a second loading time super fast - which is a nice thing in general.
But now I’m wondering if this can be prevented or if I can target specific assets to be cleared from the cache if I want to (something like AssetItem.Unload())?
Maybe that’s also not even needed, I don’t care if too many stay in memory … but here I would have more questions:
- Will a full gpu memory be ok in this case as the memory is managed by Stride and I can rely on it to free up ressources when needed? (When loading textures manually from a Directory per Bang IOBox, looking at GPU-Z, around 11640MB it stop increasing in memory but the FileTexture loading times of new textures remain within the same range as before the memory wasn’t full)
- Will a full gpu memory also not impair performance somewhere else?
- If the above are both fine, will that also remain true if not another Stride asset is requesting to be loaded into memory, but some other process (maybe even outside of vvvv) needs more memory, will I not run into errors then or even run into exceptions related to the full memory?
- As the above things to some degree only revolve around the fact that Stride just keeps using up memory, can this be limited?
- Not sure if it’s the same as 4, but is this currently making use of Streaming | Stride (stride3d.net)? If so, one could probably lower the available streaming memory pool. But looking at the TextureAssetFromFile inside of the FileTexture, it has IsStreamable hardcoded to false … so probably the memory is not managed somehow. I can keep loading textures though (see 1) and it will remain around the same level when it’s nearly full.
- Once the memory is full but textures get loaded without any issues, I can only assume that Stride unloads previously seen textures. By which logic would that happen? Any random texture not on display at the time? I would have expected ListAssets to report on that, but both “Loaded Asset Items” and “Requested Assets” keep increasing whenever I load the next texture.
Edit: Just found ContentManager.Unload(), but haven’t looked at it yet. Also, before making use of that, I would need to understand if it’s actually necessary or everything just works fine as is …
TextureReader
Not really questions here, just documenting my thoughts.
As I don’t understand everything that is happening in Stride when making use of the FileTexture, I wanted to also explore this option. As I don’t have a 3D scene, I don’t need MipMaps anyway … right now everything is just slightly off its display size, but that could be optimized if really needed.
This seems to work as expected, there are only the things in memory I want and it’s easier to keep track of what is happening.
One thing noteworthy is though (and now that I know it also makes sense), that in order to free up ressources the TextureReader will need to remain updated with just the filenames you want to keep. When having the TextureReader as part of an operation and just not calling that operation anymore, it will not work:
But on the upside this will also only load everything just once, even from different places in the patch, as the internal NewPooled region will return the handle to the very same ressource as long as the filepaths remain the same.
Conclusion
Wondering if the FileTexture also just works and the gpu memory being on the edge wouldn’t turn out to be an issue, but I somehow don’t trust it being so close to the device limit …
Is there any way to make the FileTexture also work around the Stride asset pipeline, so it behaves more like the TextureReader / FileTexture in Beta? This way we could keep some of its features without running into the other “issues” (if they even are issues to begin with …).
For my use case, I guess the TextureReader will be fine.
(Edit: loading all filetextures at once seems to be fine, even if it exceeds the vram … I have quite a lot of more followup questions, trying to figure out whether what I’m observing is something the drivers understand, or Stride does for you, or Stride does for you but needs you to keep the FileTextures around for the intelligent management (or if I’d have the same seamless experience when storing all textures in a dictionary at once, omitting all FileTextures across the patch … I guess I just have a limited understanding of what’s going on here.)
