Mali Graphics Debugger Memory statistics

In Mali Graphics Debugger there is view with pie chart called memory statistics with break down for different kinds of memory usage.

Where i can get good definition what each type means? especially interesting what framepool and frame internal means, (i`m aware of tiled rendering and that mali need to store some data until buffer swapped but why two kinds), also interesting what is unnamed and default heap, sounds completely uninformative.

Parents
  • Hi Dmytro, 

    > Where i can get good definition what each type means? especially interesting what framepool and frame internal means

    The framepool is storage for intermediate output from vertex shaders and the tiling process before fragment shading. Frame internal is "other memory related to the submission of a frame" - command queues, internal descriptor storage, etc.

    > also interesting what is unnamed and default heap, sounds completely uninformative.

    Indeed, it's quite uninformative sorry ;)

    This is one area where older drivers would have given you a better breakdown, because memory allocations were strongly typed by resource. When you allocated e.g. a texture it would always be a texture until it was freed. In drivers designed for a modern Vulkan-shaped world, memory allocation and memory usage are decoupled - the same memory can be aliased to different resource types by the application without being reallocated by the memory allocation layer in the driver. Unfortunately this means we lose the ability to track resource use by type, even for a GLES driver, because we use the same memory management backend for both.

    HTH, 
    Pete

Reply
  • Hi Dmytro, 

    > Where i can get good definition what each type means? especially interesting what framepool and frame internal means

    The framepool is storage for intermediate output from vertex shaders and the tiling process before fragment shading. Frame internal is "other memory related to the submission of a frame" - command queues, internal descriptor storage, etc.

    > also interesting what is unnamed and default heap, sounds completely uninformative.

    Indeed, it's quite uninformative sorry ;)

    This is one area where older drivers would have given you a better breakdown, because memory allocations were strongly typed by resource. When you allocated e.g. a texture it would always be a texture until it was freed. In drivers designed for a modern Vulkan-shaped world, memory allocation and memory usage are decoupled - the same memory can be aliased to different resource types by the application without being reallocated by the memory allocation layer in the driver. Unfortunately this means we lose the ability to track resource use by type, even for a GLES driver, because we use the same memory management backend for both.

    HTH, 
    Pete

Children