The Graphics > <No Name> bug is fixed if you update to the latest release of the package and the latest patch release of the major version of the engine that you’re on. But that only fixed the rooting of those resources to the Graphics Driver who retains some formerly allocated resources as buffers for reuse.
Since you’re not comparing the first re-entry to the main menu scene to the second one, your Graphics memory doesn’t actually increase between these. It increases once by 16 MB which is then retained as a buffer, reused on entering the gameplay scene again, and then retained as reusable buffer on entering the main menu scene a second time. So that’s totally fine and not a leak at all.
That graphics memory is what our engine code submitted to the Graphics Driver/Graphics API (i.e. Vulkan, OpenGL, DirectX, Metal etc.). The every time we submit something, we keep a shadow copy of the resource we asked it to create for us and we update and delete that shadow copy when we make changes to that requested resource. We don’t actually HAVE an address for that resource because it is fully handled by the GFX Driver and not our Memory Manager. The number you see in the UI is an artificial resource ID that we use to identify that resource with and that’s linked to e.g. a Texture and the graphics memory shadow copy.
Now all of that of RAM memory, not VRAM, as on non-unified memory platforms the GPU might have to handle drawing other things than your game and would have to purge VRAM e.g. when you tab out to the OS or a different app, or it might have to swap resources in and out of VRAM as needed each frame (a performance issue that a GPU Vendor’s Profiling tool can help you analyze if you ever have to, as our profiling tools don’t have the insight into this to surface data coming from that low a level in the driver and/or GPU).
Now that shadow copy system works for allocations we explicitly asked the driver to make for us. That doesn’t keep the driver from making other allocations that our Memory Manager doesn’t even know about via such a shadow copy. That memory ends up as untracked. To analyze that you’d have to use a native platform profiler like WPA on windows, see this post.
I’d assume it’s further graphics buffers and that the growth there will taper off after a few cycles. Unless you have any plug-ins that allocate native memory without using the IUnityMemoryManager plugin Interface, which afaik FMod doesn’t. Or .net plugins or C# code using Marshall.AllocHGlobal