How can Mali Offline Compiler estimate shader cycles when loop iteration count is known only at runtime via a uniform?

Hi,

I'm trying to use Mali Offline Compiler to build a more accurate runtime GPU workload estimation for our game.

I have a shader with a loop whose iteration count comes from a CPU-provided uniform/constant buffer, for example:

uniform int lightCount;

for (int i = 0; i < lightCount; ++i)
{
    ProcessLight(i);
}

For a specific draw call, the CPU knows the actual value, for example:

lightCount = 2

What I would like to estimate is the Mali Offline Compiler cycle cost for the original compiled shader executing this loop exactly twice, especially the per-functional-unit costs:

A / LS / V / T cycles

The problem is that Mali Offline Compiler does not know the runtime uniform value. For a uniform-controlled loop, the Longest Path Cycles can also be reported as N/A.

I tried replacing the runtime value with a compile-time constant, for example:

const int lightCount = 2;

However, this changes the compiler optimization. In my tests, the generated shader uses a different number of work registers, presumably due to optimizations such as loop unrolling, constant propagation, dead-code elimination, and different register allocation.

Therefore, the result from the specialized shader is not necessarily representative of the original shader executing with lightCount = 2 at runtime.

What I am looking for is something conceptually like:

Original compiled shader
        +
Known runtime uniform values
        ↓
Path-aware performance analysis
        ↓
A / LS / V / T cycles

without recompiling/specializing the shader in a way that changes its register usage or occupancy.

Is there any supported way to do this with Mali Offline Compiler?

In particular:

1. Can runtime uniform values be supplied to Mali Offline Compiler for performance analysis?
2. Is there an API, command-line option, or internal analysis mode that can evaluate a specific control-flow path using known runtime values?

3. Can Mali Offline Compiler expose cycle costs at a finer granularity, such as per basic block, loop body, or control-flow region?

   If so, we could keep the original compiled shader and calculate something like:

base cost
+ loop body cost × runtime iteration count
+ loop control overhead

4. If none of the above is currently supported, what would Arm recommend for estimating the cycle cost of a dynamic loop when the actual iteration count is known by the application at runtime?

Our goal is not necessarily to predict the final GPU execution time directly. We are mainly trying to estimate the shader-core workload in terms of the same A / LS / V / T cycle metrics reported by Mali Offline Compiler, while preserving the register usage and occupancy of the original shader.

Thanks!