Unexpected texture memory results
donmccurdy opened this issue · comments
I'm loading these two textures one at a time in https://sandbox.babylonjs.com/ and trying to confirm the texture memory associated with each. It's the same texture in JPEG and KTX2 (UASTC) format, and I'd expected the memory use to be about 21 MB and 5 MB respectively.
When I run the SpectorJS profile and check the Information -> Total Memory -> Texture2D section, I'm seeing a bit larger number for the KTX2 texture (18MB), and nothing at all for the JPEG texture: total memory is not shown.
KTX2
Is this expected? I'm trying to help debug a larger application for a three.js user, and they're seeing higher memory reported with Basis UASTC which doesn't seem right, so I'm wondering if this could be related.
So if you drag them one after the other I am seeing:
or
Those numbers are representing the total amount of texture memory at some points in time.
the numbers are coming from here 97c992d and they are totally inaccurate for compressed textures I guess... I think it should only be the size of the buffer here ?
I'm seeing something a bit different but similar, starting with the KTX texture and then the JPEG. Possibly coming down to browser (Firefox) and hardware differences? I'm not sure whether mipmaps are generated.
- 12: 18087936
- 17: 13893632
I think you're correct that the size of the buffer is the right thing to show for compressed textures. I've written some code in gltf-transform to estimate memory from the source KTX2 file, but it makes assumptions about what the transcode target is going to be, whereas using the transcoded buffer size should be precise.
Yup, I ll try to fix it by end of week. Thanks for reporting it !!!
Ok with my current changes: #208 I can now see:
and
So which does looks better :-) could you confirm ?
That's in the ballpark I'd expect if it's saying 7.9 MB for Basis Universal UASTC and 16.3 MB for JPEG.
For KTX2 — do you happen to know if your hardware supports ASTC? If so, I'd have expected a somewhat lower number here. For anything else, transcoded size varies.
For JPEG — those numbers sound like you're assuming 3 bytes per pixel. I tend to estimate as if RGB will be expanded to RGBA in memory, based on donmccurdy/glTF-Transform#151 (comment). Not sure if that can be detected from JS; can't fault Spector.js one way or another if not. 😄
About KTX2 👍
For JPEG, is it only JPEG or any RGB texImage... calls which would expand ??? (this is so hardware dependant that I am wondering which one to pick, but knowing Spector is mostly a desktop usage maybe I should infer differently)
I would have guessed it was any RGB image, excluding compressed textures, but I don't really know. (/cc @lexaknyazev might?)
In any case, thanks for the quick fix here!
For JPEG, is it only JPEG or any RGB texImage... calls which would expand ???
Direct3D and Metal do not even support RGB8 pixels, so such textures are always expanded to RGBA8 when running WebGL on top of these platforms. The situation is slightly different with other APIs:
- On Vulkan, it's explicitly optional. So in case of WebGL, the translation layer does the expansion if needed.
- On OpenGL, it's hardware-dependent and happens silently in the driver.
Thanks a lot, I ll try to change it ASAP