The result cooked for iOS Platform on Windows be used on iOS without problems?

Development Platform & Builds
, ,
1

UE Version : 5.3.2

Metal Developer Tool : 4.1

​

We are attempting Remote iOS Cooking from Win64.

In UE 5.3, aside from applying the following commit:

https://github.com/EpicGames/UnrealEngine/commit/08ecd19aad7b6c903d9d4af2939190e47afb3dff

In addition to this, we have verified Metal library operation through a few cherry-picks.

The results cooked on Windows and iOS are different.

As we investigated the reason, we found the following code:

cpp
#if PLATFORM_CPU_ARM_FAMILY
	// Separate out arm keys as x64 and arm64 clang do not generate the same data for a given
	// input. Add the arm specifically so that a) we avoid rebuilding the current DDC and
	// b) we can remove it once we get arm64 to be consistent.
	KeySuffix.Append(TEXT("_arm64"));
#endif

It says that results generated by arm64 and x64 are different.

In that case, can the result cooked for iOS Platform on Windows be used on iOS without problems?

From which version of Metal Developer Tools is the Metal library generated on Windows stable to use?

There are some posts saying that using Remote Cook up to live game deployment in 5.3 is not complete, so I’m asking.

​

Let me know if you’d like help sending it as a support ticket or email.

​

------------------------------------------------------------------------------------------------------------------------------

[Content removed]

[Content removed]

[Content removed]

2

재현 방법

3

Hi eunbi,

Yes, cooked data iOS Data from a Win64 host should be usable without issue.

Best regards.

4

Then, what is the reason for the comment that the generated outputs differ between arm64 and x64, and for the suffix in the DDC key?

Is it simply to distinguish where the content was cooked?

5

Correct, that just differentiates the cooking host architecture.

Best regards.

6

I have an additional question.

When cooking on Windows, the “.metallib” file isn’t generated, and the shaderbytecode is embedded directly into the pak file.

But the app still runs fine.

I’m wondering if this is an issue or not.

Since we’re using Unreal Engine 5.3, it seems the Windows Metal library path may not be applied correctly.

Is it safe to run the app on iOS without the .metallib file?

7

Hi Eunbi,

Under 5.3, I don’t believe the app would run properly without the .metallib files in the .app root. Is this what you’re observing?

Best regards.

8

We have two types of paks: StartPak and PatchPak.

StartPak is generated on macOS, so it contains the metallib, while PatchPak is generated on Windows, so it doesn’t include metallib pak.

(The reason we generate PatchPak on Windows is due to memory limitations.)

If PatchPak were also generated on macOS, it would add another 900MB metallib pak.

And metallib in StartPak is about 25MB.

In our current test, we ran the game with the embedded as shader bytecode inside the PatchPak without 900MB metallib pak.

What kind of issues could arise in this case?

9

Hi Eunbi,

There is no issue with compatibility between Windows and Mac however, there can be slight byte code differences that would affect patches sizes etc. This is why we append to the keysuffix. If you are only building your patch data only on windows then you would not see any issues. We are planning a fix for the next release (5.8) which removes the requirement for this extra suffix.

Can you confirm that on WIndows you have the toolchain installed and that CanCompileBinaryShaders is returning true?

Thanks,

Carl