[1431] Estimated memory usage appears to show pre-crunch-decompression size
tracked
bd_
When a texture is compressed using crunch compression, the new estimated memory usage field in the avatar stats shows the crunched size, not the actual size in memory after crunch decompression. This is not ideal, as it will encourage users to juice these numbers by crunch-compressing textures, when this doesn't actually help memory usage, and makes load hitching worse.
As a concrete example, this avatar shows a texture memory of 10.67 MB, but an estimates memory usage of 0.48 MB. The avatar contains a single 4k all-white texture that has been crunch-compressed. https://vrchat.com/home/avatar/avtr_ef3447a0-5fea-4a7d-aa5d-d4d9a75aeb74
Log In
_
_tau_
tracked
＃かなたん
If they release crunch-compressed items without treating them at their decompressed size, wouldn't it make no sense at all to provide a separate limit on download size?
As a user who has been waiting for a limit on VRAM usage, I cannot welcome it...
＃かなたん
We just hope that the newly added "Uncompressed size" will be calculated correctly using the decompressed size for crunch-compressed textures as well.
That's all we want.
lilxyzw
Thank you for providing a workaround for the limitation! I'm going to recommend Crunch Compression to a friend who wants to reduce memory size!
...This is a joke, but users will think so if it is released to live with this specification.
Sayamame
If OpenBeta(1434) is released to Live without fixing this problem, the use of Crunch compression may be encouraged among users, starting with users who observed how the value of Uncompressed Size changes, and this is really not good.
bd_
There were some comments in VRCPrefabs suggesting that crunched textures might not be resident in main memory. After doing some investigation, I can confirm that there are cases where crunched textures are decompressed into main memory - in particular, I was able to access the native color data via GetPixelData in a standalone Unity application. When I did this, the buffer was not visible on the Unity memory profiler (or perhaps counted to graphics memory) so it’s difficult to confirm if this is always the case or only when requested.
AirGamer
bd_ iirc, the default import settings for textures is Read/Write disabled, implying that no copy in main memory would be kept.
At least in the unity editor, I got an exception when using GetPixelData on a texture that was not read/write enabled (or otherwise IsReadable)
Did you test with a texture that is read/write enabled?
AirGamer
"and makes load hitching worse" I was under the impression that crunching made virtually no difference? Is there performance testing on this?
bd_
AirGamer This was based on some comments by tupper re: crunch requiring more resources in load, but I’ve not benchmarked this in detail myself (and, looking back, it’s not clear if he meant to refer to hitching or just cpu consumption in general)
Tupper - VRChat Head of Community
bd_: Anecdotally, I've definitely noted hitching in extreme use cases of Crunch. But it's anecdotal -- I haven't benchmarked. I might be totally wrong.
DarkSwordsman
AirGamer There's two separate things:
- Bundle Compression
- Crunch Compression
This isn't based 100% on fact because we don't have access to the Unity source code, but based on feel/testing/docs:
- Texture gets crunched.
- Bundle compression (LZMA)
- Bundle decompresses on download
- Crunch textures converted to VRAM-compatible textures
To my knowledge: normal DXT1/5 and BC7 (i.e: "Texture Formats") are already in a format the GPU can read from VRAM as soon as the bundle decompresses. However, "Crunch" textures can't be accessed directly by the GPU, so it has to convert it to normal texture formats. Hence the "Crunch doesn't affect VRAM" thing we know.
You can think of it similar to a monitor needing a special high-bandwidth cable (HDMI/DP). It's why monitors don't need any extra processors or chips, just a basic display controller to draw to the pixels. The conversion of JPG, PNG, UI elements, etc. are all done earlier in the chain by the GPU and CPU, and all the monitor gets is a raw RGB feed (excluding Display Stream Compression, a technology that has a similar goal to to how texture formats work).
AirGamer
DarkSwordsman I'm aware that crunched textures required an extra decompression step
I'm also aware that Crunch Compression + Bundle Compression achieves a better then just a Bundle Compressed texture
What I however don't know is;
Is the cost of uncrunching a texture significant?
Assuming a smaller bundle will unpack faster, does that counter the extra uncrunch cost?
Is the uncrunching done in a way that makes it more likely to cause hitching (i.e. is uncrunching performed on the main thread? and is bundle decompression done on another thread?)
DarkSwordsman
AirGamer the entire process of converting it into the correct texture is what causes the hitching. It's primarily when people have a lot of textures. Even if there was no hitching, no one can actually really recommend crunch compression because it barely reduces download size and does not reduce VRAM usage. So all you are doing by using crunch is reducing the quality of your textures because it's fun.
AirGamer
DarkSwordsman You can achieve significant download savings with crunch compression, a topic that was discussed to great degree when it was brought up in one of the developer blogs comments.
Re hitching, have you performance tested this yourself? do you have side by side comparisons or hard numbers?
DarkSwordsman
AirGamer I have not done vacuumed tests myself, but have done observations based on experience with certain avatars, and trust the word of others who have done tests.
Yes, it "can", but the cases where it "can" are slim, and savings are negligible in comparison to the quality loss, possible hitching, and the fact that it does not change VRAM size. For example, I do not use crunch compression and my Texture Memory is about 45 MB for a specific avatar, but the download is only 7 MB. There is no point for me to use Crunch.
If you are at the point where crunch compression may have a notable impact on download size, you are probably destroying your textures and/or already have way too much texture memory usage. Also, instead of using crunch compression, you could just drop the resolution 1 step and use DXT1/BC7. Actual quality is more important than resolution in most cases.
AirGamer
DarkSwordsman "certain avatars"
Are you sure that crunch compression was a common feature of all those avatars?
Are you sure that crunch compression was absent in similar complexity avatars that didn't hitch?
Are you sure that those hitching avatars don't share a different aspect that might be causing the hitching, and you are misidentifying the cause?
"cases where it "can" are slim" More often then not it's given me a noticeable reduction.
"instead of using crunch compression, you could just drop resolution 1 step and use DXT1/BC7." Doesn't always give you better quality.
The last two points are, however, tangential to my request for more substantial evidence of that crunch is a common cause of hitching.
I'm pretty sure I've seen hitching due to complex shaders, variables like that need to be eliminated/controlled to get clear confirmation one way of the other
Edit: and continuing the discussion of if crunch is worthwhile is just repeating the discussion that was in https://ask.vrchat.com/t/developer-update-16-march-2023/16950 and was not what was asked here
DarkSwordsman
AirGamer To our knowledge, crunch causes lag spikes because it needs to be converted on decompression.
Whether it does or not, I don't think it matters, because crunch drastically reduces quality for a generally negligible bundle size reduction. That's all we have.
So no, to my knowledge, no one has done extensive testing. It's been all anecdotal. But people I trust to have good knowledge and testing of things have said the same things, and the logic makes sense, so I believe it, especially since there is virtually no reason to actually use crunch, even if it didn't cause lag spikes on avatar load.
At the end of the day: NEVER use crunch compression unless you have a very, very specific reason to.
AirGamer
DarkSwordsman "To our knowledge, crunch causes lag spikes" I'm asking for numbers, proof, what is the foundation for this knowledge
You can't keep reiterating this as fact and ignoring my request provide the backing information.
Anecdotally, I've seen people lag loading avatars that do not appear to be crunch compressed at all.
Crunch compression can and has (for me) outperformed dropping the resolution. You shouldn't wholesale advising against it. it is another tool for download optimisation.
I also see that you have also ignored my hint to stop derailing away from the original topic of my question, just stop it.
If you aren't going to respond with actual performance data, and instead waste our time arguing trying to against the use of crunch compression, then don't bother.
bd_
As a concrete recommendation for improvement: It appears that these servers are calculated on the server side (since the estimated memory usage doesn't appear on local test avatars). If it's difficult to determine the uncrunched size based on server side analysis for whatever reason, if would be good to recalculate them on the client side as well based on decompressed texture memory, just to avoid creating an incentive to crunch things unnecessarily.
bd_
Perf stats for that test avatar
