Hey, I’m getting some blank Objects in Memory Profiler, Anyone knows about this or any idea how to identify those objects?
Hi,
These textures don’t have any references pointing to them anymore so I’d assume they’ll get unloaded by the next Resources.UnloadUnusedAssets call (or a destructive, i.e. non-additive scene load).
I’m not sure what would be a good way to identify them, other than maybe to catch them in an earlier snapshot while they still have a name and references to them and then identifying them in the diff view or by their instance id and/or address?
Also, in case you where taking Snapshots of Playmode or the Editor, these could have been the preview screenshots used by the Memory Profiler, or textures used by the Memory Map. See this post for more context.
FYI, the fix for this has just landed with the release of com.unity.memoryprofiler@0.2.6-preview.1 .
If you create any Texture2D objects without naming them, they will still appear without name in the snapshot though.
Negativ instances ID = it isn’t an asset so it was created at runtime.
If you are using any plugins dealing with textures or effects that you don’t have source code to, try disabling them. Besides that, use your IDE to find all instances of where you are creating a new Texture2D and there also give it a name.
Hopefully that helps provide context info for this
Specifically Graphics > <No Name> > <No Name> should usually be the same as Rendering::GfxDeviceClient, i.e. a graphics buffer allocated for usage by the Gfx Device Driver (OpenGL, Vulkan, Dx11, …) or returned to it’s pool after usage. We currently have situation where we might not “properly” set the device driver as the root for these allocations resulting in the “No Name” objects. We’re in the process of fixing that, but if you’re on 2022, I expect that’s the case and that means it won’t actually tell you much more about these. (If you are pre 2022 or latest patch versions it might also be some RenderTextures or CubemapArrays)
You might have to use XCode Instruments to analyze this deeper
Hey, Have you solved this problem?
For the Graphics > <No Name> > <No Name> case:
We fixed it on 6000.0.0b16 and backported it to 2022 where it landed on 2022.3.44f1, so you’ll need to update to at least that AND use the Memory Profiler at package version 1.1.1 or newer.
Hello, does this fix require that the capture be done on 2022.3.44f1, or is it expected to work so long as it’s opened in that version? I tried opening a capture done in 2022.3.16f1 in 2022.3.44f1 with Memory Profiler version 1.1.3, and I’m still seeing Graphics <No Name> <No Name> entries.
The opening version of the Editor has zero influence on the data in the snapshot.
The captured Player/Editor version defines the data available. The version of the Editor receiving the capture defines if it can serialize the data to file, or if it’ll either skip or hang/crash on it. The version of the package defines what part of the data it can read and how it will be processed.
So yes, you’ll need to recapture builds made with the version that has received the fixes.
I’m using Unity 2022.3.58 and Memory Profiler 1.1.1, and I did a new dev build, and I’m getting these texture3D objects. Each is 2.7mb (5.3 allocated size) and there are 64 of them – which is coincidentally the number of terrains we have in the scene. Are these a different kind of No Name texture than what was fixed?
Oh, and there are a lot more textures that are smaller (0.7mb) that I didn’t notice at first.
thx
Dave
If tried to clarify this a bit with edits and adjusting the resoling post to fix the original post better:
What’s been fixed recently is the case of Graphics > <No Name> > <No Name> entries in the All Of Memory table.
What’s not been fixed is Graphics > Texture2D > _ case, i.e. unnamed Texture assets. If your code creates textures at runtime using new Texture2D(/*...*/); or similar oath ways, it’s the responsibility of your code, or that of any (Editor) Extensions you use, to set its .name property to something sensible.
If it appears to be Unity’s own Terrain solution that’s creating these, then please file a bug report via Help > Report A Bug so it can be fixed for those cases explicitly.
I see, thanks! We’ll look into it.