Cycles Metal device #92212

New Issue

Tasks

For tracking Metal device development, targeting 3.1 release:

Kernel changes required to compile for MSL (Metal Shading Language):
- Explicit address space qualifiers
- Adapt cross-platform layer (device/gpu) for MSL
- MetalRT kernel changes
Host changes:
- Support specification of explicit dispatch argument types
- Add core Metal implmentation (device_impl, device_queue, etc)
- Min OS / device version checks
Buildbot changes
- Upgrade Xcode on buildbot machines to macOS 12.0 SDK
  - Arm
  - Intel
Regression tests (CYCLES_TEST_DEVICES=CPU;METAL)
- Enable on Arm buildbot, with just a single test to verify the basic kernel works
- Fix broken tests
  - Bake tests have empty output
  - Missing shadows(?) in many volume tests
  - Missing point cloud support (D13632)
  - Ambient occlusion only local fails
- Enable running of all tests on the buildbot
MetalRT regression test failures
- Point clouds
- Ambient occlusion only local
- Crash rendering 3D hair curves (ribbons are ok)
- Misc other failures
  - hair transmission
  - openvdb smoke
  - shadow catcher pt transparent lamp only 1.0
  - visibility particles
Hardware support
- Apple Silicon
- AMD
- Intel (requires buildbot update to macOS 13, see D16253)

Performance - see #101931

Metal GPU Cycles Implementation

Overview of initial steps taken to get the implementation working.

There are two broad phases to enabling the Metal GPU implementation of Cycles:

Adapting the kernel code so that it can be compiled under MSL (Metal Shading Language)
Adding the new Metal host-side device

The kernel code changes represent the largest chunk of work, in terms of interaction with existing implementations. MSL is closely based on C++14, therefore much of the kernel code already compiles by default. Here we describe the remaining steps required to fully compile kernels with MSL:

Explicit address space qualifiers

Metal requires that all pointer types be declared with explicit address space attributes (device, thread, etc...). There is already precedent for this with Cycles' address space macros (ccl_global, ccl_private, etc...), therefore the first step of MSL-enablement is to apply these consistently. Line-for-line this represents the largest change required to enable MSL. Applying this change first will simplify future patches as well as offering the emergent benefit of enhanced descriptiveness.

Cross-platform layer (device/gpu)

Cycles is architected such that the majority of the kernel code is shared, with a small surface area of platform-specific entrypoints and an associated compatibility adapter header ("compat.h"). Metal is no exception, and almost all required features can be adapted through a "metal/compat.h", including thread indexing accessors, texture sampling adapters, math intrinsics, and SIMD-group functions (analogous to CUDA's warp-level primitives).

There are a couple of small exceptions which require minimal modification elsewhere:

float3 as used by some integrator state arrays, requires the use of Metal's packed_float3 to achieve tight packing
Lambda expressions are not available in MSL, however all instances (chiefly volume-stepping) can be easily adapted to use function objects, either directly or through adapter macros

Resource encoding and access

The Cycles kernels make use of several device-accessible resources - more than is practical to pass directly through kernel dispatches. Metal offers a convenient way to encode the required resources into argument buffers which we can structure as required for device access. Since MSL is based on C++, we can wrap all of the shared kernel code in a context class containing the correctly structured resources. This way, kernel resources can be accessed using the usual methods: INTEGRATOR_STATE, kernel_tex_fetch, etc...

Beyond this, the bulk of the remaining work is on the host-side, where the addition of a Metal device will have very minimal interaction with existing host-side code.

Links:

**Tasks** For tracking Metal device development, targeting 3.1 release: - [x] Kernel changes required to compile for MSL (Metal Shading Language): - [x] Explicit address space qualifiers - [x] Adapt cross-platform layer (device/gpu) for MSL - [x] MetalRT kernel changes - [x] Host changes: - [x] Support specification of explicit dispatch argument types - [x] Add core Metal implmentation (device_impl, device_queue, etc) - [x] Min OS / device version checks - [x] Buildbot changes - [x] Upgrade Xcode on buildbot machines to macOS 12.0 SDK - [x] Arm - [x] Intel - [x] Regression tests (`CYCLES_TEST_DEVICES=CPU;METAL`) - [x] Enable on Arm buildbot, with just a single test to verify the basic kernel works - [x] Fix broken tests - [x] Bake tests have empty output - [x] Missing shadows(?) in many volume tests - [x] Missing point cloud support ([D13632](https://archive.blender.org/developer/D13632)) - [x] Ambient occlusion only local fails - [x] Enable running of all tests on the buildbot - [ ] MetalRT regression test failures - [x] Point clouds - [x] Ambient occlusion only local - [ ] Crash rendering 3D hair curves (ribbons are ok) - [ ] Misc other failures - [ ] hair transmission - [ ] openvdb smoke - [ ] shadow catcher pt transparent lamp only 1.0 - [ ] visibility particles - [x] Hardware support - [x] Apple Silicon - [x] AMD - [x] Intel (requires buildbot update to macOS 13, see [D16253](https://archive.blender.org/developer/D16253)) Performance - see #101931 --- **Metal GPU Cycles Implementation** Overview of initial steps taken to get the implementation working. There are two broad phases to enabling the Metal GPU implementation of Cycles: - Adapting the kernel code so that it can be compiled under MSL ([Metal Shading Language](https://developer.apple.com/metal/Metal-Shading-Language-Specification.pdf)) - Adding the new Metal host-side device The kernel code changes represent the largest chunk of work, in terms of interaction with existing implementations. MSL is closely based on C++14, therefore much of the kernel code already compiles by default. Here we describe the remaining steps required to fully compile kernels with MSL: **Explicit address space qualifiers** - Metal requires that all pointer types be declared with explicit address space attributes (`device`, `thread`, etc...). There is already precedent for this with Cycles' address space macros (`ccl_global`, `ccl_private`, etc...), therefore the first step of MSL-enablement is to apply these consistently. Line-for-line this represents the largest change required to enable MSL. Applying this change first will simplify future patches as well as offering the emergent benefit of enhanced descriptiveness. **Cross-platform layer (device/gpu)** - Cycles is architected such that the majority of the kernel code is shared, with a small surface area of platform-specific entrypoints and an associated compatibility adapter header ("compat.h"). Metal is no exception, and almost all required features can be adapted through a "metal/compat.h", including thread indexing accessors, texture sampling adapters, math intrinsics, and SIMD-group functions (analogous to CUDA's warp-level primitives). ``` There are a couple of small exceptions which require minimal modification elsewhere: ``` - `float3` as used by some integrator state arrays, requires the use of Metal's `packed_float3` to achieve tight packing - Lambda expressions are not available in MSL, however all instances (chiefly volume-stepping) can be easily adapted to use function objects, either directly or through adapter macros **Resource encoding and access** - The Cycles kernels make use of several device-accessible resources - more than is practical to pass directly through kernel dispatches. Metal offers a convenient way to encode the required resources into [argument buffers](https://developer.apple.com/documentation/metal/buffers/about_argument_buffers) which we can structure as required for device access. Since MSL is based on C++, we can wrap all of the shared kernel code in a context class containing the correctly structured resources. This way, kernel resources can be accessed using the usual methods: `INTEGRATOR_STATE`, `kernel_tex_fetch`, etc... Beyond this, the bulk of the remaining work is on the host-side, where the addition of a Metal device will have very minimal interaction with existing host-side code. --- **Links:** - [Metal Shading Language Specification](https://developer.apple.com/metal/Metal-Shading-Language-Specification.pdf) - [About Metal Argument Buffers](https://developer.apple.com/documentation/metal/buffers/about_argument_buffers)

Added subscriber: @Michael-Jones

This issue was referenced by blender/cycles@51366f838e

This issue was referenced by blender/cycles@51366f838eb392e2005f9ffea7e892d7e5f7e45e

This issue was referenced by a0f269f682

This issue was referenced by a0f269f682dab848afc80cd322d04a0c4a815cae

Added subscriber: @ThomasDinges

Added subscriber: @PhlixFer

Added subscriber: @VictorMukayev

Added subscriber: @FrancoisRoussel-3

Added subscriber: @ChuckOcheret

Added subscriber: @Memento

Added subscriber: @gupon

Added subscriber: @lvxejay

Added subscriber: @blenderrocket

Added subscriber: @SteveWong-1

Added subscriber: @MetinSeven-1

Added subscriber: @mel

Added subscriber: @Miro-Virta

Added subscriber: @Stefan_Werner

Added subscriber: @samuelmiller

Added subscriber: @virokannas

Added subscriber: @GeorgiaPacific

Added subscriber: @Alaska

Changed status from 'Needs Triage' to: 'Confirmed'

Added subscriber: @macgeek21

Added subscriber: @Eliot-Mack

Added subscriber: @levybergman

Added subscriber: @liquidplace

Best news in 2021 :-)

Added subscriber: @CharlesWardlaw

Added subscriber: @OsakaWayne

Added subscriber: @HiggsTheBoson

Added subscriber: @amandak

Added subscriber: @hatchli

Added subscriber: @Matt-McLin

Added subscriber: @Christopher-Snowhill

Added subscriber: @Raimund58

Added subscriber: @Omega151

Added subscriber: @Caddickbrown

Added subscriber: @MatthiasZierau

Added subscriber: @Zeirus

Added subscriber: @NIDIE_XP

Added subscriber: @dodo-2

Before Update to vulkan first.... :) ( iknow the task is in progress : https://developer.blender.org/T68990)

Removed subscriber: @NIDIE_XP

Added subscriber: @UseTheFarce

Added subscriber: @HectorDeAnda

Added subscriber: @Puckohead

Added subscriber: @lucacustom

Added subscriber: @simonmurphy

Added subscriber: @chaos666

Added subscriber: @easythrees

Added subscriber: @winnertakesteve-1

Added subscriber: @mycoconut

Added subscriber: @Low_Polygon42

Added subscriber: @zxleeethan

Added subscriber: @Sigillus

Removed subscriber: @Sigillus

Added subscriber: @Rajesh-kumar-M-2

Added subscriber: @Kiha

Added subscriber: @Zelig

Added subscriber: @JakobUnn

Added subscriber: @Sigra

Added subscriber: @henner78

Added subscriber: @Lucas-Bleackley-Petter

Added subscriber: @shinyuu

Added subscriber: @Sait-Kiat

Added subscriber: @KABBOUCHI

Added subscriber: @forrestwalter

Added subscriber: @llemarie

Added subscriber: @misiek3d

Added subscriber: @Bryan-Germann

Added subscriber: @MXBBB

Added subscriber: @knox

Added subscriber: @Ololoki

Added subscriber: @Zandman

Added subscriber: @2046411367

Added subscriber: @bireos

Added subscriber: @FynnGr

Added subscriber: @gintszilbalodis

Added subscriber: @bao007fei

Added subscriber: @Henry-Bourne

Added subscriber: @kozbilek

Added subscriber: @Will-7

Added subscriber: @hebus

Hi,

A dumb question here… not related to Cycle,

But what about the extensive use of OpenGL in the blender code itself, OpenGL seems to be used as the basic 3D graphic call everywhere, no abstraction layer.

Cheers

Hi, A dumb question here… not related to Cycle, But what about the extensive use of OpenGL in the blender code itself, OpenGL seems to be used as the basic 3D graphic call everywhere, no abstraction layer. Cheers

Added subscriber: @brecht

@hebus please see #68990 for the development of the OpenGL abstraction layer and Vulkan.

Let's stay on the topic of Cycles & Metal development in this task.

@hebus please see #68990 for the development of the OpenGL abstraction layer and Vulkan. Let's stay on the topic of Cycles & Metal development in this task.

Added subscriber: @zardashtkaya

Added subscriber: @Sankel

Added subscriber: @itsNYD3LL-2

Added subscriber: @CookItOff

Added subscriber: @Anthony-Boyd

Added subscriber: @mr.simon

Added subscriber: @sleepdepchris

Added subscriber: @yigit

This issue was referenced by blender/cycles@901562929d

This issue was referenced by blender/cycles@901562929d0479aa6dfc4a7487bfb8250414acb4

This issue was referenced by 3a4c8f406a

This issue was referenced by 3a4c8f406a3a3bf0627477c6183a594fa707a6e2

Added subscriber: @AledBrown

Added subscriber: @philippremy

Added subscriber: @darknoon

Added subscriber: @jaypatel

Added subscriber: @William7679

Added subscriber: @Alej

Added subscriber: @scottmckay

Added subscriber: @Alexandre-Valsamou-Stanislawski

This issue was referenced by blender/cycles@3e50677692

This issue was referenced by blender/cycles@3e5067769211644400e24f9cb7ab192735dc36e0

This issue was referenced by 9937d5379c

This issue was referenced by 9937d5379ca936b4ba93534185477fa7e529181c

This issue was referenced by blender/cycles@200053d682

This issue was referenced by blender/cycles@200053d68244b4c90e5f0ad26207cd3034a65ca7

This issue was referenced by 64003fa4b0

This issue was referenced by 64003fa4b0b1699998a5b048d980eb775d547d8d

Added subscriber: @AlfredTsaizer

Added subscriber: @jm3d

This issue was referenced by blender/cycles@a7335a6533

This issue was referenced by blender/cycles@a7335a6533c60c9bd873d3850b7819c02b948d60

This issue was referenced by d19e35873f

This issue was referenced by d19e35873f67c90b251ca38e007a83aa1eada211

This issue was referenced by blender/cycles@46ad25a76f

This issue was referenced by blender/cycles@46ad25a76fe2821d1a005687fbba866865c65a42

This issue was referenced by d1f944c186

This issue was referenced by d1f944c18634f215c3da0484ac3b80e994118680

Added subscriber: @csabikaa97

Added subscriber: @Nurb2Kea

Removed subscriber: @Nurb2Kea

Added subscriber: @AndyBCX

Added subscriber: @aaronburns

Added subscriber: @JWelek

Added subscriber: @Francesco-Della-Torre

Thank you so much for finally giving Apple users some love!!
One quick question: with Blender getting Metal support, will I be able to use my Intel Iris Pro 1536 MB (Mid 2015 MacBook Pro) and Nvidia GeForce GT 640M (Late 2012 iMac) GPUs? In theory I should be able to, since they’re supported by Metal…?
Should I already try Blender 3.1 to see if they work or is it too early?
Thanks in advance for any answers.

Thank you so much for finally giving Apple users some love!! One quick question: with Blender getting Metal support, will I be able to use my Intel Iris Pro 1536 MB (Mid 2015 MacBook Pro) and Nvidia GeForce GT 640M (Late 2012 iMac) GPUs? In theory I should be able to, since they’re supported by Metal…? Should I already try Blender 3.1 to see if they work or is it too early? Thanks in advance for any answers.

There is no build to test yet, and no information yet on which GPUs will be supported. The 2012 iMac will definitely not be supported though, since this relies on more recent Metal driver fixes/improvements not available for that device.

In #92212#1261328, @brecht wrote:
There is no build to test yet, and no information yet on which GPUs will be supported. The 2012 iMac will definitely not be supported though, since this relies on more recent Metal driver fixes/improvements not available for that device.

Hey Brecht, thank you for the quick answer! Okay, that makes sense. I hope the 2015 MacBook Pro will be supported though. 😄
It can still be updated to the latest MacOS version and its GPU is supported by Metal, so it should all work.

> In #92212#1261328, @brecht wrote: > There is no build to test yet, and no information yet on which GPUs will be supported. The 2012 iMac will definitely not be supported though, since this relies on more recent Metal driver fixes/improvements not available for that device. Hey Brecht, thank you for the quick answer! Okay, that makes sense. I hope the 2015 MacBook Pro will be supported though. 😄 It can still be updated to the latest MacOS version and its GPU is supported by Metal, so it should all work.

Added subscriber: @ArtWeb

I want to thank all Blender developers for this, it really means a lot to mac users. When can we expect a build to test performance on? Also will integrated GPUs see performance improvements too (The one in the M1 for example)?

In #92212#1261440, @ArtWeb wrote:
I want to thank all Blender developers for this, it really means a lot to mac users. When can we expect a build to test performance on?

Builds will be available when they are ready. The current aim is to get Metal support into Blender 3.1 but that is only a target, if issues arise it may be delayed to a later Blender version.

In #92212#1261440, @ArtWeb wrote:
Also will integrated GPUs see performance improvements too (The one in the M1 for example)?

This is just my interpretation of things, but it seems the GPUs in "Apple Silicon" (M1, M1 Max, M1 Pro and future devices) will be supported. As for the expected performance, you will have to wait until performance numbers are posted or the build is made available for testing and you can test it yourself (assuming you have the device to test with).

> In #92212#1261440, @ArtWeb wrote: > I want to thank all Blender developers for this, it really means a lot to mac users. When can we expect a build to test performance on? Builds will be available when they are ready. The current aim is to get Metal support into Blender 3.1 but that is only a target, if issues arise it may be delayed to a later Blender version. > In #92212#1261440, @ArtWeb wrote: >Also will integrated GPUs see performance improvements too (The one in the M1 for example)? This is just my interpretation of things, but it **seems** the GPUs in "Apple Silicon" (`M1`, `M1 Max`, `M1 Pro` and future devices) will be supported. As for the expected performance, you will have to wait until performance numbers are posted or the build is made available for testing and you can test it yourself (assuming you have the device to test with).

Added subscriber: @domdosinme

This issue was referenced by blender/cycles@88dc78c907

This issue was referenced by blender/cycles@88dc78c907f53e112c241972f7a8c7d103e57a2b

This issue was referenced by 98a5c924fc

This issue was referenced by 98a5c924fca00b4b39e75a4fc16585cfa040398c

This issue was referenced by blender/cycles@6a038a2e63

This issue was referenced by blender/cycles@6a038a2e6370f1feb151f3496fa32070836affb8

This issue was referenced by f613c4c095

This issue was referenced by f613c4c0953ebaf993ecd55b12bab9cf2196dac4

Added subscriber: @Val80

Added subscriber: @Yuro

Added subscriber: @KaelenBaldwin

Added subscriber: @Pixla

Added subscriber: @Hello9999901

Added subscriber: @luca_1948

Added subscriber: @danm3d

Added subscriber: @Steve-Hanff

Added subscriber: @kironde

Added subscriber: @SimonArcher

Added subscriber: @metal_bass

Added subscriber: @regcs

This issue was referenced by blender/cycles@27052fbbba

This issue was referenced by blender/cycles@27052fbbbabdfbd5141a2a18f647ef05c1852878

This issue was referenced by 9558fa5196

This issue was referenced by 9558fa5196033390111a2348caa66ab18b8a4f89

Added subscriber: @Futaba

Tried to build myself, crashes every time trying to render

Thread 28 Crashed:
0   Blender                       	       0x104501124 ccl::MetalDevice::build_bvh(ccl::BVH*, ccl::Progress&, bool) + 24
1   Blender                       	       0x10462911c ccl::Geometry::compute_bvh(ccl::Device*, ccl::DeviceScene*, ccl::SceneParams*, ccl::Progress*, int, int) + 1060
2   Blender                       	       0x10462911c ccl::Geometry::compute_bvh(ccl::Device*, ccl::DeviceScene*, ccl::SceneParams*, ccl::Progress*, int, int) + 1060
3   Blender                       	       0x1077026d0 tbb::internal::function_task<std::__1::function<void ()> >::execute() + 28
4   Blender                       	       0x1034cbc4c tbb::internal::custom_scheduler<tbb::internal::IntelSchedulerTraits>::process_bypass_loop(tbb::internal::context_guard_helper<false>&, tbb::task*, long) + 440
5   Blender                       	       0x1034cb2fc tbb::internal::custom_scheduler<tbb::internal::IntelSchedulerTraits>::local_wait_for_all(tbb::task&, tbb::task*) + 184
6   Blender                       	       0x1047f7a68 tbb::internal::task_group_base::wait() + 40
7   Blender                       	       0x1077026f8 ccl::TaskPool::wait_work(ccl::TaskPool::Summary*) + 24
8   Blender                       	       0x104631650 ccl::GeometryManager::device_update(ccl::Device*, ccl::DeviceScene*, ccl::Scene*, ccl::Progress&) + 3524
9   Blender                       	       0x10469a2ac ccl::Scene::device_update(ccl::Device*, ccl::Progress&) + 1472
10  Blender                       	       0x10469e8f8 ccl::Scene::update(ccl::Progress&) + 164
11  Blender                       	       0x104744030 ccl::Session::run_update_for_next_iteration() + 1020
12  Blender                       	       0x104743778 ccl::Session::run_main_render_loop() + 120
13  Blender                       	       0x1047447a8 ccl::Session::run() + 252
14  Blender                       	       0x107703190 ccl::thread::run(void*) + 52
15  libsystem_pthread.dylib       	       0x19a0794ec _pthread_start + 148
16  libsystem_pthread.dylib       	       0x19a0742d0 thread_start + 8

Build is release from master branch(on 5bd41b2e25 now but tried 9558fa5196 as well, no luck) with bits from D13503. macOS 12.0.1, MacBook Air M1. Scene and setting are all default with exception of enabling Metal and gpu rendering on cycles.

Tried to build myself, crashes every time trying to render ``` Thread 28 Crashed: 0 Blender 0x104501124 ccl::MetalDevice::build_bvh(ccl::BVH*, ccl::Progress&, bool) + 24 1 Blender 0x10462911c ccl::Geometry::compute_bvh(ccl::Device*, ccl::DeviceScene*, ccl::SceneParams*, ccl::Progress*, int, int) + 1060 2 Blender 0x10462911c ccl::Geometry::compute_bvh(ccl::Device*, ccl::DeviceScene*, ccl::SceneParams*, ccl::Progress*, int, int) + 1060 3 Blender 0x1077026d0 tbb::internal::function_task<std::__1::function<void ()> >::execute() + 28 4 Blender 0x1034cbc4c tbb::internal::custom_scheduler<tbb::internal::IntelSchedulerTraits>::process_bypass_loop(tbb::internal::context_guard_helper<false>&, tbb::task*, long) + 440 5 Blender 0x1034cb2fc tbb::internal::custom_scheduler<tbb::internal::IntelSchedulerTraits>::local_wait_for_all(tbb::task&, tbb::task*) + 184 6 Blender 0x1047f7a68 tbb::internal::task_group_base::wait() + 40 7 Blender 0x1077026f8 ccl::TaskPool::wait_work(ccl::TaskPool::Summary*) + 24 8 Blender 0x104631650 ccl::GeometryManager::device_update(ccl::Device*, ccl::DeviceScene*, ccl::Scene*, ccl::Progress&) + 3524 9 Blender 0x10469a2ac ccl::Scene::device_update(ccl::Device*, ccl::Progress&) + 1472 10 Blender 0x10469e8f8 ccl::Scene::update(ccl::Progress&) + 164 11 Blender 0x104744030 ccl::Session::run_update_for_next_iteration() + 1020 12 Blender 0x104743778 ccl::Session::run_main_render_loop() + 120 13 Blender 0x1047447a8 ccl::Session::run() + 252 14 Blender 0x107703190 ccl::thread::run(void*) + 52 15 libsystem_pthread.dylib 0x19a0794ec _pthread_start + 148 16 libsystem_pthread.dylib 0x19a0742d0 thread_start + 8 ``` Build is release from master branch(on 5bd41b2e255 now but tried 9558fa51960 as well, no luck) with bits from [D13503](https://archive.blender.org/developer/D13503). macOS 12.0.1, MacBook Air M1. Scene and setting are all default with exception of enabling Metal and gpu rendering on cycles.

yes same issue only difference M1Pro (Termination Reason: Namespace SIGNAL, Code 11 Segmentation fault: 11), viewport or rendering makes no difference.

MacBook Pro 15’ 2017 with Radeon Pro 560 (macOS 12.0.1)

Render Kernel starts compiling and crashes with ‘Compiler encountered an internal error’, error with integrator_active_paths_array

MacBook Pro 15’ 2017 with Radeon Pro 560 (macOS 12.0.1) Render Kernel starts compiling and crashes with ‘Compiler encountered an internal error’, error with integrator_active_paths_array

In #92212#1267718, @Futaba wrote:
Tried to build myself, crashes every time trying to render

I believe a missing WITH_METAL define is preventing the Metal BVH setup case from executing which manifests as an assert in a debug build. Try this one-line patch: D13505

> In #92212#1267718, @Futaba wrote: > Tried to build myself, crashes every time trying to render > I believe a missing `WITH_METAL` define is preventing the Metal BVH setup case from executing which manifests as an assert in a debug build. Try this one-line patch: [D13505](https://archive.blender.org/developer/D13505)

In #92212#1267744, @Michael-Jones wrote:

In #92212#1267718, @Futaba wrote:
Tried to build myself, crashes every time trying to render

I believe a missing WITH_METAL define is preventing the Metal BVH setup case from executing which manifests as an assert in a debug build. Try this one-line patch: D13505

yes it does :) thanks

> In #92212#1267744, @Michael-Jones wrote: >> In #92212#1267718, @Futaba wrote: >> Tried to build myself, crashes every time trying to render >> > > I believe a missing `WITH_METAL` define is preventing the Metal BVH setup case from executing which manifests as an assert in a debug build. Try this one-line patch: [D13505](https://archive.blender.org/developer/D13505) yes it does :) thanks

In #92212#1267734, @philippremy wrote:
MacBook Pro 15’ 2017 with Radeon Pro 560 (macOS 12.0.1)

Render Kernel starts compiling and crashes with ‘Compiler encountered an internal error’, error with integrator_active_paths_array

The current Metal implementation only works on Apple Silicon devices right now. AMD enablement is on the way, hopefully lining up with the 3.1 binary release.

> In #92212#1267734, @philippremy wrote: > MacBook Pro 15’ 2017 with Radeon Pro 560 (macOS 12.0.1) > > Render Kernel starts compiling and crashes with ‘Compiler encountered an internal error’, error with integrator_active_paths_array The current Metal implementation only works on Apple Silicon devices right now. AMD enablement is on the way, hopefully lining up with the 3.1 binary release.

In #92212#1267754, @Michael-Jones wrote:

The current Metal implementation only works on Apple Silicon devices right now. AMD enablement is on the way, hopefully lining up with the 3.1 binary release.

Do these builds you are discussing here end up automagically on the Daily Builds 3.1 alpha list? Or do I need to build/compile it myself?

I'd be curious to try it on my M1 Max.

I've got Homebrew up and running and I've read up on Blender's documentation on building myself, but I'm not sure how or where I specify a specific branch—or is this the actual Master that gets build as per Blender's instructions:

brew install cmake svn

> In #92212#1267754, @Michael-Jones wrote: > > The current Metal implementation only works on Apple Silicon devices right now. AMD enablement is on the way, hopefully lining up with the 3.1 binary release. Do these builds you are discussing here end up automagically on the Daily Builds 3.1 alpha list? Or do I need to build/compile it myself? I'd be curious to try it on my M1 Max. I've got Homebrew up and running and I've read up on Blender's documentation on building myself, but I'm not sure how or where I specify a specific branch—or is this the actual Master that gets build as per Blender's instructions: > brew install cmake svn

WITH_METAL totally works, thanks!

In #92212#1267759, @Pixla wrote:

In #92212#1267754, @Michael-Jones wrote:

The current Metal implementation only works on Apple Silicon devices right now. AMD enablement is on the way, hopefully lining up with the 3.1 binary release.

Do these builds you are discussing here end up automagically on the Daily Builds 3.1 alpha list? Or do I need to build/compile it myself?

I'd be curious to try it on my M1 Max.

I've got Homebrew up and running and I've read up on Blender's documentation on building myself, but I'm not sure how or where I specify a specific branch—or is this the actual Master that gets build as per Blender's instructions:

brew install cmake svn

It is in master, you only need changes from D13503 to enable it. Or wait for builds from metal-enable branch I guess.

***WITH_METAL*** totally works, thanks! > In #92212#1267759, @Pixla wrote: >> In #92212#1267754, @Michael-Jones wrote: >> >> The current Metal implementation only works on Apple Silicon devices right now. AMD enablement is on the way, hopefully lining up with the 3.1 binary release. > > Do these builds you are discussing here end up automagically on the Daily Builds 3.1 alpha list? Or do I need to build/compile it myself? > > I'd be curious to try it on my M1 Max. > > I've got Homebrew up and running and I've read up on Blender's documentation on building myself, but I'm not sure how or where I specify a specific branch—or is this the actual Master that gets build as per Blender's instructions: > >> brew install cmake svn It is in master, you only need changes from [D13503](https://archive.blender.org/developer/D13503) to enable it. Or wait for builds from *metal-enable* branch I guess.

Just tested this on an M1 Max (32 cores). Compositing makes Blender crash consistently. Turning it off, the classroom scene renders in 110 seconds.

Added subscriber: @John-Lamb

In #92212#1267754, @Michael-Jones wrote:

In #92212#1267734, @philippremy wrote:
MacBook Pro 15’ 2017 with Radeon Pro 560 (macOS 12.0.1)

Render Kernel starts compiling and crashes with ‘Compiler encountered an internal error’, error with integrator_active_paths_array

The current Metal implementation only works on Apple Silicon devices right now. AMD enablement is on the way, hopefully lining up with the 3.1 binary release.

Cries in intel - ok, that would explain why I just... could... not... get this to work. Thanks for all the hard work. This means a lot to us Mac users!

P.S. when you want someone with a VEGA 48 to slam on this for testing, feel free to reach out :)

> In #92212#1267754, @Michael-Jones wrote: >> In #92212#1267734, @philippremy wrote: >> MacBook Pro 15’ 2017 with Radeon Pro 560 (macOS 12.0.1) >> >> Render Kernel starts compiling and crashes with ‘Compiler encountered an internal error’, error with integrator_active_paths_array > > The current Metal implementation only works on Apple Silicon devices right now. AMD enablement is on the way, hopefully lining up with the 3.1 binary release. *Cries in intel* - ok, that would explain why I just... could... not... get this to work. Thanks for all the hard work. This means a lot to us Mac users! P.S. when you want someone with a VEGA 48 to slam on this for testing, feel free to reach out :)

YES, it's finally working, congrats to everyone working so hard in the project. Is there going to be metal support for intel integrated graphics? Also, will this build be available in "Daily Builds" or will I have access to it only by building it myself? The improvement really looks like it's day and night, 110 seconds for classroom... Around 5.3 times faster than x86 blender running on CPU for the M1 Max.

Added subscriber: @Volconon

Thanks a lot guys! Up and running here too with Blender's demo files benching smoothly with everything working (M1 Max 16").

So nice to already have come so far in what feels like a short time. Things have moved along much faster than I would have hoped! It can only get better from here: forward+upward!

Thanks a lot guys! Up and running here too with Blender's demo files benching smoothly with everything working (M1 Max 16"). So nice to already have come so far in what feels like a short time. Things have moved along much faster than I would have hoped! It can only get better from here: forward+upward!

Added subscriber: @FredSprinkle

Added subscriber: @Manigandan-Saravanan-4

Finally got it working. Not sure how to build properly yet so i just edited the text files. M1 Pro 16 Cores 32GB same render time as my desktop with GeForce 1080 8GB.

Added subscriber: @hogg-4

I couldn't find a Metal branch. Has this work been integrated into master already? I've built master and the Sytem Info says:

==========================================
= Blender 3.1.0 Alpha System Information =
==========================================
build linkflags: ... -framework Metal

GPU:
==========================================

renderer:	'Apple M1'
vendor:		'Apple'
version:	'4.1 Metal - 71.7.1'

Does this mean I have the proper build?

I couldn't find a Metal branch. Has this work been integrated into `master` already? I've built `master` and the Sytem Info says: ``` ========================================== = Blender 3.1.0 Alpha System Information = ========================================== build linkflags: ... -framework Metal GPU: ========================================== renderer: 'Apple M1' vendor: 'Apple' version: '4.1 Metal - 71.7.1' ``` Does this mean I have the proper build?

Please wait a bit until the last missing bits are worked out and available in master. I understand the enthusiasm, but please remember this task is for developers who work on the Metal Cycles backend, and not for discussions / user questions or compile help. Thanks!

Removed subscriber: @gintszilbalodis

Added subscriber: @AlfredENeuman

In #92212#1268006, @ThomasDinges wrote:
... please remember this task is for developers who work on the Metal Cycles backend, and not for discussions / user questions or compile help. Thanks!

In my understanding once stuff is approved in master it is more or less cooked. I would've expected this stuff to live inside a separate Metal branch until then, but wasn't able to find one. I'm not trying to be an end-user here, just checking how it runs on my machine/work and possibly help development by detecting issues. As I did before for other developements.

But I guess I'll wait then :-)

> In #92212#1268006, @ThomasDinges wrote: > ... please remember this task is for developers who work on the Metal Cycles backend, and not for discussions / user questions or compile help. Thanks! In my understanding once stuff is approved in `master` it is more or less cooked. I would've expected this stuff to live inside a separate Metal branch until then, but wasn't able to find one. I'm not trying to be an end-user here, just checking how it runs on my machine/work and possibly help development by detecting issues. As I did before for other developements. But I guess I'll wait then :-)

In #92212#1268067, @Zandman wrote:
But I guess I'll wait then :-)

I posted a link to my Metal build a few posts up, if you want to try that.

> In #92212#1268067, @Zandman wrote: > But I guess I'll wait then :-) I posted a link to my Metal build a few posts up, if you want to try that.

In #92212#1268103, @Pixla wrote:
I posted a link to my Metal build a few posts up, if you want to try that.

Thanks, but in general I refrain from running unofficial builds made by others, just as a security precaution. Also, unless you did some signing magic your build probably won't run on my machine. Apple has tightened up that stuff pretty well lately.

I should be perfectly able to build one myself. I just needed to know if I was building the right branch and if I had to enable switches/defines or that a default make release would already to the trick.

Anyway, I'm done here. Don't want to clutter this task with my musings :-)

> In #92212#1268103, @Pixla wrote: > I posted a link to my Metal build a few posts up, if you want to try that. Thanks, but in general I refrain from running unofficial builds made by others, just as a security precaution. Also, unless you did some signing magic your build probably won't run on my machine. Apple has tightened up that stuff pretty well lately. I should be perfectly able to build one myself. I just needed to know if I was building the right branch and if I had to enable switches/defines or that a default `make release` would already to the trick. Anyway, I'm done here. Don't want to clutter this task with my musings :-)

Added subscriber: @kisvenus

Added subscriber: @hahnzhu

Added subscriber: @ikester_blender

In #92212#1268103, @Pixla wrote:

In #92212#1268067, @Zandman wrote:
But I guess I'll wait then :-)

I posted a link to my Metal build a few posts up, if you want to try that.

@Pixla, your build is an Intel binary (not M1/Apple Silicon or Universal).

> In #92212#1268103, @Pixla wrote: >> In #92212#1268067, @Zandman wrote: >> But I guess I'll wait then :-) > > I posted a link to my Metal build a few posts up, if you want to try that. @Pixla, your build is an Intel binary (not M1/Apple Silicon or Universal).

I would post my Apple Silicon binary, but I want to sign and notarize it first, and I haven't tested whether the binary needs entitlements to work with hardened runtime. I should check the source tree for an entitlements file just in case.

I am amazed at the performance, especially if this is just preliminary and in need of further tuning. It already blows away my old RX 480 in my PC, which is increasingly harder to use for much of anything other than the occasional light game when something refuses to run on my Mac.

The RX 480, attempting to render the 2.81 Junk Shop demo, already was nearly equal to CPU rendering on my Ryzen 7 2700, which made me question its future usefulness for rendering tasks, considering how it likes to nearly crash the system when rendering. ROCm dropped Polaris, too.

I would post my Apple Silicon binary, but I want to sign and notarize it first, and I haven't tested whether the binary needs entitlements to work with hardened runtime. I should check the source tree for an entitlements file just in case. I am amazed at the performance, especially if this is just preliminary and in need of further tuning. It already blows away my old RX 480 in my PC, which is increasingly harder to use for much of anything other than the occasional light game when something refuses to run on my Mac. The RX 480, attempting to render the 2.81 Junk Shop demo, already was nearly equal to CPU rendering on my Ryzen 7 2700, which made me question its future usefulness for rendering tasks, considering how it likes to nearly crash the system when rendering. ROCm dropped Polaris, too.

Added subscriber: @Karol-Zachara

In #92212#1269889, @ikester_blender wrote:
@Pixla, your build is an Intel binary (not M1/Apple Silicon or Universal).

Thanks for pointing that out! I had compiled it on both my Mac Pro and my M1 Max MacBook Pro and it was the wrong link posted – sorry about that.

I also totally understand the concerns about running random apps compiled by users on the internet and I also don't want to add noise to the developer exchange taking place here, so it's back to being a 'fly on the wall' for me.

Looking forward to seeing this trickle into the official alphas!

> In #92212#1269889, @ikester_blender wrote: > @Pixla, your build is an Intel binary (not M1/Apple Silicon or Universal). Thanks for pointing that out! I had compiled it on both my Mac Pro and my M1 Max MacBook Pro and it was the wrong link posted – sorry about that. I also totally understand the concerns about running random apps compiled by users on the internet and I also don't want to add noise to the developer exchange taking place here, so it's back to being a 'fly on the wall' for me. Looking forward to seeing this trickle into the official alphas!

This comment was removed by @Karol-Zachara

*This comment was removed by @Karol-Zachara*

One last moderation note: This is not the place to share builds, user questions, compile help etc. It is only for the developers, who work on the Metal implementation. Please use user forums like blenderartists for these kind of things.

There are 123 people subscribed here, per default user setting everyone will get an mail notification on every update.

Every further comment, that is not related to the actual development, will be removed!

One last moderation note: This is *not* the place to share builds, user questions, compile help etc. It is only for the developers, who work on the Metal implementation. Please use user forums like blenderartists for these kind of things. There are 123 people subscribed here, per default user setting everyone will get an mail notification on every update. **Every further comment, that is not related to the actual development, will be removed!**

Added subscriber: @Kuutti-Taavitsainen

Added subscriber: @OrchardDigital

This comment was removed by @OrchardDigital

*This comment was removed by @OrchardDigital*

Added subscriber: @okapi

Added subscriber: @KhalilChikh

This comment was removed by @KhalilChikh

*This comment was removed by @KhalilChikh*

Removed subscriber: @UseTheFarce

Added subscriber: @maxvoltar

Added subscriber: @nodymoha

Added subscriber: @MN-4

Added subscriber: @edwardloveall

Added subscriber: @soffes

Added subscriber: @sid350

This issue was referenced by blender/cycles@1fbf07d556

This issue was referenced by blender/cycles@1fbf07d5564d4306fe66949c478d5cbb2bfe653d

This issue was referenced by 3f96555123

This issue was referenced by 3f96555123db2b48047c40a45a6b78d6cd760dc4

This is now enabled for Apple M1 computers in the Blender 3.1 daily build. Please leave any feedback here:
https://devtalk.blender.org/t/cycles-apple-metal-device-feedback/21868

This is now enabled for Apple M1 computers in the Blender 3.1 daily build. Please leave any feedback here: https://devtalk.blender.org/t/cycles-apple-metal-device-feedback/21868

Removed subscriber: @hogg-4

Added subscriber: @AidenLocke

@Michael-Jones I ran the regression tests and found some things failing, these would need to be fixed before we enable automated testing. Or we blacklist some tests but preferably not.

I also had trouble getting pointcloud rendering to work with an internal compiler error. I might have made some mistake in the implementation. Would be helpful if you could have a look. (D13632)

@Michael-Jones I ran the regression tests and found some things failing, these would need to be fixed before we enable automated testing. Or we blacklist some tests but preferably not. I also had trouble getting pointcloud rendering to work with an internal compiler error. I might have made some mistake in the implementation. Would be helpful if you could have a look. ([D13632](https://archive.blender.org/developer/D13632))

In #92212#1275908, @brecht wrote:
@Michael-Jones I ran the regression tests and found some things failing, these would need to be fixed before we enable automated testing. Or we blacklist some tests but preferably not.

I'm in the process of triaging the failures. At least some require driver fixes which we're aiming to land in time for 3.1.

I also had trouble getting pointcloud rendering to work with an internal compiler error. I might have made some mistake in the implementation. Would be helpful if you could have a look. (D13632)

Great - I'll take a quick look now...

> In #92212#1275908, @brecht wrote: > @Michael-Jones I ran the regression tests and found some things failing, these would need to be fixed before we enable automated testing. Or we blacklist some tests but preferably not. I'm in the process of triaging the failures. At least some require driver fixes which we're aiming to land in time for 3.1. > I also had trouble getting pointcloud rendering to work with an internal compiler error. I might have made some mistake in the implementation. Would be helpful if you could have a look. ([D13632](https://archive.blender.org/developer/D13632)) Great - I'll take a quick look now...

Removed subscriber: @chaos666

Added subscriber: @Dar3NPo

Added subscriber: @kunemann

Added subscriber: @Phong-Vu

This issue was referenced by 1a27d20df3

This issue was referenced by 1a27d20df3ff57d3b95a24daec2ca8ff3de5dbc2

The buildbot was updated to cross-compile x86_64 binaries on the Arm machines, which means we can now build with the new Xcode version needed for Metal.

It now also runs a single Metal regression test (cycles_camera_metal) on the buildbot, to verify the basic kernel works. We can enable all the tests when they pass.

The buildbot was updated to cross-compile x86_64 binaries on the Arm machines, which means we can now build with the new Xcode version needed for Metal. It now also runs a single Metal regression test (`cycles_camera_metal`) on the buildbot, to verify the basic kernel works. We can enable all the tests when they pass.

Added subscriber: @Chris-Bowman

Removed subscriber: @Kuutti-Taavitsainen

Added subscriber: @sjoerd

This issue was referenced by blender/cycles@045a09c1b6

This issue was referenced by blender/cycles@045a09c1b693b38ea0304b2583d7fa839b09636b

This issue was referenced by f6c8a78ac6

This issue was referenced by f6c8a78ac684242ba067499511a0db2fa64657fe

This issue was referenced by blender/cycles@f12ad656cc

This issue was referenced by blender/cycles@f12ad656ccd08d1a330d8eede8820117ee2c17f9

This issue was referenced by d68ce0e475

This issue was referenced by d68ce0e4754e4f4fc957fa702a2fb34535129d8b

Removed subscriber: @okapi

Added subscriber: @carterbk

(@brecht)

Metal status update:

I have a workaround for these bake failures which involve special-casing RenderBuffers to use managed storage instead of shared storage (possibly a synchronisation issue):

Bake tests have empty output

These are the result of a driver issue which should be fixed in macOS 12.2:

Missing shadows(?) in many volume tests

...and as a result we should update the OS version check, however I was planning to do that closer to 3.1 release if this makes sense?
- Min OS / device version checks

(@brecht) Metal status update: 1) I have a workaround for these bake failures which involve special-casing `RenderBuffers` to use *managed* storage instead of *shared* storage (possibly a synchronisation issue): - [ ] Bake tests have empty output 2) These are the result of a driver issue which should be fixed in macOS 12.2: - [ ] Missing shadows(?) in many volume tests 3) ...and as a result we should update the OS version check, however I was planning to do that closer to 3.1 release if this makes sense? - [x] Min OS / device version checks

Regarding multi-device support, I'm aware that CPU+GPU performance on Metal is not generally giving an uplift over GPU-only render times. @brecht , are you aware of any general issues with CPU+GPU load-balancing that could be affecting results here?

From what I’ve tested, CPU+GPU doesn’t help in CUDA and OPTIX either. That wasn’t the case before Cycles X was introduced so it probably has something to do with recent load-balancing changes.

Removed subscriber: @soffes

In #92212#1295377, @Michael-Jones wrote:

I have a workaround for these bake failures which involve special-casing RenderBuffers to use managed storage instead of shared storage (possibly a synchronisation issue):

It's a bit odd since the init_from_bake kernel doesn't do anything very different from init_from_camera, and all the other kernels are shared. But a workaround is fine.

These are the result of a driver issue which should be fixed in macOS 12.2:

Sounds good.

...and as a result we should update the OS version check, however I was planning to do that closer to 3.1 release if this makes sense?

Fine with me, not much point checking for macOS 12.2 if it's not out yet.

are you aware of any general issues with CPU+GPU load-balancing that could be affecting results here?

Yes, we have #89833 (Cycles: multi-device rendering performance).

I think generally it does tend to help for more complex scenes that take a while to render, while for simpler/quick renders the balancing overhead/slowness is too much. There's also overhead of having to build 2 BVHs for example. Not really specific to Metal.

It helps for some people in the feedback thread at least:
https://devtalk.blender.org/t/cycles-apple-metal-device-feedback/21868/68

> In #92212#1295377, @Michael-Jones wrote: > 1) I have a workaround for these bake failures which involve special-casing `RenderBuffers` to use *managed* storage instead of *shared* storage (possibly a synchronisation issue): It's a bit odd since the `init_from_bake` kernel doesn't do anything very different from `init_from_camera`, and all the other kernels are shared. But a workaround is fine. > 2) These are the result of a driver issue which should be fixed in macOS 12.2: Sounds good. > 3) ...and as a result we should update the OS version check, however I was planning to do that closer to 3.1 release if this makes sense? Fine with me, not much point checking for macOS 12.2 if it's not out yet. > are you aware of any general issues with CPU+GPU load-balancing that could be affecting results here? Yes, we have #89833 (Cycles: multi-device rendering performance). I think generally it does tend to help for more complex scenes that take a while to render, while for simpler/quick renders the balancing overhead/slowness is too much. There's also overhead of having to build 2 BVHs for example. Not really specific to Metal. It helps for some people in the feedback thread at least: https://devtalk.blender.org/t/cycles-apple-metal-device-feedback/21868/68

I hope it is appropriate to comment on performance regressions in this thread. I have noted with the past few builds that the render times for the BMW GPU "benchmark" file are consistently slower on an MBP M1 Max, 32 GB, on a power adapter with Energy Mode set to "High Power". I was getting an average of 42 secs in early January and I'm currently getting ~47 secs. I know that some things changed over the last couple of weeks, first with the crashing and then with the CPU not being used when the CPU+GPU option was selected, as mentioned on this thread: https://devtalk.blender.org/t/cycles-apple-metal-device-feedback/21868/96.

I'm aware that this might not be an issue (and might even be inverted) with more complex scenes, but it is consistent and it's not negligible,
so I thought I'd mention it.

I hope it is appropriate to comment on performance regressions in this thread. I have noted with the past few builds that the render times for the BMW GPU "benchmark" file are consistently slower on an MBP M1 Max, 32 GB, on a power adapter with Energy Mode set to "High Power". I was getting an average of 42 secs in early January and I'm currently getting ~47 secs. I know that some things changed over the last couple of weeks, first with the crashing and then with the CPU not being used when the CPU+GPU option was selected, as mentioned on this thread: https://devtalk.blender.org/t/cycles-apple-metal-device-feedback/21868/96. I'm aware that this might not be an issue (and might even be inverted) with more complex scenes, but it is consistent and it's not negligible, so I thought I'd mention it.

Added subscriber: @davidmikucki

In #92212#1295437, @brecht wrote:

Fine with me, not much point checking for macOS 12.2 if it's not out yet.

This actually just came out moments ago.

> In #92212#1295437, @brecht wrote: > Fine with me, not much point checking for macOS 12.2 if it's not out yet. This actually just came out moments ago.

Added subscriber: @Kuutti-Taavitsainen

Added subscriber: @Isaac_Lee

@ikester_blender BMW is actually not a great test. After the BVH2 patch it is the only demo scene that is slower for me.
Monster under the bed, Classroom for example are faster.

What I however noticed it that memory use has gone through the roof, especially Sinosauropteryx Prima, before I could easily render it at 2048 tiles but that was a no go after the patch. Also memory use while rendering was about twice as high as before BVH2.

@brecht do you think that is normal?

@ikester_blender BMW is actually not a great test. After the BVH2 patch it is the only demo scene that is slower for me. Monster under the bed, Classroom for example are faster. What I however noticed it that memory use has gone through the roof, especially Sinosauropteryx Prima, before I could easily render it at 2048 tiles but that was a no go after the patch. Also memory use while rendering was about twice as high as before BVH2. @brecht do you think that is normal?

In #92212#1295555, @Steve-Hanff wrote:
@ikester_blender BMW is actually not a great test. After the BVH2 patch it is the only demo scene that is slower for me.
Monster under the bed, Classroom for example are faster.

This matches my observations: after the bvh2 switch, all of the benchmark scenes are faster except BMW, which seems to be a bit of an outlier in general.

What I however noticed it that memory use has gone through the roof, especially Sinosauropteryx Prima, before I could easily render it at 2048 tiles but that was a no go after the patch. Also memory use while rendering was about twice as high as before BVH2.

I am investigating this and hope to have insight soon. While it's great that benchmarking scenes render faster with bvh2, we don't want to regress on larger scenes like Sinosauropteryx. One possibility could be to expose a separate MetalRT device in the same way that Cycles has separate CUDA and Optix device. There are still some (seemingly minor) correctness issues with MetalRT, so it would probably make sense for this to be opt-in and marked as experimental. @brecht , does this seem reasonable?

> In #92212#1295555, @Steve-Hanff wrote: > @ikester_blender BMW is actually not a great test. After the BVH2 patch it is the only demo scene that is slower for me. > Monster under the bed, Classroom for example are faster. This matches my observations: after the bvh2 switch, all of the benchmark scenes are faster except BMW, which seems to be a bit of an outlier in general. > What I however noticed it that memory use has gone through the roof, especially Sinosauropteryx Prima, before I could easily render it at 2048 tiles but that was a no go after the patch. Also memory use while rendering was about twice as high as before BVH2. I am investigating this and hope to have insight soon. While it's great that benchmarking scenes render faster with bvh2, we don't want to regress on larger scenes like Sinosauropteryx. One possibility could be to expose a separate MetalRT device in the same way that Cycles has separate CUDA and Optix device. There are still some (seemingly minor) correctness issues with MetalRT, so it would probably make sense for this to be opt-in and marked as experimental. @brecht , does this seem reasonable?

Kinda related: #93089 (Cycles: CUDA takes ages to render what takes seconds on CPU and OPTIX (it also needs way more RAM))

In #92212#1295846, @Michael-Jones wrote:
One possibility could be to expose a separate MetalRT device in the same way that Cycles has separate CUDA and Optix device. There are still some (seemingly minor) correctness issues with MetalRT, so it would probably make sense for this to be opt-in and marked as experimental. @brecht , does this seem reasonable?

We can add an option for MetalRT, but I don't think it needs to be a new device type. A boolean like peer_memory for CUDA/OptiX seems enough to me.

> In #92212#1295846, @Michael-Jones wrote: > One possibility could be to expose a separate MetalRT device in the same way that Cycles has separate CUDA and Optix device. There are still some (seemingly minor) correctness issues with MetalRT, so it would probably make sense for this to be opt-in and marked as experimental. @brecht , does this seem reasonable? We can add an option for MetalRT, but I don't think it needs to be a new device type. A boolean like `peer_memory` for CUDA/OptiX seems enough to me.

Added subscriber: @cagram

Added subscriber: @makizar

Added subscriber: @EAW

@Michael-Jones OpenColorIO v2.1.1 has added Metal Shading Language generation support to the GPU renderer. Just an FYI in case it is helpful to you.

https://github.com/AcademySoftwareFoundation/OpenColorIO/releases/tag/v2.1.1
https://github.com/AcademySoftwareFoundation/OpenColorIO/pull/1520

@Michael-Jones OpenColorIO v2.1.1 has added Metal Shading Language generation support to the GPU renderer. Just an FYI in case it is helpful to you. https://github.com/AcademySoftwareFoundation/OpenColorIO/releases/tag/v2.1.1 https://github.com/AcademySoftwareFoundation/OpenColorIO/pull/1520

This issue was referenced by 6175c569f9

This issue was referenced by 6175c569f9c7c7b2c97fd318634c4c61873f41ad

Added subscriber: @simon-luo

Added subscriber: @George-Samper

Added subscriber: @ZeeshanYousuf

Added subscriber: @C60

Added subscriber: @Benup

Hello,

Blender 3.1.0 beta (Apple Silicon) or 3.2.0 alpha (Apple Silicon) can't be used with UV Paint. It is very slow, lag, with the graphic tablet. But the Intel 3.0.1 version works perfectly in Mac Apple Silicon. Is a correction possible ?

Thanks for your work !

Hello, Blender 3.1.0 beta (Apple Silicon) or 3.2.0 alpha (Apple Silicon) can't be used with UV Paint. It is very slow, lag, with the graphic tablet. But the Intel 3.0.1 version works perfectly in Mac Apple Silicon. Is a correction possible ? Thanks for your work !

@Benup please report potential bugs through this form. This task is not related to texture painting.
https://developer.blender.org/maniphest/task/edit/form/1/

@Benup please report potential bugs through this form. This task is not related to texture painting. https://developer.blender.org/maniphest/task/edit/form/1/

Removed subscriber: @Isaac_Lee

@ Brecht Van Lommel (brecht) Ok I post the bug in the day ;-)

Removed subscriber: @camden-1

Added subscriber: @DarrylDias

Did Metal get slower in the 3.1.0 release candidate compared to beta/alpha?

I've been using 3.1.0 beta a lot and have been impressed by render speeds on the M1 Max, however the release candidate seems slower and the GPU settings look different.

I don't have data on this yet, but curious if anyone else has expressed this.

Did Metal get slower in the 3.1.0 release candidate compared to beta/alpha? I've been using 3.1.0 beta a lot and have been impressed by render speeds on the M1 Max, however the release candidate seems slower and the GPU settings look different. I don't have data on this yet, but curious if anyone else has expressed this.

Added subscriber: @StanK

Something wrong with Mac OS 12.3.
An error with ATI drivers for 5-/6-series of AMD cards. AMD driver is 4.1 ATI-4.8.13 and it have half of performance of previous version. As I understand, Michael Jones say that they worked on AMD drivers for CyclesX but 12.3 drop down performance of EEVEE engine and overall system performance. Please, watch for that side.

Something wrong with Mac OS 12.3. An error with ATI drivers for 5-/6-series of AMD cards. AMD driver is 4.1 ATI-4.8.13 and it have half of performance of previous version. As I understand, Michael Jones say that they worked on AMD drivers for CyclesX but 12.3 drop down performance of EEVEE engine and overall system performance. Please, watch for that side.

This is unrelated to Blender, the bug affects the whole system. For more detailed information, see this article from AppleInsider: macOS 12.3 update causing problems for some PCI-E GPU owners.

This is unrelated to Blender, the bug affects the whole system. For more detailed information, see this article from AppleInsider: [macOS 12.3 update causing problems for some PCI-E GPU owners](https://appleinsider.com/articles/22/03/15/macos-123-update-causing-problems-for-some-pci-e-gpu-owners).

Please keep this task on topic! This task is for developers only and should focus on code design and review. Please report bugs in the dedicated place. Thank you for your understanding.

Please keep this task on topic! **This task is for developers only** and should focus on code design and review. Please report bugs in the dedicated place. Thank you for your understanding.

Added subscriber: @Koen-Kooi

Added subscriber: @ErikT

Added subscriber: @Alex-Shepard

Added subscriber: @Funnybob

Added subscriber: @blobinabottle

Added subscriber: @tylerfurby

Added subscriber: @JacobMerrill-1

Added subscriber: @skyscapeparadise

Added subscriber: @extrup-1

This issue was referenced by f9f834068e

This issue was referenced by f9f834068e38f562f3590c12af35d3033db98995

This issue was referenced by e6902d19a0

This issue was referenced by e6902d19a0d8b034e65f28df6dba914a876b08df

Removed subscriber: @bireos

Added subscriber: @Alexander-Hartmann

This issue was referenced by b132e3b3ce

This issue was referenced by b132e3b3ce1c5ecc836d22f4c4cba90e0ed2edcc

This issue was referenced by 009f7de619

This issue was referenced by 009f7de619e62b9415fa09f4ee72ecb4b8fbb9b9

@Michael-Jones, I got a report from Christophe Hery that MetaRT rendering of 3D curves crashes currently, while ribbons are fine.

I'm not sure if one of the recent changes broke it. I added it to the list of MetalRT issues in the description.

@Michael-Jones, I got a report from Christophe Hery that MetaRT rendering of 3D curves crashes currently, while ribbons are fine. I'm not sure if one of the recent changes broke it. I added it to the list of MetalRT issues in the description.

@Michael-Jones, I got a report from Christophe Hery that MetaRT rendering of 3D curves crashes currently, while ribbons are fine.

I'm not sure if one of the recent changes broke it. I added it to the list of MetalRT issues in the description.

Hey @brecht, do you know if there are any more specific repro steps? It seemed fine when I switched hair_close_up.blend over to 3D Curves + MetalRT (main @5491563e59a7298f129b0b521f1a385d46243a5b, M1 Max, macOS 13.0).

> @Michael-Jones, I got a report from Christophe Hery that MetaRT rendering of 3D curves crashes currently, while ribbons are fine. > > I'm not sure if one of the recent changes broke it. I added it to the list of MetalRT issues in the description. Hey @brecht, do you know if there are any more specific repro steps? It seemed fine when I switched hair_close_up.blend over to 3D Curves + MetalRT (main @5491563e59a7298f129b0b521f1a385d46243a5b, M1 Max, macOS 13.0).

@Christophe-Hery, see above, are there specific repro steps?

Seems like I cannot repro anymore this week (from a synced up main).

With the same scene/settings, including hairs as Shape = 3D Curves under MetalRT (experimental - full), on a build from two weeks ago, here is the type of crash I would get:

Translated Report (Full Report Below)

Process: Blender [31766]
Path: /Users/USER/Desktop/Blender3.60_v84_ARM.app/Contents/MacOS/Blender
Identifier: org.blenderfoundation.blender
Version: 3.6.0 (3.6.0 2023-03-29)
Code Type: ARM-64 (Native)
Parent Process: launchd [1]
User ID: 501

Date/Time: 2023-04-18 16:39:34.2245 +0200
OS Version: macOS 13.3.1 (22E261)
Report Version: 12
Anonymous UUID: BCE1D7E7-77DC-344D-2EA7-FF5305322A41

Time Awake Since Boot: 1500 seconds

System Integrity Protection: enabled

Crashed Thread: 32 Dispatch queue: MTLBinaryArchive

Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000000
Exception Codes: 0x0000000000000001, 0x0000000000000000

Termination Reason: Namespace SIGNAL, Code 11 Segmentation fault: 11
Terminating Process: exc handler [31766]

VM Region Info: 0 is not in any region. Bytes before following region: 4341334016
REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL
UNUSED SPACE AT START
--->
__TEXT 102c38000-10e270000 [182.2M] r-x/r-x SM=COW ...MacOS/Blender

Thread 0:
0 libsystem_kernel.dylib 0x195f3fe90 semaphore_wait_trap + 8
1 libdispatch.dylib 0x195dd099c _dispatch_sema4_wait + 28
2 libdispatch.dylib 0x195dd1050 _dispatch_semaphore_wait_slow + 132
3 libIlmThread.dylib 0x112a3b398 IlmThread_3_1::(anonymous namespace)::DefaultWorkerThread::run() + 64
4 libIlmThread.dylib 0x112a39fe4 void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_deletestd::__1::__thread_struct>, void (IlmThread_3_1::Thread::)(), IlmThread_3_1::Thread>>(void*) + 64
5 libsystem_pthread.dylib 0x195f7ffa8 _pthread_start + 148
6 libsystem_pthread.dylib 0x195f7ada0 thread_start + 8

Thread 1:
0 libsystem_kernel.dylib 0x195f3fe90 semaphore_wait_trap + 8
1 libdispatch.dylib 0x195dd099c _dispatch_sema4_wait + 28
2 libdispatch.dylib 0x195dd1050 _dispatch_semaphore_wait_slow + 132
3 libIlmThread.dylib 0x112a3b398 IlmThread_3_1::(anonymous namespace)::DefaultWorkerThread::run() + 64
4 libIlmThread.dylib 0x112a39fe4 void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_deletestd::__1::__thread_struct>, void (IlmThread_3_1::Thread::)(), IlmThread_3_1::Thread>>(void*) + 64
5 libsystem_pthread.dylib 0x195f7ffa8 _pthread_start + 148
6 libsystem_pthread.dylib 0x195f7ada0 thread_start + 8

Thread 2:
0 libsystem_kernel.dylib 0x195f3fe90 semaphore_wait_trap + 8
1 libdispatch.dylib 0x195dd099c _dispatch_sema4_wait + 28
2 libdispatch.dylib 0x195dd1050 _dispatch_semaphore_wait_slow + 132
3 libIlmThread.dylib 0x112a3b398 IlmThread_3_1::(anonymous namespace)::DefaultWorkerThread::run() + 64
4 libIlmThread.dylib 0x112a39fe4 void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_deletestd::__1::__thread_struct>, void (IlmThread_3_1::Thread::)(), IlmThread_3_1::Thread>>(void*) + 64
5 libsystem_pthread.dylib 0x195f7ffa8 _pthread_start + 148
6 libsystem_pthread.dylib 0x195f7ada0 thread_start + 8

Thread 3:
0 libsystem_kernel.dylib 0x195f3fe90 semaphore_wait_trap + 8
1 libdispatch.dylib 0x195dd099c _dispatch_sema4_wait + 28
2 libdispatch.dylib 0x195dd1050 _dispatch_semaphore_wait_slow + 132
3 libIlmThread.dylib 0x112a3b398 IlmThread_3_1::(anonymous namespace)::DefaultWorkerThread::run() + 64
4 libIlmThread.dylib 0x112a39fe4 void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_deletestd::__1::__thread_struct>, void (IlmThread_3_1::Thread::)(), IlmThread_3_1::Thread>>(void*) + 64
5 libsystem_pthread.dylib 0x195f7ffa8 _pthread_start + 148
6 libsystem_pthread.dylib 0x195f7ada0 thread_start + 8

Thread 4:
0 libsystem_kernel.dylib 0x195f3fe90 semaphore_wait_trap + 8
1 libdispatch.dylib 0x195dd099c _dispatch_sema4_wait + 28
2 libdispatch.dylib 0x195dd1050 _dispatch_semaphore_wait_slow + 132
3 libIlmThread.dylib 0x112a3b398 IlmThread_3_1::(anonymous namespace)::DefaultWorkerThread::run() + 64
4 libIlmThread.dylib 0x112a39fe4 void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_deletestd::__1::__thread_struct>, void (IlmThread_3_1::Thread::)(), IlmThread_3_1::Thread>>(void*) + 64
5 libsystem_pthread.dylib 0x195f7ffa8 _pthread_start + 148
6 libsystem_pthread.dylib 0x195f7ada0 thread_start + 8

Thread 5:
0 libsystem_kernel.dylib 0x195f3fe90 semaphore_wait_trap + 8
1 libdispatch.dylib 0x195dd099c _dispatch_sema4_wait + 28
2 libdispatch.dylib 0x195dd1050 _dispatch_semaphore_wait_slow + 132
3 libIlmThread.dylib 0x112a3b398 IlmThread_3_1::(anonymous namespace)::DefaultWorkerThread::run() + 64
4 libIlmThread.dylib 0x112a39fe4 void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_deletestd::__1::__thread_struct>, void (IlmThread_3_1::Thread::)(), IlmThread_3_1::Thread>>(void*) + 64
5 libsystem_pthread.dylib 0x195f7ffa8 _pthread_start + 148
6 libsystem_pthread.dylib 0x195f7ada0 thread_start + 8

Thread 6:
0 libsystem_kernel.dylib 0x195f3fe90 semaphore_wait_trap + 8
1 libdispatch.dylib 0x195dd099c _dispatch_sema4_wait + 28
2 libdispatch.dylib 0x195dd1050 _dispatch_semaphore_wait_slow + 132
3 libIlmThread.dylib 0x112a3b398 IlmThread_3_1::(anonymous namespace)::DefaultWorkerThread::run() + 64
4 libIlmThread.dylib 0x112a39fe4 void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_deletestd::__1::__thread_struct>, void (IlmThread_3_1::Thread::)(), IlmThread_3_1::Thread>>(void*) + 64
5 libsystem_pthread.dylib 0x195f7ffa8 _pthread_start + 148
6 libsystem_pthread.dylib 0x195f7ada0 thread_start + 8

Thread 7:
0 libsystem_kernel.dylib 0x195f3fe90 semaphore_wait_trap + 8
1 libdispatch.dylib 0x195dd099c _dispatch_sema4_wait + 28
2 libdispatch.dylib 0x195dd1050 _dispatch_semaphore_wait_slow + 132
3 libIlmThread.dylib 0x112a3b398 IlmThread_3_1::(anonymous namespace)::DefaultWorkerThread::run() + 64
4 libIlmThread.dylib 0x112a39fe4 void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_deletestd::__1::__thread_struct>, void (IlmThread_3_1::Thread::)(), IlmThread_3_1::Thread>>(void*) + 64
5 libsystem_pthread.dylib 0x195f7ffa8 _pthread_start + 148
6 libsystem_pthread.dylib 0x195f7ada0 thread_start + 8

Thread 8:
0 libsystem_kernel.dylib 0x195f3fe90 semaphore_wait_trap + 8
1 libdispatch.dylib 0x195dd099c _dispatch_sema4_wait + 28
2 libdispatch.dylib 0x195dd1050 _dispatch_semaphore_wait_slow + 132
3 libIlmThread.dylib 0x112a3b398 IlmThread_3_1::(anonymous namespace)::DefaultWorkerThread::run() + 64
4 libIlmThread.dylib 0x112a39fe4 void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_deletestd::__1::__thread_struct>, void (IlmThread_3_1::Thread::)(), IlmThread_3_1::Thread>>(void*) + 64
5 libsystem_pthread.dylib 0x195f7ffa8 _pthread_start + 148
6 libsystem_pthread.dylib 0x195f7ada0 thread_start + 8

Thread 9:
0 libsystem_kernel.dylib 0x195f3fe90 semaphore_wait_trap + 8
1 libdispatch.dylib 0x195dd099c _dispatch_sema4_wait + 28
2 libdispatch.dylib 0x195dd1050 _dispatch_semaphore_wait_slow + 132
3 libIlmThread.dylib 0x112a3b398 IlmThread_3_1::(anonymous namespace)::DefaultWorkerThread::run() + 64
4 libIlmThread.dylib 0x112a39fe4 void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_deletestd::__1::__thread_struct>, void (IlmThread_3_1::Thread::)(), IlmThread_3_1::Thread>>(void*) + 64
5 libsystem_pthread.dylib 0x195f7ffa8 _pthread_start + 148
6 libsystem_pthread.dylib 0x195f7ada0 thread_start + 8

Thread 10:
0 libsystem_pthread.dylib 0x195f7ad8c start_wqthread + 0

Thread 11:
0 libsystem_pthread.dylib 0x195f7ad8c start_wqthread + 0

Thread 12:: caulk.messenger.shared:17
0 libsystem_kernel.dylib 0x195f3fe90 semaphore_wait_trap + 8
1 caulk 0x19f59e024 caulk::semaphore::timed_wait(double) + 212
2 caulk 0x19f59ded8 caulk::concurrent::details::worker_thread::run() + 36
3 caulk 0x19f59dbc8 void* caulk::thread_proxy<std::__1::tuple<caulk:🧵:attributes, void (caulk::concurrent::details::worker_thread::)(), std::__1::tuplecaulk::concurrent::details::worker_thread*>>(void) + 96
4 libsystem_pthread.dylib 0x195f7ffa8 _pthread_start + 148
5 libsystem_pthread.dylib 0x195f7ada0 thread_start + 8

Thread 13:: com.apple.audio.IOThread.client
0 libsystem_kernel.dylib 0x195f3ff14 mach_msg2_trap + 8
1 libsystem_kernel.dylib 0x195f52240 mach_msg2_internal + 80
2 libsystem_kernel.dylib 0x195f48b78 mach_msg_overwrite + 604
3 libsystem_kernel.dylib 0x195f40290 mach_msg + 24
4 CoreAudio 0x198369624 HALB_MachPort::SendSimpleMessageWithSimpleReply(unsigned int, unsigned int, int, int&, bool, unsigned int) + 104
5 CoreAudio 0x198256d14 HALC_ProxyIOContext::IOWorkLoop() + 3516
6 CoreAudio 0x19825587c invocation function for block in HALC_ProxyIOContext::HALC_ProxyIOContext(unsigned int, unsigned int) + 116
7 CoreAudio 0x1983b8564 HALB_IOThread::Entry(void*) + 88
8 libsystem_pthread.dylib 0x195f7ffa8 _pthread_start + 148
9 libsystem_pthread.dylib 0x195f7ada0 thread_start + 8

Thread 14:
0 libsystem_kernel.dylib 0x195f3fe90 semaphore_wait_trap + 8
1 libtbb.dylib 0x112a75ffc rml::internal::thread_monitor::commit_wait(rml::internal::thread_monitor::cookie&) + 64
2 libtbb.dylib 0x112a75bb4 tbb::internal::rml::private_worker::run() + 420
3 libtbb.dylib 0x112a75a04 tbb::internal::rml::private_worker::thread_routine(void*) + 12
4 libsystem_pthread.dylib 0x195f7ffa8 _pthread_start + 148
5 libsystem_pthread.dylib 0x195f7ada0 thread_start + 8

Thread 15:
0 libsystem_kernel.dylib 0x195f3fe90 semaphore_wait_trap + 8
1 libtbb.dylib 0x112a75ffc rml::internal::thread_monitor::commit_wait(rml::internal::thread_monitor::cookie&) + 64
2 libtbb.dylib 0x112a75bb4 tbb::internal::rml::private_worker::run() + 420
3 libtbb.dylib 0x112a75a04 tbb::internal::rml::private_worker::thread_routine(void*) + 12
4 libsystem_pthread.dylib 0x195f7ffa8 _pthread_start + 148
5 libsystem_pthread.dylib 0x195f7ada0 thread_start + 8

Thread 16:
0 libsystem_kernel.dylib 0x195f3fe90 semaphore_wait_trap + 8
1 libtbb.dylib 0x112a75ffc rml::internal::thread_monitor::commit_wait(rml::internal::thread_monitor::cookie&) + 64
2 libtbb.dylib 0x112a75bb4 tbb::internal::rml::private_worker::run() + 420
3 libtbb.dylib 0x112a75a04 tbb::internal::rml::private_worker::thread_routine(void*) + 12
4 libsystem_pthread.dylib 0x195f7ffa8 _pthread_start + 148
5 libsystem_pthread.dylib 0x195f7ada0 thread_start + 8

Thread 17:
0 libsystem_kernel.dylib 0x195f3fe90 semaphore_wait_trap + 8
1 libtbb.dylib 0x112a75ffc rml::internal::thread_monitor::commit_wait(rml::internal::thread_monitor::cookie&) + 64
2 libtbb.dylib 0x112a75bb4 tbb::internal::rml::private_worker::run() + 420
3 libtbb.dylib 0x112a75a04 tbb::internal::rml::private_worker::thread_routine(void*) + 12
4 libsystem_pthread.dylib 0x195f7ffa8 _pthread_start + 148
5 libsystem_pthread.dylib 0x195f7ada0 thread_start + 8

Thread 18:
0 libsystem_kernel.dylib 0x195f3fe90 semaphore_wait_trap + 8
1 libtbb.dylib 0x112a75ffc rml::internal::thread_monitor::commit_wait(rml::internal::thread_monitor::cookie&) + 64
2 libtbb.dylib 0x112a75bb4 tbb::internal::rml::private_worker::run() + 420
3 libtbb.dylib 0x112a75a04 tbb::internal::rml::private_worker::thread_routine(void*) + 12
4 libsystem_pthread.dylib 0x195f7ffa8 _pthread_start + 148
5 libsystem_pthread.dylib 0x195f7ada0 thread_start + 8

Thread 19:
0 libsystem_kernel.dylib 0x195f3fe90 semaphore_wait_trap + 8
1 libtbb.dylib 0x112a75ffc rml::internal::thread_monitor::commit_wait(rml::internal::thread_monitor::cookie&) + 64
2 libtbb.dylib 0x112a75bb4 tbb::internal::rml::private_worker::run() + 420
3 libtbb.dylib 0x112a75a04 tbb::internal::rml::private_worker::thread_routine(void*) + 12
4 libsystem_pthread.dylib 0x195f7ffa8 _pthread_start + 148
5 libsystem_pthread.dylib 0x195f7ada0 thread_start + 8

Thread 20:
0 libsystem_kernel.dylib 0x195f3fe90 semaphore_wait_trap + 8
1 libtbb.dylib 0x112a75ffc rml::internal::thread_monitor::commit_wait(rml::internal::thread_monitor::cookie&) + 64
2 libtbb.dylib 0x112a75bb4 tbb::internal::rml::private_worker::run() + 420
3 libtbb.dylib 0x112a75a04 tbb::internal::rml::private_worker::thread_routine(void*) + 12
4 libsystem_pthread.dylib 0x195f7ffa8 _pthread_start + 148
5 libsystem_pthread.dylib 0x195f7ada0 thread_start + 8

Thread 21:
0 libsystem_kernel.dylib 0x195f3fe90 semaphore_wait_trap + 8
1 libtbb.dylib 0x112a75ffc rml::internal::thread_monitor::commit_wait(rml::internal::thread_monitor::cookie&) + 64
2 libtbb.dylib 0x112a75bb4 tbb::internal::rml::private_worker::run() + 420
3 libtbb.dylib 0x112a75a04 tbb::internal::rml::private_worker::thread_routine(void*) + 12
4 libsystem_pthread.dylib 0x195f7ffa8 _pthread_start + 148
5 libsystem_pthread.dylib 0x195f7ada0 thread_start + 8

Thread 22:
0 libsystem_kernel.dylib 0x195f3fe90 semaphore_wait_trap + 8
1 libtbb.dylib 0x112a75ffc rml::internal::thread_monitor::commit_wait(rml::internal::thread_monitor::cookie&) + 64
2 libtbb.dylib 0x112a75bb4 tbb::internal::rml::private_worker::run() + 420
3 libtbb.dylib 0x112a75a04 tbb::internal::rml::private_worker::thread_routine(void*) + 12
4 libsystem_pthread.dylib 0x195f7ffa8 _pthread_start + 148
5 libsystem_pthread.dylib 0x195f7ada0 thread_start + 8

Thread 23:
0 libsystem_pthread.dylib 0x195f7ad8c start_wqthread + 0

Thread 24:: com.apple.NSEventThread
0 libsystem_kernel.dylib 0x195f3ff14 mach_msg2_trap + 8
1 libsystem_kernel.dylib 0x195f52240 mach_msg2_internal + 80
2 libsystem_kernel.dylib 0x195f48b78 mach_msg_overwrite + 604
3 libsystem_kernel.dylib 0x195f40290 mach_msg + 24
4 CoreFoundation 0x19605e8b8 __CFRunLoopServiceMachPort + 160
5 CoreFoundation 0x19605d198 __CFRunLoopRun + 1208
6 CoreFoundation 0x19605c58c CFRunLoopRunSpecific + 612
7 AppKit 0x1993a6508 _NSEventThread + 172
8 libsystem_pthread.dylib 0x195f7ffa8 _pthread_start + 148
9 libsystem_pthread.dylib 0x195f7ada0 thread_start + 8

Thread 25:
0 libsystem_pthread.dylib 0x195f7ad8c start_wqthread + 0

Thread 26:
0 libsystem_pthread.dylib 0x195f7ad8c start_wqthread + 0

Thread 27:
0 libsystem_kernel.dylib 1 libsystem_pthread.dylib 2 libc++.1.dylib 3 Blender 4 Blender 5 Blender 6 Blender 7 Blender 8 Blender 9 Blender 10 Blender 11 Blender 12 Blender 13 Blender 14 Blender 15 Blender 16 Blender 17 Blender 18 Blender 19 Blender 20 Blender 21 Blender 22 Blender 23 Blender 24 libsystem_pthread.dylib 25 libsystem_pthread.dylib 0x195f43710 __psynch_cvwait + 8
0x195f80574 _pthread_cond_wait + 1232
0x195ea8ef0 std::__1::condition_variable::wait(std::__1::unique_lockstd::__1::mutex&) + 28
0x104c34240 ccl::Session::wait() + 108
0x104865c88 ccl::BlenderSession::render(BL::Depsgraph&) + 2508
0x10485da2c ccl::render_func(_object*, _object*) + 160
0x109f40634 cfunction_call + 172 (methodobject.c:552)
0x109ef7a24 _PyObject_MakeTpCall + 360 (call.c:215)
0x109fdaaf4 call_function + 548
0x109fd7ff0 _PyEval_EvalFrameDefault + 25324 (ceval.c:4181)
0x109fd1bf8 _PyEval_EvalFrame + 24 (pycore_ceval.h:46) [inlined]
0x109fd1bf8 _PyEval_Vector + 164 (ceval.c:5065)
0x109fdaa0c call_function + 316
0x109fd7ff0 _PyEval_EvalFrameDefault + 25324 (ceval.c:4181)
0x109fd1bf8 _PyEval_EvalFrame + 24 (pycore_ceval.h:46) [inlined]
0x109fd1bf8 _PyEval_Vector + 164 (ceval.c:5065)
0x103809910 bpy_class_call + 1000
0x10376a408 engine_render + 120
0x103f1bea8 engine_render_view_layer(Render*, RenderEngine*, ViewLayer*, bool, bool) + 556
0x103f1ba50 RE_engine_render + 892
0x103f2093c do_render_full_pipeline(Render*) + 264
0x103f205b0 RE_RenderFrame + 356
0x10480eb0c render_startjob(void*, bool*, bool*, float*) + 92
0x10334e748 do_job_thread + 40
0x195f7ffa8 _pthread_start + 148
0x195f7ada0 thread_start + 8

Thread 28:
0 libsystem_pthread.dylib 0x195f7ad8c start_wqthread + 0

Thread 29:
0 libsystem_kernel.dylib 0x195f4350c __semwait_signal + 8
1 libsystem_c.dylib 0x195e242d0 nanosleep + 220
2 libc++.1.dylib 0x195eb6a18 std::__1::this_thread::sleep_for(std::__1::chrono::duration<long long, std::__1::ratio<1l, 1000000000l>> const&) + 84
3 Blender 0x1048ebc04 ccl::ShaderCache::get_best_pipeline(ccl::DeviceKernel, ccl::MetalDevice const*) + 112
4 Blender 0x1048ef3cc ccl::MetalDeviceQueue::enqueue(ccl::DeviceKernel, int, ccl::DeviceKernelArguments const&) + 1292
5 Blender 0x104caa778 ccl::ShaderEval::eval_gpu(ccl::Device*, ccl::ShaderEvalType, ccl::device_vectorccl::KernelShaderEvalInput&, ccl::device_vector&, long long) + 256
6 Blender 0x104caa23c std::__1::__function::__func<ccl::ShaderEval::eval(ccl::ShaderEvalType, int, int, std::__1::function<int (ccl::device_vectorccl::KernelShaderEvalInput&)> const&, std::__1::function<void (ccl::device_vector&)> const&)::_0, std::__1::allocator<ccl::ShaderEval::eval(ccl::ShaderEvalType, int, int, std::__1::function<int (ccl::device_vector<ccl::KernelShaderEvalInput>&)> const&, std::__1::function<void (ccl::device_vector<float>&)> const&)::_0>, void (ccl::Device*)>::operator()(ccl::Device*&&) + 596
7 Blender 0x1048bcf34 ccl::Device::foreach_device(std::__1::function<void (ccl::Device*)> const&) + 40
8 Blender 0x104ca9ecc ccl::ShaderEval::eval(ccl::ShaderEvalType, int, int, std::__1::function<int (ccl::device_vectorccl::KernelShaderEvalInput&)> const&, std::__1::function<void (ccl::device_vector&)> const&) + 156
9 Blender 0x104b2cb64 ccl::GeometryManager::displace(ccl::Device*, ccl::Scene*, ccl::Mesh*, ccl::Progress&) + 452
10 Blender 0x104ad00ac ccl::GeometryManager::device_update(ccl::Device*, ccl::DeviceScene*, ccl::Scene*, ccl::Progress&) + 2696
11 Blender 0x104b4f3b4 ccl::Scene::device_update(ccl::Device*, ccl::Progress&) + 1548
12 Blender 0x104b50dc4 ccl::Scene::update(ccl::Progress&) + 148
13 Blender 0x104c34c5c ccl::Session::run_update_for_next_iteration() + 1184
14 Blender 0x104c342fc ccl::Session::run_main_render_loop() + 112
15 Blender 0x104c35218 ccl::Session::thread_render() + 252
16 Blender 0x104c33008 ccl::Session::thread_run() + 164
17 Blender 0x10798cc70 ccl:🧵:run(void*) + 28
18 libsystem_pthread.dylib 0x195f7ffa8 _pthread_start + 148
19 libsystem_pthread.dylib 0x195f7ada0 thread_start + 8

Thread 30:
0 libsystem_pthread.dylib 0x195f7ad8c start_wqthread + 0

Thread 31:
0 libsystem_pthread.dylib 0x195f7ad8c start_wqthread + 0

Thread 32 Crashed:: Dispatch queue: MTLBinaryArchive
0 libdispatch.dylib 0x195dcf01c dispatch_release + 12
1 Metal 0x19f4229bc __121-[_MTLBinaryArchive(MTLBinaryArchiveInternal) newArchiverIdWithFunctionId:descriptor:bitcode:srcArchiverId:functionType:]_block_invoke + 548
2 libdispatch.dylib 0x195dd0400 _dispatch_client_callout + 20
3 libdispatch.dylib 0x195ddf97c _dispatch_lane_barrier_sync_invoke_and_complete + 56
4 Metal 0x19f422770 -[_MTLBinaryArchive(MTLBinaryArchiveInternal) newArchiverIdWithFunctionId:descriptor:bitcode:srcArchiverId:functionType:] + 188
5 Metal 0x19f4a80e0 -[MTLCompiler addExtraDataToAirntBinaryArchive:functionId:cachedData:] + 156
6 Metal 0x19f4a922c -[MTLCompiler compileFunctionRequestInternal:frameworkLinking:linkDataSize:reflectionOnly:completionHandler:] + 4120
7 AGXMetalG13X 0x1e2dfc0d0 void AGX::Compiler::compileProgramAGX::ComputeProgramKey(AGX::ComputeProgramKey const&, MTLCompileFunctionRequestData*, void (AGCDeserializedReply const&, NSObject<OS_dispatch_data>, NSObject<OS_dispatch_data>, NSObject<OS_dispatch_data>, NSObject<OS_dispatch_data>, NSObject<OS_dispatch_data>, MTLCompilerError, NSString, unsigned long long) block_pointer) + 568
8 AGXMetalG13X 0x1e2dfaaa8 AGX::UserCommonShaderFactory<AGX::G13::Encoders, AGX::G13::Classes, AGX::G13::ObjClasses>::createComputeProgramVariant(MTLComputePipelineDescriptor*, AGXG13XFamilyDevice*, unsigned long, AGXG13XFamilyBinaryArchive*, NSArray*, AGX::G13::ComputeProgram*, NSObject<OS_dispatch_data>, bool, void (AGX::G13::ComputeProgramVariant, NSMutableDictionary*, MTLCompilerError, NSString*) block_pointer) + 976
9 AGXMetalG13X 0x1e2dfa50c -[AGXG13XFamilyBinaryArchive addComputePipelineFunctionsWithDescriptor:options:error:] + 728
10 Blender 0x1048ee694 ccl::MetalKernelPipeline::compile()::$_2::operator()() const::'lambda'()::operator()() const + 64
11 Blender 0x1048ee504 ccl::MetalKernelPipeline::compile()::$_2::operator()() const + 564
12 Blender 0x1048ea3e4 ccl::MetalKernelPipeline::compile() + 4076
13 Blender 0x1048e8f8c ccl::ShaderCache::compile_thread_func(int) + 512
14 Blender 0x1048eb308 void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_deletestd::__1::__thread_struct>, ccl::ShaderCache::load_kernel(ccl::DeviceKernel, ccl::MetalDevice*, ccl::MetalPipelineType)::$_1>>(void*) + 44
15 libsystem_pthread.dylib 0x195f7ffa8 _pthread_start + 148
16 libsystem_pthread.dylib 0x195f7ada0 thread_start + 8

Thread 33:: Dispatch queue: MTLBinaryArchive
0 libsystem_kernel.dylib 0x195f40968 __open + 8
1 libsystem_kernel.dylib 0x195f4ba84 open + 64
2 Foundation 0x196f9cde4 _NSReadBytesFromFileWithExtendedAttributes + 152
3 Foundation 0x196f9cc64 -[NSData(NSData) initWithContentsOfFile:options:maxLength:error:] + 132
4 Metal 0x19f4884a8 LoaderGlobalState::loadFile(NSURL*, NSError**) + 328
5 Metal 0x19f417d78 -[_MTLBinaryArchive loadFromURL:error:] + 244
6 Metal 0x19f41c6e8 __55-[_MTLBinaryArchive airntSerializeToURL:options:error:]_block_invoke_2 + 784
7 libdispatch.dylib 0x195dd0400 _dispatch_client_callout + 20
8 libdispatch.dylib 0x195ddf97c _dispatch_lane_barrier_sync_invoke_and_complete + 56
9 Metal 0x19f41c3c0 __55-[_MTLBinaryArchive airntSerializeToURL:options:error:]_block_invoke.188 + 504
10 Metal 0x19f4a6bdc __123-[MTLCompiler generateMachOWithID:binaryEntries:numEntries:machOSpecializedData:machOType:Path:platform:completionHandler:]_block_invoke + 96
11 Metal 0x19f45a6cc invocation function for block in MTLCompilerConnectionManagerPrivate::buildRequest(unsigned int, MTLCompilerRequest*, bool, void (MTLCompilerError, NSObject<OS_dispatch_data>, char const) block_pointer) + 92
12 Metal 0x19f458e1c invocation function for block in XPCCompilerConnection::BuildRequestInternal(MTLCompilerRequest*, char const*, NSObject<OS_dispatch_data>, int, bool, void (unsigned int, void const, unsigned long, char const*) block_pointer) + 532
13 Metal 0x19f3dc378 XPCCompilerConnection::BuildRequestInternal(MTLCompilerRequest*, char const*, NSObject<OS_dispatch_data>, int, bool, void (unsigned int, void const, unsigned long, char const*) block_pointer) + 1208
14 Metal 0x19f4595d4 invocation function for block in XPCCompilerConnection::BuildRequest(MTLCompilerRequest*, char const*, NSObject<OS_dispatch_data>, int, bool, void (unsigned int, void const, unsigned long, char const*) block_pointer) + 64
15 libdispatch.dylib 0x195dd0400 _dispatch_client_callout + 20
16 libdispatch.dylib 0x195ddf97c _dispatch_lane_barrier_sync_invoke_and_complete + 56
17 Metal 0x19f3dbe50 XPCCompilerConnection::BuildRequest(MTLCompilerRequest*, char const*, NSObject<OS_dispatch_data>, int, bool, void (unsigned int, void const, unsigned long, char const*) block_pointer) + 136
18 Metal 0x19f3dbc74 MTLCompilerConnectionManagerPrivate::buildRequest(unsigned int, MTLCompilerRequest*, bool, void (MTLCompilerError, NSObject<OS_dispatch_data>, char const) block_pointer) + 524
19 Metal 0x19f4a6a8c -[MTLCompiler generateMachOWithID:binaryEntries:numEntries:machOSpecializedData:machOType:Path:platform:completionHandler:] + 2236
20 Metal 0x19f41b680 __55-[_MTLBinaryArchive airntSerializeToURL:options:error:]_block_invoke + 728
21 libdispatch.dylib 0x195dd0400 _dispatch_client_callout + 20
22 libdispatch.dylib 0x195ddf97c _dispatch_lane_barrier_sync_invoke_and_complete + 56
23 Metal 0x19f41b294 -[_MTLBinaryArchive airntSerializeToURL:options:error:] + 360
24 Blender 0x1048ea4bc ccl::MetalKernelPipeline::compile() + 4292
25 Blender 0x1048e8f8c ccl::ShaderCache::compile_thread_func(int) + 512
26 Blender 0x1048eb308 void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_deletestd::__1::__thread_struct>, ccl::ShaderCache::load_kernel(ccl::DeviceKernel, ccl::MetalDevice*, ccl::MetalPipelineType)::$_1>>(void*) + 44
27 libsystem_pthread.dylib 0x195f7ffa8 _pthread_start + 148
28 libsystem_pthread.dylib 0x195f7ada0 thread_start + 8

Thread 32 crashed with ARM Thread State (64-bit):
x0: 0x0000000000000000 x1: 0x00006000000710e0 x2: 0x0000000000000001 x3: 0x0000600003518070
x4: 0x0000600003518080 x5: 0x0000000003200000 x6: 0x0000600003518000 x7: 0x0000000000000403
x8: 0x0000000000000400 x9: 0x00000000000003ff x10: 0x00000000000010e0 x11: 0x00000000000007fb
x12: 0x00000000a617890e x13: 0x00000000000007fd x14: 0x00000000a637910f x15: 0x00000000a617890e
x16: 0x0000000195dcf010 x17: 0x00000001f5f04270 x18: 0x0000000000000000 x19: 0x000000034cf01df8
x20: 0x0000000000000000 x21: 0x0000000000000000 x22: 0x0000000000000000 x23: 0x00006000000710e0
x24: 0x0000000167075460 x25: 0x00006000590d8300 x26: 0x0000000000000000 x27: 0x0000000000000002
x28: 0x0000000000000000 fp: 0x000000034cf01c80 lr: 0x487800019f4229bc
sp: 0x000000034cf01c80 pc: 0x0000000195dcf01c cpsr: 0x60001000
far: 0x0000000000000000 esr: 0x92000006 (Data Abort) byte read Translation fault

Not sure what ended up fixing the issue...

Seems like I cannot repro anymore this week (from a synced up main). With the same scene/settings, including hairs as Shape = 3D Curves under MetalRT (experimental - full), on a build from two weeks ago, here is the type of crash I would get: ------------------------------------- Translated Report (Full Report Below) ------------------------------------- Process: Blender [31766] Path: /Users/USER/Desktop/Blender3.60_v84_ARM.app/Contents/MacOS/Blender Identifier: org.blenderfoundation.blender Version: 3.6.0 (3.6.0 2023-03-29) Code Type: ARM-64 (Native) Parent Process: launchd [1] User ID: 501 Date/Time: 2023-04-18 16:39:34.2245 +0200 OS Version: macOS 13.3.1 (22E261) Report Version: 12 Anonymous UUID: BCE1D7E7-77DC-344D-2EA7-FF5305322A41 Time Awake Since Boot: 1500 seconds System Integrity Protection: enabled Crashed Thread: 32 Dispatch queue: MTLBinaryArchive Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000000 Exception Codes: 0x0000000000000001, 0x0000000000000000 Termination Reason: Namespace SIGNAL, Code 11 Segmentation fault: 11 Terminating Process: exc handler [31766] VM Region Info: 0 is not in any region. Bytes before following region: 4341334016 REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL UNUSED SPACE AT START ---> __TEXT 102c38000-10e270000 [182.2M] r-x/r-x SM=COW ...MacOS/Blender Thread 0: 0 libsystem_kernel.dylib 0x195f3fe90 semaphore_wait_trap + 8 1 libdispatch.dylib 0x195dd099c _dispatch_sema4_wait + 28 2 libdispatch.dylib 0x195dd1050 _dispatch_semaphore_wait_slow + 132 3 libIlmThread.dylib 0x112a3b398 IlmThread_3_1::(anonymous namespace)::DefaultWorkerThread::run() + 64 4 libIlmThread.dylib 0x112a39fe4 void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct>>, void (IlmThread_3_1::Thread::*)(), IlmThread_3_1::Thread*>>(void*) + 64 5 libsystem_pthread.dylib 0x195f7ffa8 _pthread_start + 148 6 libsystem_pthread.dylib 0x195f7ada0 thread_start + 8 Thread 1: 0 libsystem_kernel.dylib 0x195f3fe90 semaphore_wait_trap + 8 1 libdispatch.dylib 0x195dd099c _dispatch_sema4_wait + 28 2 libdispatch.dylib 0x195dd1050 _dispatch_semaphore_wait_slow + 132 3 libIlmThread.dylib 0x112a3b398 IlmThread_3_1::(anonymous namespace)::DefaultWorkerThread::run() + 64 4 libIlmThread.dylib 0x112a39fe4 void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct>>, void (IlmThread_3_1::Thread::*)(), IlmThread_3_1::Thread*>>(void*) + 64 5 libsystem_pthread.dylib 0x195f7ffa8 _pthread_start + 148 6 libsystem_pthread.dylib 0x195f7ada0 thread_start + 8 Thread 2: 0 libsystem_kernel.dylib 0x195f3fe90 semaphore_wait_trap + 8 1 libdispatch.dylib 0x195dd099c _dispatch_sema4_wait + 28 2 libdispatch.dylib 0x195dd1050 _dispatch_semaphore_wait_slow + 132 3 libIlmThread.dylib 0x112a3b398 IlmThread_3_1::(anonymous namespace)::DefaultWorkerThread::run() + 64 4 libIlmThread.dylib 0x112a39fe4 void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct>>, void (IlmThread_3_1::Thread::*)(), IlmThread_3_1::Thread*>>(void*) + 64 5 libsystem_pthread.dylib 0x195f7ffa8 _pthread_start + 148 6 libsystem_pthread.dylib 0x195f7ada0 thread_start + 8 Thread 3: 0 libsystem_kernel.dylib 0x195f3fe90 semaphore_wait_trap + 8 1 libdispatch.dylib 0x195dd099c _dispatch_sema4_wait + 28 2 libdispatch.dylib 0x195dd1050 _dispatch_semaphore_wait_slow + 132 3 libIlmThread.dylib 0x112a3b398 IlmThread_3_1::(anonymous namespace)::DefaultWorkerThread::run() + 64 4 libIlmThread.dylib 0x112a39fe4 void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct>>, void (IlmThread_3_1::Thread::*)(), IlmThread_3_1::Thread*>>(void*) + 64 5 libsystem_pthread.dylib 0x195f7ffa8 _pthread_start + 148 6 libsystem_pthread.dylib 0x195f7ada0 thread_start + 8 Thread 4: 0 libsystem_kernel.dylib 0x195f3fe90 semaphore_wait_trap + 8 1 libdispatch.dylib 0x195dd099c _dispatch_sema4_wait + 28 2 libdispatch.dylib 0x195dd1050 _dispatch_semaphore_wait_slow + 132 3 libIlmThread.dylib 0x112a3b398 IlmThread_3_1::(anonymous namespace)::DefaultWorkerThread::run() + 64 4 libIlmThread.dylib 0x112a39fe4 void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct>>, void (IlmThread_3_1::Thread::*)(), IlmThread_3_1::Thread*>>(void*) + 64 5 libsystem_pthread.dylib 0x195f7ffa8 _pthread_start + 148 6 libsystem_pthread.dylib 0x195f7ada0 thread_start + 8 Thread 5: 0 libsystem_kernel.dylib 0x195f3fe90 semaphore_wait_trap + 8 1 libdispatch.dylib 0x195dd099c _dispatch_sema4_wait + 28 2 libdispatch.dylib 0x195dd1050 _dispatch_semaphore_wait_slow + 132 3 libIlmThread.dylib 0x112a3b398 IlmThread_3_1::(anonymous namespace)::DefaultWorkerThread::run() + 64 4 libIlmThread.dylib 0x112a39fe4 void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct>>, void (IlmThread_3_1::Thread::*)(), IlmThread_3_1::Thread*>>(void*) + 64 5 libsystem_pthread.dylib 0x195f7ffa8 _pthread_start + 148 6 libsystem_pthread.dylib 0x195f7ada0 thread_start + 8 Thread 6: 0 libsystem_kernel.dylib 0x195f3fe90 semaphore_wait_trap + 8 1 libdispatch.dylib 0x195dd099c _dispatch_sema4_wait + 28 2 libdispatch.dylib 0x195dd1050 _dispatch_semaphore_wait_slow + 132 3 libIlmThread.dylib 0x112a3b398 IlmThread_3_1::(anonymous namespace)::DefaultWorkerThread::run() + 64 4 libIlmThread.dylib 0x112a39fe4 void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct>>, void (IlmThread_3_1::Thread::*)(), IlmThread_3_1::Thread*>>(void*) + 64 5 libsystem_pthread.dylib 0x195f7ffa8 _pthread_start + 148 6 libsystem_pthread.dylib 0x195f7ada0 thread_start + 8 Thread 7: 0 libsystem_kernel.dylib 0x195f3fe90 semaphore_wait_trap + 8 1 libdispatch.dylib 0x195dd099c _dispatch_sema4_wait + 28 2 libdispatch.dylib 0x195dd1050 _dispatch_semaphore_wait_slow + 132 3 libIlmThread.dylib 0x112a3b398 IlmThread_3_1::(anonymous namespace)::DefaultWorkerThread::run() + 64 4 libIlmThread.dylib 0x112a39fe4 void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct>>, void (IlmThread_3_1::Thread::*)(), IlmThread_3_1::Thread*>>(void*) + 64 5 libsystem_pthread.dylib 0x195f7ffa8 _pthread_start + 148 6 libsystem_pthread.dylib 0x195f7ada0 thread_start + 8 Thread 8: 0 libsystem_kernel.dylib 0x195f3fe90 semaphore_wait_trap + 8 1 libdispatch.dylib 0x195dd099c _dispatch_sema4_wait + 28 2 libdispatch.dylib 0x195dd1050 _dispatch_semaphore_wait_slow + 132 3 libIlmThread.dylib 0x112a3b398 IlmThread_3_1::(anonymous namespace)::DefaultWorkerThread::run() + 64 4 libIlmThread.dylib 0x112a39fe4 void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct>>, void (IlmThread_3_1::Thread::*)(), IlmThread_3_1::Thread*>>(void*) + 64 5 libsystem_pthread.dylib 0x195f7ffa8 _pthread_start + 148 6 libsystem_pthread.dylib 0x195f7ada0 thread_start + 8 Thread 9: 0 libsystem_kernel.dylib 0x195f3fe90 semaphore_wait_trap + 8 1 libdispatch.dylib 0x195dd099c _dispatch_sema4_wait + 28 2 libdispatch.dylib 0x195dd1050 _dispatch_semaphore_wait_slow + 132 3 libIlmThread.dylib 0x112a3b398 IlmThread_3_1::(anonymous namespace)::DefaultWorkerThread::run() + 64 4 libIlmThread.dylib 0x112a39fe4 void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct>>, void (IlmThread_3_1::Thread::*)(), IlmThread_3_1::Thread*>>(void*) + 64 5 libsystem_pthread.dylib 0x195f7ffa8 _pthread_start + 148 6 libsystem_pthread.dylib 0x195f7ada0 thread_start + 8 Thread 10: 0 libsystem_pthread.dylib 0x195f7ad8c start_wqthread + 0 Thread 11: 0 libsystem_pthread.dylib 0x195f7ad8c start_wqthread + 0 Thread 12:: caulk.messenger.shared:17 0 libsystem_kernel.dylib 0x195f3fe90 semaphore_wait_trap + 8 1 caulk 0x19f59e024 caulk::semaphore::timed_wait(double) + 212 2 caulk 0x19f59ded8 caulk::concurrent::details::worker_thread::run() + 36 3 caulk 0x19f59dbc8 void* caulk::thread_proxy<std::__1::tuple<caulk::thread::attributes, void (caulk::concurrent::details::worker_thread::*)(), std::__1::tuple<caulk::concurrent::details::worker_thread*>>>(void*) + 96 4 libsystem_pthread.dylib 0x195f7ffa8 _pthread_start + 148 5 libsystem_pthread.dylib 0x195f7ada0 thread_start + 8 Thread 13:: com.apple.audio.IOThread.client 0 libsystem_kernel.dylib 0x195f3ff14 mach_msg2_trap + 8 1 libsystem_kernel.dylib 0x195f52240 mach_msg2_internal + 80 2 libsystem_kernel.dylib 0x195f48b78 mach_msg_overwrite + 604 3 libsystem_kernel.dylib 0x195f40290 mach_msg + 24 4 CoreAudio 0x198369624 HALB_MachPort::SendSimpleMessageWithSimpleReply(unsigned int, unsigned int, int, int&, bool, unsigned int) + 104 5 CoreAudio 0x198256d14 HALC_ProxyIOContext::IOWorkLoop() + 3516 6 CoreAudio 0x19825587c invocation function for block in HALC_ProxyIOContext::HALC_ProxyIOContext(unsigned int, unsigned int) + 116 7 CoreAudio 0x1983b8564 HALB_IOThread::Entry(void*) + 88 8 libsystem_pthread.dylib 0x195f7ffa8 _pthread_start + 148 9 libsystem_pthread.dylib 0x195f7ada0 thread_start + 8 Thread 14: 0 libsystem_kernel.dylib 0x195f3fe90 semaphore_wait_trap + 8 1 libtbb.dylib 0x112a75ffc rml::internal::thread_monitor::commit_wait(rml::internal::thread_monitor::cookie&) + 64 2 libtbb.dylib 0x112a75bb4 tbb::internal::rml::private_worker::run() + 420 3 libtbb.dylib 0x112a75a04 tbb::internal::rml::private_worker::thread_routine(void*) + 12 4 libsystem_pthread.dylib 0x195f7ffa8 _pthread_start + 148 5 libsystem_pthread.dylib 0x195f7ada0 thread_start + 8 Thread 15: 0 libsystem_kernel.dylib 0x195f3fe90 semaphore_wait_trap + 8 1 libtbb.dylib 0x112a75ffc rml::internal::thread_monitor::commit_wait(rml::internal::thread_monitor::cookie&) + 64 2 libtbb.dylib 0x112a75bb4 tbb::internal::rml::private_worker::run() + 420 3 libtbb.dylib 0x112a75a04 tbb::internal::rml::private_worker::thread_routine(void*) + 12 4 libsystem_pthread.dylib 0x195f7ffa8 _pthread_start + 148 5 libsystem_pthread.dylib 0x195f7ada0 thread_start + 8 Thread 16: 0 libsystem_kernel.dylib 0x195f3fe90 semaphore_wait_trap + 8 1 libtbb.dylib 0x112a75ffc rml::internal::thread_monitor::commit_wait(rml::internal::thread_monitor::cookie&) + 64 2 libtbb.dylib 0x112a75bb4 tbb::internal::rml::private_worker::run() + 420 3 libtbb.dylib 0x112a75a04 tbb::internal::rml::private_worker::thread_routine(void*) + 12 4 libsystem_pthread.dylib 0x195f7ffa8 _pthread_start + 148 5 libsystem_pthread.dylib 0x195f7ada0 thread_start + 8 Thread 17: 0 libsystem_kernel.dylib 0x195f3fe90 semaphore_wait_trap + 8 1 libtbb.dylib 0x112a75ffc rml::internal::thread_monitor::commit_wait(rml::internal::thread_monitor::cookie&) + 64 2 libtbb.dylib 0x112a75bb4 tbb::internal::rml::private_worker::run() + 420 3 libtbb.dylib 0x112a75a04 tbb::internal::rml::private_worker::thread_routine(void*) + 12 4 libsystem_pthread.dylib 0x195f7ffa8 _pthread_start + 148 5 libsystem_pthread.dylib 0x195f7ada0 thread_start + 8 Thread 18: 0 libsystem_kernel.dylib 0x195f3fe90 semaphore_wait_trap + 8 1 libtbb.dylib 0x112a75ffc rml::internal::thread_monitor::commit_wait(rml::internal::thread_monitor::cookie&) + 64 2 libtbb.dylib 0x112a75bb4 tbb::internal::rml::private_worker::run() + 420 3 libtbb.dylib 0x112a75a04 tbb::internal::rml::private_worker::thread_routine(void*) + 12 4 libsystem_pthread.dylib 0x195f7ffa8 _pthread_start + 148 5 libsystem_pthread.dylib 0x195f7ada0 thread_start + 8 Thread 19: 0 libsystem_kernel.dylib 0x195f3fe90 semaphore_wait_trap + 8 1 libtbb.dylib 0x112a75ffc rml::internal::thread_monitor::commit_wait(rml::internal::thread_monitor::cookie&) + 64 2 libtbb.dylib 0x112a75bb4 tbb::internal::rml::private_worker::run() + 420 3 libtbb.dylib 0x112a75a04 tbb::internal::rml::private_worker::thread_routine(void*) + 12 4 libsystem_pthread.dylib 0x195f7ffa8 _pthread_start + 148 5 libsystem_pthread.dylib 0x195f7ada0 thread_start + 8 Thread 20: 0 libsystem_kernel.dylib 0x195f3fe90 semaphore_wait_trap + 8 1 libtbb.dylib 0x112a75ffc rml::internal::thread_monitor::commit_wait(rml::internal::thread_monitor::cookie&) + 64 2 libtbb.dylib 0x112a75bb4 tbb::internal::rml::private_worker::run() + 420 3 libtbb.dylib 0x112a75a04 tbb::internal::rml::private_worker::thread_routine(void*) + 12 4 libsystem_pthread.dylib 0x195f7ffa8 _pthread_start + 148 5 libsystem_pthread.dylib 0x195f7ada0 thread_start + 8 Thread 21: 0 libsystem_kernel.dylib 0x195f3fe90 semaphore_wait_trap + 8 1 libtbb.dylib 0x112a75ffc rml::internal::thread_monitor::commit_wait(rml::internal::thread_monitor::cookie&) + 64 2 libtbb.dylib 0x112a75bb4 tbb::internal::rml::private_worker::run() + 420 3 libtbb.dylib 0x112a75a04 tbb::internal::rml::private_worker::thread_routine(void*) + 12 4 libsystem_pthread.dylib 0x195f7ffa8 _pthread_start + 148 5 libsystem_pthread.dylib 0x195f7ada0 thread_start + 8 Thread 22: 0 libsystem_kernel.dylib 0x195f3fe90 semaphore_wait_trap + 8 1 libtbb.dylib 0x112a75ffc rml::internal::thread_monitor::commit_wait(rml::internal::thread_monitor::cookie&) + 64 2 libtbb.dylib 0x112a75bb4 tbb::internal::rml::private_worker::run() + 420 3 libtbb.dylib 0x112a75a04 tbb::internal::rml::private_worker::thread_routine(void*) + 12 4 libsystem_pthread.dylib 0x195f7ffa8 _pthread_start + 148 5 libsystem_pthread.dylib 0x195f7ada0 thread_start + 8 Thread 23: 0 libsystem_pthread.dylib 0x195f7ad8c start_wqthread + 0 Thread 24:: com.apple.NSEventThread 0 libsystem_kernel.dylib 0x195f3ff14 mach_msg2_trap + 8 1 libsystem_kernel.dylib 0x195f52240 mach_msg2_internal + 80 2 libsystem_kernel.dylib 0x195f48b78 mach_msg_overwrite + 604 3 libsystem_kernel.dylib 0x195f40290 mach_msg + 24 4 CoreFoundation 0x19605e8b8 __CFRunLoopServiceMachPort + 160 5 CoreFoundation 0x19605d198 __CFRunLoopRun + 1208 6 CoreFoundation 0x19605c58c CFRunLoopRunSpecific + 612 7 AppKit 0x1993a6508 _NSEventThread + 172 8 libsystem_pthread.dylib 0x195f7ffa8 _pthread_start + 148 9 libsystem_pthread.dylib 0x195f7ada0 thread_start + 8 Thread 25: 0 libsystem_pthread.dylib 0x195f7ad8c start_wqthread + 0 Thread 26: 0 libsystem_pthread.dylib 0x195f7ad8c start_wqthread + 0 Thread 27: 0 libsystem_kernel.dylib 0x195f43710 __psynch_cvwait + 8 1 libsystem_pthread.dylib 0x195f80574 _pthread_cond_wait + 1232 2 libc++.1.dylib 0x195ea8ef0 std::__1::condition_variable::wait(std::__1::unique_lock<std::__1::mutex>&) + 28 3 Blender 0x104c34240 ccl::Session::wait() + 108 4 Blender 0x104865c88 ccl::BlenderSession::render(BL::Depsgraph&) + 2508 5 Blender 0x10485da2c ccl::render_func(_object*, _object*) + 160 6 Blender 0x109f40634 cfunction_call + 172 (methodobject.c:552) 7 Blender 0x109ef7a24 _PyObject_MakeTpCall + 360 (call.c:215) 8 Blender 0x109fdaaf4 call_function + 548 9 Blender 0x109fd7ff0 _PyEval_EvalFrameDefault + 25324 (ceval.c:4181) 10 Blender 0x109fd1bf8 _PyEval_EvalFrame + 24 (pycore_ceval.h:46) [inlined] 11 Blender 0x109fd1bf8 _PyEval_Vector + 164 (ceval.c:5065) 12 Blender 0x109fdaa0c call_function + 316 13 Blender 0x109fd7ff0 _PyEval_EvalFrameDefault + 25324 (ceval.c:4181) 14 Blender 0x109fd1bf8 _PyEval_EvalFrame + 24 (pycore_ceval.h:46) [inlined] 15 Blender 0x109fd1bf8 _PyEval_Vector + 164 (ceval.c:5065) 16 Blender 0x103809910 bpy_class_call + 1000 17 Blender 0x10376a408 engine_render + 120 18 Blender 0x103f1bea8 engine_render_view_layer(Render*, RenderEngine*, ViewLayer*, bool, bool) + 556 19 Blender 0x103f1ba50 RE_engine_render + 892 20 Blender 0x103f2093c do_render_full_pipeline(Render*) + 264 21 Blender 0x103f205b0 RE_RenderFrame + 356 22 Blender 0x10480eb0c render_startjob(void*, bool*, bool*, float*) + 92 23 Blender 0x10334e748 do_job_thread + 40 24 libsystem_pthread.dylib 0x195f7ffa8 _pthread_start + 148 25 libsystem_pthread.dylib 0x195f7ada0 thread_start + 8 Thread 28: 0 libsystem_pthread.dylib 0x195f7ad8c start_wqthread + 0 Thread 29: 0 libsystem_kernel.dylib 0x195f4350c __semwait_signal + 8 1 libsystem_c.dylib 0x195e242d0 nanosleep + 220 2 libc++.1.dylib 0x195eb6a18 std::__1::this_thread::sleep_for(std::__1::chrono::duration<long long, std::__1::ratio<1l, 1000000000l>> const&) + 84 3 Blender 0x1048ebc04 ccl::ShaderCache::get_best_pipeline(ccl::DeviceKernel, ccl::MetalDevice const*) + 112 4 Blender 0x1048ef3cc ccl::MetalDeviceQueue::enqueue(ccl::DeviceKernel, int, ccl::DeviceKernelArguments const&) + 1292 5 Blender 0x104caa778 ccl::ShaderEval::eval_gpu(ccl::Device*, ccl::ShaderEvalType, ccl::device_vector<ccl::KernelShaderEvalInput>&, ccl::device_vector<float>&, long long) + 256 6 Blender 0x104caa23c std::__1::__function::__func<ccl::ShaderEval::eval(ccl::ShaderEvalType, int, int, std::__1::function<int (ccl::device_vector<ccl::KernelShaderEvalInput>&)> const&, std::__1::function<void (ccl::device_vector<float>&)> const&)::$_0, std::__1::allocator<ccl::ShaderEval::eval(ccl::ShaderEvalType, int, int, std::__1::function<int (ccl::device_vector<ccl::KernelShaderEvalInput>&)> const&, std::__1::function<void (ccl::device_vector<float>&)> const&)::$_0>, void (ccl::Device*)>::operator()(ccl::Device*&&) + 596 7 Blender 0x1048bcf34 ccl::Device::foreach_device(std::__1::function<void (ccl::Device*)> const&) + 40 8 Blender 0x104ca9ecc ccl::ShaderEval::eval(ccl::ShaderEvalType, int, int, std::__1::function<int (ccl::device_vector<ccl::KernelShaderEvalInput>&)> const&, std::__1::function<void (ccl::device_vector<float>&)> const&) + 156 9 Blender 0x104b2cb64 ccl::GeometryManager::displace(ccl::Device*, ccl::Scene*, ccl::Mesh*, ccl::Progress&) + 452 10 Blender 0x104ad00ac ccl::GeometryManager::device_update(ccl::Device*, ccl::DeviceScene*, ccl::Scene*, ccl::Progress&) + 2696 11 Blender 0x104b4f3b4 ccl::Scene::device_update(ccl::Device*, ccl::Progress&) + 1548 12 Blender 0x104b50dc4 ccl::Scene::update(ccl::Progress&) + 148 13 Blender 0x104c34c5c ccl::Session::run_update_for_next_iteration() + 1184 14 Blender 0x104c342fc ccl::Session::run_main_render_loop() + 112 15 Blender 0x104c35218 ccl::Session::thread_render() + 252 16 Blender 0x104c33008 ccl::Session::thread_run() + 164 17 Blender 0x10798cc70 ccl::thread::run(void*) + 28 18 libsystem_pthread.dylib 0x195f7ffa8 _pthread_start + 148 19 libsystem_pthread.dylib 0x195f7ada0 thread_start + 8 Thread 30: 0 libsystem_pthread.dylib 0x195f7ad8c start_wqthread + 0 Thread 31: 0 libsystem_pthread.dylib 0x195f7ad8c start_wqthread + 0 Thread 32 Crashed:: Dispatch queue: MTLBinaryArchive 0 libdispatch.dylib 0x195dcf01c dispatch_release + 12 1 Metal 0x19f4229bc __121-[_MTLBinaryArchive(MTLBinaryArchiveInternal) newArchiverIdWithFunctionId:descriptor:bitcode:srcArchiverId:functionType:]_block_invoke + 548 2 libdispatch.dylib 0x195dd0400 _dispatch_client_callout + 20 3 libdispatch.dylib 0x195ddf97c _dispatch_lane_barrier_sync_invoke_and_complete + 56 4 Metal 0x19f422770 -[_MTLBinaryArchive(MTLBinaryArchiveInternal) newArchiverIdWithFunctionId:descriptor:bitcode:srcArchiverId:functionType:] + 188 5 Metal 0x19f4a80e0 -[MTLCompiler addExtraDataToAirntBinaryArchive:functionId:cachedData:] + 156 6 Metal 0x19f4a922c -[MTLCompiler compileFunctionRequestInternal:frameworkLinking:linkDataSize:reflectionOnly:completionHandler:] + 4120 7 AGXMetalG13X 0x1e2dfc0d0 void AGX::Compiler::compileProgram<AGX::ComputeProgramKey>(AGX::ComputeProgramKey const&, MTLCompileFunctionRequestData*, void (AGCDeserializedReply const&, NSObject<OS_dispatch_data>*, NSObject<OS_dispatch_data>*, NSObject<OS_dispatch_data>*, NSObject<OS_dispatch_data>*, NSObject<OS_dispatch_data>*, MTLCompilerError, NSString*, unsigned long long) block_pointer) + 568 8 AGXMetalG13X 0x1e2dfaaa8 AGX::UserCommonShaderFactory<AGX::G13::Encoders, AGX::G13::Classes, AGX::G13::ObjClasses>::createComputeProgramVariant(MTLComputePipelineDescriptor*, AGXG13XFamilyDevice*, unsigned long, AGXG13XFamilyBinaryArchive*, NSArray*, AGX::G13::ComputeProgram*, NSObject<OS_dispatch_data>*, bool, void (AGX::G13::ComputeProgramVariant*, NSMutableDictionary*, MTLCompilerError, NSString*) block_pointer) + 976 9 AGXMetalG13X 0x1e2dfa50c -[AGXG13XFamilyBinaryArchive addComputePipelineFunctionsWithDescriptor:options:error:] + 728 10 Blender 0x1048ee694 ccl::MetalKernelPipeline::compile()::$_2::operator()() const::'lambda'()::operator()() const + 64 11 Blender 0x1048ee504 ccl::MetalKernelPipeline::compile()::$_2::operator()() const + 564 12 Blender 0x1048ea3e4 ccl::MetalKernelPipeline::compile() + 4076 13 Blender 0x1048e8f8c ccl::ShaderCache::compile_thread_func(int) + 512 14 Blender 0x1048eb308 void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct>>, ccl::ShaderCache::load_kernel(ccl::DeviceKernel, ccl::MetalDevice*, ccl::MetalPipelineType)::$_1>>(void*) + 44 15 libsystem_pthread.dylib 0x195f7ffa8 _pthread_start + 148 16 libsystem_pthread.dylib 0x195f7ada0 thread_start + 8 Thread 33:: Dispatch queue: MTLBinaryArchive 0 libsystem_kernel.dylib 0x195f40968 __open + 8 1 libsystem_kernel.dylib 0x195f4ba84 open + 64 2 Foundation 0x196f9cde4 _NSReadBytesFromFileWithExtendedAttributes + 152 3 Foundation 0x196f9cc64 -[NSData(NSData) initWithContentsOfFile:options:maxLength:error:] + 132 4 Metal 0x19f4884a8 LoaderGlobalState::loadFile(NSURL*, NSError**) + 328 5 Metal 0x19f417d78 -[_MTLBinaryArchive loadFromURL:error:] + 244 6 Metal 0x19f41c6e8 __55-[_MTLBinaryArchive airntSerializeToURL:options:error:]_block_invoke_2 + 784 7 libdispatch.dylib 0x195dd0400 _dispatch_client_callout + 20 8 libdispatch.dylib 0x195ddf97c _dispatch_lane_barrier_sync_invoke_and_complete + 56 9 Metal 0x19f41c3c0 __55-[_MTLBinaryArchive airntSerializeToURL:options:error:]_block_invoke.188 + 504 10 Metal 0x19f4a6bdc __123-[MTLCompiler generateMachOWithID:binaryEntries:numEntries:machOSpecializedData:machOType:Path:platform:completionHandler:]_block_invoke + 96 11 Metal 0x19f45a6cc invocation function for block in MTLCompilerConnectionManagerPrivate::buildRequest(unsigned int, MTLCompilerRequest*, bool, void (MTLCompilerError, NSObject<OS_dispatch_data>*, char const*) block_pointer) + 92 12 Metal 0x19f458e1c invocation function for block in XPCCompilerConnection::BuildRequestInternal(MTLCompilerRequest*, char const*, NSObject<OS_dispatch_data>*, int, bool, void (unsigned int, void const*, unsigned long, char const*) block_pointer) + 532 13 Metal 0x19f3dc378 XPCCompilerConnection::BuildRequestInternal(MTLCompilerRequest*, char const*, NSObject<OS_dispatch_data>*, int, bool, void (unsigned int, void const*, unsigned long, char const*) block_pointer) + 1208 14 Metal 0x19f4595d4 invocation function for block in XPCCompilerConnection::BuildRequest(MTLCompilerRequest*, char const*, NSObject<OS_dispatch_data>*, int, bool, void (unsigned int, void const*, unsigned long, char const*) block_pointer) + 64 15 libdispatch.dylib 0x195dd0400 _dispatch_client_callout + 20 16 libdispatch.dylib 0x195ddf97c _dispatch_lane_barrier_sync_invoke_and_complete + 56 17 Metal 0x19f3dbe50 XPCCompilerConnection::BuildRequest(MTLCompilerRequest*, char const*, NSObject<OS_dispatch_data>*, int, bool, void (unsigned int, void const*, unsigned long, char const*) block_pointer) + 136 18 Metal 0x19f3dbc74 MTLCompilerConnectionManagerPrivate::buildRequest(unsigned int, MTLCompilerRequest*, bool, void (MTLCompilerError, NSObject<OS_dispatch_data>*, char const*) block_pointer) + 524 19 Metal 0x19f4a6a8c -[MTLCompiler generateMachOWithID:binaryEntries:numEntries:machOSpecializedData:machOType:Path:platform:completionHandler:] + 2236 20 Metal 0x19f41b680 __55-[_MTLBinaryArchive airntSerializeToURL:options:error:]_block_invoke + 728 21 libdispatch.dylib 0x195dd0400 _dispatch_client_callout + 20 22 libdispatch.dylib 0x195ddf97c _dispatch_lane_barrier_sync_invoke_and_complete + 56 23 Metal 0x19f41b294 -[_MTLBinaryArchive airntSerializeToURL:options:error:] + 360 24 Blender 0x1048ea4bc ccl::MetalKernelPipeline::compile() + 4292 25 Blender 0x1048e8f8c ccl::ShaderCache::compile_thread_func(int) + 512 26 Blender 0x1048eb308 void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct>>, ccl::ShaderCache::load_kernel(ccl::DeviceKernel, ccl::MetalDevice*, ccl::MetalPipelineType)::$_1>>(void*) + 44 27 libsystem_pthread.dylib 0x195f7ffa8 _pthread_start + 148 28 libsystem_pthread.dylib 0x195f7ada0 thread_start + 8 Thread 32 crashed with ARM Thread State (64-bit): x0: 0x0000000000000000 x1: 0x00006000000710e0 x2: 0x0000000000000001 x3: 0x0000600003518070 x4: 0x0000600003518080 x5: 0x0000000003200000 x6: 0x0000600003518000 x7: 0x0000000000000403 x8: 0x0000000000000400 x9: 0x00000000000003ff x10: 0x00000000000010e0 x11: 0x00000000000007fb x12: 0x00000000a617890e x13: 0x00000000000007fd x14: 0x00000000a637910f x15: 0x00000000a617890e x16: 0x0000000195dcf010 x17: 0x00000001f5f04270 x18: 0x0000000000000000 x19: 0x000000034cf01df8 x20: 0x0000000000000000 x21: 0x0000000000000000 x22: 0x0000000000000000 x23: 0x00006000000710e0 x24: 0x0000000167075460 x25: 0x00006000590d8300 x26: 0x0000000000000000 x27: 0x0000000000000002 x28: 0x0000000000000000 fp: 0x000000034cf01c80 lr: 0x487800019f4229bc sp: 0x000000034cf01c80 pc: 0x0000000195dcf01c cpsr: 0x60001000 far: 0x0000000000000000 esr: 0x92000006 (Data Abort) byte read Translation fault Not sure what ended up fixing the issue...