macOS ARM (macos-14) has rendering issues with lines and texture when using OpenGL

[mwestphal]

Description

I'm the co-creator of F3D, a fast an minimalist cross platform 3D viewer. We have been supporting macOS ARM using cross-compilation for a while but we recently switched to using macos-14 runner instead.

So far it has been behaving great we do have one issue that seems to be caused by the runner images themselves.

Indeed, we struggle to render certain specific part of our models, it very much looks like a driver bug in the OpenGL stack. We do not reproduce on any actual macOS ARM, these issues are specific to macos-14 ARM images on github.

Platforms affected

• [ ] Azure DevOps
• [X] GitHub Actions - Standard Runners
• [ ] GitHub Actions - Larger Runners

Runner images affected

• [ ] Ubuntu 20.04
• [ ] Ubuntu 22.04
• [ ] macOS 11
• [ ] macOS 12
• [ ] macOS 13
• [ ] macOS 13 Arm64
• [ ] macOS 14
• [X] macOS 14 Arm64
• [ ] Windows Server 2019
• [ ] Windows Server 2022

Image version and build link

20240415.6

Is it regression?

No

Expected behavior

Correct rendering like this:

Actual behavior

Test	Result	Diff
TestConfigStemBuild
TestDXF
TestGridX
TestGridZ

Are you can see, certain lines and texture are incorrectly rendered.

Repro steps

Create a PR on F3D but in .github/actions/generic-ci/action.yml:210, remove the -E ctest argument to run all the tests instead of excluding the one that do not render correctly.

[Alexey-Ayupov]

Hello @mwestphal, we will take a look what we can do about it.

[mwestphal]

Thanks! Please let me know if I can help or test anything on my side.

[kintel]

We see a very similar issue with OpenSCAD:

Example of issue:

[kintel]

I ran some tests in an UTM VM with a macOS-14 guest on a macOS-13 host, and I see similar issues, so this might be an upstream OpenGL issue. The GL version is the same as on the GitHub macos-14 runner:

OpenGL Version: 2.1 APPLE-21.0.19 (Apple Software Renderer)

[kintel]

I also managed to reproduce this in an UTM VM with macOS-13.6.6 on a macOS-13 host:

OpenGL Version: 2.1 APPLE-20.5.2 (Apple Software Renderer)

This is the same OS version and renderer version as used on GitHub's macos-13 runner, except I'm running on arm64 while GitHub runs on x86_64. The x86_64 version works fine and does not exhibit this issue.

The red thread seems to be that Apple's software renderer on arm64 has issues. It not clear if it's possible to fix this through VM configuration or not.

[kintel]

..and finally: Running the Apple Software Renderer directly on a macOS-13 M1 host also fails:

OpenGL Version: 2.1 APPLE-20.5.2 (Apple Software Renderer)

This last piece of info takes the VM out of the equation.

[mwestphal]

..and finally: Running the Apple Software Renderer directly on a macOS-13 M1 host also fails:

OpenGL Version: 2.1 APPLE-20.5.2 (Apple Software Renderer)

This last piece of info takes the VM out of the equation.

So that means this is not fixable because it is a bug in the software rendering stack on macos ?

[kintel]

So that means this is not fixable because it is a bug in the software rendering stack on macos ?

There may still exist workarounds. I haven't experimented with GL context settings to see if the bug only manifests through certain pixel format configurations. I also haven't tried any newer (if they exist) renderers than 21.0.19.

I can only reproduce this bug in relatively complex scenarios. We have more than 1500 tests, and only 41 of them fail, so there may be some specific GL usage which triggers this issue, and it might be possible to avoid that GL usage by rewriting code (or using slightly different code for testing on macOS).

If you manage to reproduce this with a minimal example, that could be interesting to look into more closely and/or find some paying Apple developer who can engage with Apple on the topic.

[sureshe456]

@mwestphal, We conducted tests in a UTM VM using a macOS-14 guest on a macOS-13 host, and we observed similar issues. please submit the report to Apple.we are closing this issue from our end.Thanks.

[mwestphal]

I'm afraid I wont be submitting anything to apple as I would not know where to start nor do I care enough. Thanks for checking as you did though, at least we know where its coming from. Maybe someone will find some kind of work around.

[kintel]

I guess we wait until a paying Apple customer is hit by this and can engage with Apple. I had hoped GitHub could do that as this affects a bunch of GitHub customers. Luckily, GitHub Actions still has x86 runners, so it's not yet critical.

Once the x86 runners become decommissioned we'll have to either migrate off GitHub Actions or find another solution. The only workaround I can think about right now is to replace Apple's SW renderer with Mesa, but I haven't looked into what it would take to get that working. I'm afraid it will be pretty messy :(