• State Accepted Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 10 replies
  • Subscribers 137 subscribers
  • Views 3701 views
  • Users 0 members are here
Options
Related
How was your experience today?
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

mali offline compiler cannot find entry point for vulkan fragment shader

whoareyou

The fragment shader only has one function:

And I have tried to use the mali offline compier by following commands:

-n <NAME>, --name <NAME>
Name the program entrypoint.

The malioc.exe tells me to use -n or --name, I have tried both, all without luck.

Can someone kindly points out what's going wrong? Thanks!

Parents Reply Children
  • +1 Arm Employee Badge in reply to whoareyou

    I'm not sure what I actually compiled last night, but I can confirm it doesn't work =)

    We use glslangValidator for our GLSL to SPIR-V compilation, which strictly adheres to the Khronos specifications. For GLSL the entry point must be "void main()" - alternative names are out-of-spec. The shader in this case is trying to use "void main_00000000_00000000()" as the entry point which is incorrect and not accepted by glslangValidator, but accepted by some other front-ends such as DXC.

    For this particular case, you can work around this issue with the preprocessor. However, this can be a little fragile in the general case as any instance of the string will get replaced, not just the entry point name.

        malioc --vulkan -D main_00000000_00000000=main vulkan.frag

    We will implement this workaround for Vulkan source compiles that set --name for a future offline compiler release.

  • 0 in reply to Peter Harris

    Thanks, Peter! This workaround works great for me. Now I can use the mali offline compiler to analysis the vulkan shader.

  • 0 in reply to whoareyou

    btw it seems the UE4 also use the glslangValidator to compile the GLSL to SPIR-V.
    As far as I know, it will first use hlslcc to translate HLSL code to GLSL code, then use glslang to compile the GLSL to SPIR-V.

    I just verified that when generate the shader from material, it's not using dxc but hlslcc and glslang.

  • 0 Arm Employee Badge in reply to whoareyou

    Thanks for checking. 

    It's possible to override some of the syntax and semantic checks in glslangValidator by passing in the "-s" command line option, so it's quite possible that UE is using glslangValidator in a more relaxed mode. We don't do this by default as you get in to the realms of implementation-defined behavior.  

  • +1 Arm Employee Badge in reply to Peter Harris

    To confirm - we've implement a workaround for cases where Vulkan source shaders use a custom "--name" and this will ship in the Arm Mobile Studio 2022.3 release due ~end of August.

    Thanks again for the bug report - it's very useful for us to get these.

    Kind regards, 
    Pete

  • 0 in reply to Peter Harris

    Great! Thanks for your quick response!

  • 0 Arm Employee Badge in reply to whoareyou

    Mobile Studio 2022.3 is now available with the ability to set a custom name.