General question about .metal file organization

For a complex app with lots of MSL shader functions and utility functions, it makes some sense to split things between multiple .metal files. If functions in one file need to refer to functions in other files, I assume we’ll need to have function declarations to resolve the external references. Does it make sense to put these in .h files (or some other suffix) that are seen only by the shaders (e.g. not bridged header files as for types shared between MSL and Swift)?

For example, let’s say I made a Utility.metal file that contained the missing mod function. Would it make sense to have a Utility.h?

I haven’t even tried this yet but I was hoping to hear if you recommended a best practice.

Thx,
~chuck

Yes it does make sense to have multiple Metal files.

For common functions, I’ve done exactly what you said with a Utility.metal file.

I put the code in the .metal file (with the usual <metal_stdlib> include and metal namespace).

This metal file had several functions dependent on each other. Then I created a Utility.h file with the header for just the one top function.

Then I imported Utility.h wherever I needed the function.

You do have to be careful with relative paths.