Skip to content

Fix macOS runner lightmap and metal issues #1264

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jun 6, 2025
Merged

Fix macOS runner lightmap and metal issues #1264

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions analytics/testapp/Assets/Firebase/Sample/Analytics/MainScene.unity
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -50,8 +50,8 @@ LightmapSettings:
m_AlbedoBoost: 1
m_TemporalCoherenceThreshold: 1
m_EnvironmentLightingMode: 0
m_EnableBakedLightmaps: 0
m_EnableRealtimeLightmaps: 0
m_EnableBakedLightmaps: 1
m_EnableRealtimeLightmaps: 1
Comment on lines +53 to +54
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

critical

The PR description states the goal is to "consistently not bake the lightmaps" to avoid GHA runner timeouts. However, these changes from 0 to 1 for m_EnableBakedLightmaps and m_EnableRealtimeLightmaps seem to enable these lightmap features.

Could you clarify the reasoning behind enabling these? If the intent is to prevent any lightmap baking or processing that could cause timeouts (as suggested by the linked Unity issue https://issuetracker.unity3d.com/issues/unable-to-fall-back-to-cpu-lightmapper-dot-errors-in-the-console-when-opening-a-project-on-a-virtual-machine), shouldn't these values be 0 to explicitly disable baked and realtime lightmaps for this scene?

    m_EnableBakedLightmaps: 0
    m_EnableRealtimeLightmaps: 0

m_LightmapEditorSettings:
serializedVersion: 4
m_Resolution: 2
Expand Down
2 changes: 1 addition & 1 deletion analytics/testapp/Assets/Firebase/Sample/Analytics/MainSceneAutomated.unity
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -42,7 +42,7 @@ RenderSettings:
LightmapSettings:
m_ObjectHideFlags: 0
serializedVersion: 7
m_GIWorkflowMode: 0
m_GIWorkflowMode: 1
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

high

Changing m_GIWorkflowMode from 0 (Baked Indirect) to 1 (Realtime GI) correctly avoids the pre-baking of lightmaps, aligning with the PR's goal.

However, Realtime GI still involves significant lighting computations and might interact with the lightmapping system on the macOS GHA runners. Given the linked Unity issue (https://issuetracker.unity3d.com/issues/unable-to-fall-back-to-cpu-lightmapper-dot-errors-in-the-console-when-opening-a-project-on-a-virtual-machine) points to problems with the lightmapper itself on VMs, is switching to Realtime GI sufficient to prevent timeouts?

For testapps, which often don't require complex lighting, would it be more robust to consider completely disabling Global Illumination features (e.g., by ensuring m_EnableBakedLightmaps: 0, m_EnableRealtimeLightmaps: 0, and potentially adjusting m_GIWorkflowMode accordingly, perhaps to 0 if all GI is off) to minimize any interaction with the lightmapper?

m_GISettings:
serializedVersion: 2
m_BounceScale: 1
Expand Down
2 changes: 1 addition & 1 deletion analytics/testapp/ProjectSettings/ProjectSettings.asset
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -229,7 +229,7 @@ PlayerSettings:
macOSURLSchemes: []
iOSBackgroundModes: 0
iOSMetalForceHardShadows: 0
metalEditorSupport: 0
metalEditorSupport: 1
metalAPIValidation: 1
iOSRenderExtraFrameOnPause: 1
iosCopyPluginsCodeInsteadOfSymlink: 0
Expand Down
2 changes: 1 addition & 1 deletion auth/testapp/ProjectSettings/ProjectSettings.asset
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -229,7 +229,7 @@ PlayerSettings:
macOSURLSchemes: []
iOSBackgroundModes: 0
iOSMetalForceHardShadows: 0
metalEditorSupport: 0
metalEditorSupport: 1
metalAPIValidation: 1
iOSRenderExtraFrameOnPause: 1
iosCopyPluginsCodeInsteadOfSymlink: 0
Expand Down
2 changes: 1 addition & 1 deletion crashlytics/testapp/Assets/Firebase/Sample/Crashlytics/MainSceneAutomated.unity
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -42,7 +42,7 @@ RenderSettings:
LightmapSettings:
m_ObjectHideFlags: 0
serializedVersion: 7
m_GIWorkflowMode: 0
m_GIWorkflowMode: 1
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

high

Similar to the comment on analytics/testapp/Assets/Firebase/Sample/Analytics/MainSceneAutomated.unity:

Changing m_GIWorkflowMode from 0 (Baked Indirect) to 1 (Realtime GI) avoids pre-baking. However, could Realtime GI still trigger issues on the macOS GHA runners due to the underlying lightmapper problems on VMs (as per the linked Unity issue)?

If these testapps don't strictly need dynamic global illumination, would completely disabling GI (e.g., m_EnableBakedLightmaps: 0, m_EnableRealtimeLightmaps: 0) be a safer approach to ensure stability on the runners?

m_GISettings:
serializedVersion: 2
m_BounceScale: 1
Expand Down
2 changes: 1 addition & 1 deletion crashlytics/testapp/ProjectSettings/ProjectSettings.asset
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -229,7 +229,7 @@ PlayerSettings:
macOSURLSchemes: []
iOSBackgroundModes: 0
iOSMetalForceHardShadows: 0
metalEditorSupport: 0
metalEditorSupport: 1
metalAPIValidation: 1
iOSRenderExtraFrameOnPause: 1
iosCopyPluginsCodeInsteadOfSymlink: 0
Expand Down
2 changes: 1 addition & 1 deletion database/testapp/ProjectSettings/ProjectSettings.asset
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -229,7 +229,7 @@ PlayerSettings:
macOSURLSchemes: []
iOSBackgroundModes: 0
iOSMetalForceHardShadows: 0
metalEditorSupport: 0
metalEditorSupport: 1
metalAPIValidation: 1
iOSRenderExtraFrameOnPause: 1
iosCopyPluginsCodeInsteadOfSymlink: 0
Expand Down
2 changes: 1 addition & 1 deletion dynamic_links/testapp/ProjectSettings/ProjectSettings.asset
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -229,7 +229,7 @@ PlayerSettings:
macOSURLSchemes: []
iOSBackgroundModes: 0
iOSMetalForceHardShadows: 0
metalEditorSupport: 0
metalEditorSupport: 1
metalAPIValidation: 1
iOSRenderExtraFrameOnPause: 1
iosCopyPluginsCodeInsteadOfSymlink: 0
Expand Down
2 changes: 1 addition & 1 deletion functions/testapp/ProjectSettings/ProjectSettings.asset
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -229,7 +229,7 @@ PlayerSettings:
macOSURLSchemes: []
iOSBackgroundModes: 0
iOSMetalForceHardShadows: 0
metalEditorSupport: 0
metalEditorSupport: 1
metalAPIValidation: 1
iOSRenderExtraFrameOnPause: 1
iosCopyPluginsCodeInsteadOfSymlink: 0
Expand Down
2 changes: 1 addition & 1 deletion scripts/gha/integration_testing/MenuScene/Menu.unity
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -43,7 +43,7 @@ RenderSettings:
LightmapSettings:
m_ObjectHideFlags: 0
serializedVersion: 9
m_GIWorkflowMode: 0
m_GIWorkflowMode: 1
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

high

Similar to comments on other scenes changing m_GIWorkflowMode:

This change to m_GIWorkflowMode: 1 (Realtime GI) avoids pre-baking lightmaps. However, considering the context of macOS GHA runner timeouts and the linked Unity issue regarding lightmapper problems on VMs, is Realtime GI guaranteed to be stable?

If this menu scene doesn't require dynamic global illumination, would it be more robust to ensure all GI features are disabled (e.g., m_EnableBakedLightmaps: 0, m_EnableRealtimeLightmaps: 0) to prevent any lightmapper invocation?

m_GISettings:
serializedVersion: 2
m_BounceScale: 1
Expand Down
Loading