This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Load/Store Unit and 16-bit arithmetic from mali oc are not as expected

I profiled my shaders, but i found the Load/Store Unit value is extremely large. Therefore, I tried to simplify the shader and run some tests.

Environment:  Mali-G715,  glslc in the latest Vulkan SDK .
#version 450
#define LENGTH  512 // 1024

layout(set = 0, binding = 0, std140) mediump uniform ubo0 {
mediump vec4 data[LENGTH];
} _ubo0;

layout(set = 0, binding = 1, std140) mediump uniform ubo1 {
mediump vec4 data[LENGTH];
} _ubo1;

layout(location = 0) out mediump vec4 outColor;

void main() 
{
    outColor = vec4(0);
    for(int i = 0; i < LENGTH; i++)
    {
        outColor+= _ubo0.data[i];
    }
    
    //for(int i = 0; i < LENGTH; i++)
    //{
    //    outColor+= _ubo1.data[i];
    //}
}

void confusedMain() 
{
    outColor = vec4(0);
    for(int i = 0; i < LENGTH; i++)
    {
        outColor+= _ubo0.data[i];
        outColor+= _ubo1.data[i];
    }
}
The profile result:
Uniform Count Per Unifrom Length LS 16-bit arithmetic Uniform Register Function
1 512 0.00 N/A 2 (3% used) main
1 1024 2.00 0.0 2 (3% used) main
2 512 0.0 N/A 2 (3% used) main
2 1024 4.00 0.0 2 (3% used) main
2 512 4.00 0.0 2 (3% used) confusedMain

The results seem to indicate that the LS value is related to the size of the UBO. However, when I tried the following code, the results confused me.

So I have some questions about the result above.

Q1: Does the size of the UBO really affect LS? Could it be that there is a special cache inside the chip, but due to the limited cache size, a large UBO increases LS?

Q2: Why different UBO size have different 16-bit arithmetic result?

Q3: Why did different calculation orders produce different results in the example above?

Q4: Why does the UBO size affect 16-bit arithmetic?

Parents
  • Correct, all float texture coords get promoted to highp. Decent linear filtering needs 8 bits of subtexel precision at after any wrapping has been applied, so fp16 is almost never usable.

    Integer coords don't need subtexel precision, as there is no filtering, so texelFetch is fine.

Reply
  • Correct, all float texture coords get promoted to highp. Decent linear filtering needs 8 bits of subtexel precision at after any wrapping has been applied, so fp16 is almost never usable.

    Integer coords don't need subtexel precision, as there is no filtering, so texelFetch is fine.

Children