Move x86 binaries builder to macos-12 to enable MPS build #77662

albanD · 2022-05-17T17:31:27Z

Stack from ghstack:

-> Move x86 binaries builder to macos-12 to enable MPS build #77662

[ghstack-poisoned]

facebook-github-bot · 2022-05-17T17:31:33Z

🔗 Helpful links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/77662
📄 Preview Python docs built from this PR
📄 Preview C++ docs built from this PR
❓Need help or want to give feedback on the CI? Visit our office hours
↩️ [fb-only] Re-run with SSH instructions

❌ 1 New Failures

As of commit ad4da3a (more details on the Dr. CI page):

Expand to see more

1/1 failures introduced in this PR

🕵️ 1 new failure recognized by patterns

The following CI failures do not appear to be due to upstream breakages

macos-binary-wheel / wheel-py3_8-cpu-build (1/1)

Step: "Run actions/upload-artifact@v2" (full log | diagnosis details | 🔁 rerun)

2022-05-18T18:59:44.2899790Z ##[error]No files ...rk/_temp/artifacts. No artifacts will be uploaded.

2022-05-18T18:59:35.4696100Z   DESIRED_CUDA: cpu
2022-05-18T18:59:35.4697200Z   GPU_ARCH_TYPE: cpu
2022-05-18T18:59:35.4698300Z   DESIRED_PYTHON: 3.8
2022-05-18T18:59:35.4701860Z   AWS_ACCESS_KEY_ID: ***
2022-05-18T18:59:35.4703000Z   AWS_SECRET_ACCESS_KEY: ***
2022-05-18T18:59:35.4704030Z   BINARY_ENV_FILE: /Users/runner/work/_temp/env
2022-05-18T18:59:35.4705190Z   PYTORCH_FINAL_PACKAGE_DIR: /Users/runner/work/_temp/artifacts
2022-05-18T18:59:35.4706110Z   MAC_PACKAGE_WORK_DIR: /Users/runner/work/_temp
2022-05-18T18:59:35.4707180Z   SCCACHE_BUCKET: ossci-compiler-cache-circleci-v2
2022-05-18T18:59:35.4707930Z ##[endgroup]
2022-05-18T18:59:44.2899790Z ##[error]No files were found with the provided path: /Users/runner/work/_temp/artifacts. No artifacts will be uploaded.
2022-05-18T18:59:45.0540620Z Post job cleanup.
2022-05-18T18:59:50.5768590Z [command]/usr/local/bin/git version
2022-05-18T18:59:51.0227860Z git version 2.36.1
2022-05-18T18:59:51.4340600Z [command]/usr/local/bin/git config --local --name-only --get-regexp core\.sshCommand
2022-05-18T18:59:51.7438760Z [command]/usr/local/bin/git submodule foreach --recursive git config --local --name-only --get-regexp 'core\.sshCommand' && git config --local --unset-all 'core.sshCommand' || :
2022-05-18T18:59:55.4644370Z [command]/usr/local/bin/git config --local --name-only --get-regexp http\.https\:\/\/github\.com\/\.extraheader
2022-05-18T18:59:55.6703140Z http.https://github.com/.extraheader
2022-05-18T18:59:55.6994240Z [command]/usr/local/bin/git config --local --unset-all http.https://github.com/.extraheader
2022-05-18T18:59:55.9430640Z [command]/usr/local/bin/git submodule foreach --recursive git config --local --name-only --get-regexp 'http\.https\:\/\/github\.com\/\.extraheader' && git config --local --unset-all 'http.https://github.com/.extraheader' || :
2022-05-18T18:59:58.6633990Z Post job cleanup.

This comment was automatically generated by Dr. CI (expand for details).

Please report bugs/suggestions to the (internal) Dr. CI Users group.

Click here to manually regenerate this comment.

[ghstack-poisoned]

ghstack-source-id: 3d6192f Pull Request resolved: #77662

albanD · 2022-05-18T12:52:20Z

Testing the binaries on Bigsur 11.6.5 leads to a segfault when import torch. The current nightly do work just fine on the same machine.

Collect env of the failing machine:

PyTorch version: 1.12.0.dev20220518
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: macOS 11.6.5 (x86_64)
GCC version: Could not collect
Clang version: 13.0.0 (clang-1300.0.29.30)
CMake version: Could not collect
Libc version: N/A

Python version: 3.10.4 (main, Apr 26 2022, 19:43:24) [Clang 13.0.0 (clang-1300.0.29.30)] (64-bit runtime)
Python platform: macOS-11.6.5-x86_64-i386-64bit
Is CUDA available: False
CUDA runtime version: No CUDA
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] torch==1.12.0.dev20220518
[conda] Could not collect

…able MPS build" [ghstack-poisoned]

albanD · 2022-05-18T14:58:47Z

Trying to weak link Foundation framework to see if that helps.

ghstack-source-id: b1c95d2 Pull Request resolved: #77662

albanD · 2022-05-19T21:56:54Z

We can't reproduce this segfault locally. So trying to merge this and see if we can get more info from broader testing on nightly.

albanD · 2022-05-19T21:57:00Z

@pytorchbot merge this please

github-actions · 2022-05-19T23:45:35Z

Hey @albanD.
You've committed this PR, but it does not have both a 'release notes: ...' and 'topics: ...' label. Please add one of each to the PR. The 'release notes: ...' label should represent the part of PyTorch that this PR changes (fx, autograd, distributed, etc) and the 'topics: ...' label should represent the kind of PR it is (not user facing, new feature, bug fix, perf improvement, etc). The list of valid labels can be found here for the 'release notes: ...' and here for the 'topics: ...'.
For changes that are 'topic: not user facing' there is no need for a release notes label.

Summary: Pull Request resolved: #77662 Approved by: https://github.com/seemethere Test Plan: contbuild & OSS CI, see https://hud.pytorch.org/commit/pytorch/pytorch/fd121dfeec4895a61372d35b96f3d645ab1e73dd Reviewed By: seemethere Differential Revision: D36537753 Pulled By: albanD fbshipit-source-id: c1737a6f16eeec5d8a39ce1065c7e0bcd83bd71c

datumbox · 2022-05-23T12:51:32Z

@albanD @seemethere We are observing breakages on TorchVision for the macOS builds and suspect this PR might be related. See pytorch/vision#6070

pmeier · 2022-05-23T13:00:23Z

Here is a workflow on GitHub Actions that does nothing more than installing PyTorch and try to import it: https://github.com/pytorch/vision/runs/6555576108. It runs on macos-latest, which is macOS Big Sur 11 . Switching to macos-12 eliminates the error: https://github.com/pytorch/vision/runs/6555658933

Currently all of torchvision's CI infrastructure is based on macos-11 and thus is completely broken.

albanD · 2022-05-23T13:38:42Z

Hi,

This is very concerning for sure.
We will revert this. Looking into what is the right way to do it.

This prevents `import torch` accidentally crash on machines with no metal devices Should prevent crashes reported in #77662 (comment) and https://github.com/pytorch/functorch/runs/6560056366?check_suite_focus=true Backtrace to the crash: ``` (lldb) bt * thread #1, stop reason = signal SIGSTOP * frame #0: 0x00007fff7202be57 libobjc.A.dylib`objc_msgSend + 23 frame #1: 0x000000010fd9f524 libtorch_cpu.dylib`at::mps::HeapAllocator::MPSHeapAllocatorImpl::MPSHeapAllocatorImpl() + 436 frame #2: 0x000000010fda011d libtorch_cpu.dylib`_GLOBAL__sub_I_MPSAllocator.mm + 125 frame #3: 0x000000010ada81e3 dyld`ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) + 535 frame #4: 0x000000010ada85ee dyld`ImageLoaderMachO::doInitialization(ImageLoader::LinkContext const&) + 40(lldb) up frame #1: 0x000000010fd9f524 libtorch_cpu.dylib`at::mps::HeapAllocator::MPSHeapAllocatorImpl::MPSHeapAllocatorImpl() + 436 libtorch_cpu.dylib`at::mps::HeapAllocator::MPSHeapAllocatorImpl::MPSHeapAllocatorImpl: -> 0x10fd9f524 <+436>: movq %rax, 0x1b0(%rbx) 0x10fd9f52b <+443>: movw $0x0, 0x1b8(%rbx) 0x10fd9f534 <+452>: addq $0x8, %rsp 0x10fd9f538 <+456>: popq %rbx (lldb) disassemble ... 0x10fd9f514 <+420>: movq 0xf19ad15(%rip), %rsi ; "maxBufferLength" 0x10fd9f51b <+427>: movq %r14, %rdi 0x10fd9f51e <+430>: callq *0xeaa326c(%rip) ; (void *)0x00007fff7202be40: objc_msgSend ``` which corresponds to `[m_device maxBufferLength]` call, where `m_device` is not initialized in https://github.com/pytorch/pytorch/blob/2ae3c59e4bcb8e6e75b4a942cacc2d338c88e609/aten/src/ATen/mps/MPSAllocator.h#L171

This prevents `import torch` accidentally crash on machines with no metal devices Should prevent crashes reported in #77662 (comment) and https://github.com/pytorch/functorch/runs/6560056366?check_suite_focus=true Backtrace to the crash: ``` (lldb) bt * thread #1, stop reason = signal SIGSTOP * frame #0: 0x00007fff7202be57 libobjc.A.dylib`objc_msgSend + 23 frame #1: 0x000000010fd9f524 libtorch_cpu.dylib`at::mps::HeapAllocator::MPSHeapAllocatorImpl::MPSHeapAllocatorImpl() + 436 frame #2: 0x000000010fda011d libtorch_cpu.dylib`_GLOBAL__sub_I_MPSAllocator.mm + 125 frame #3: 0x000000010ada81e3 dyld`ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) + 535 frame #4: 0x000000010ada85ee dyld`ImageLoaderMachO::doInitialization(ImageLoader::LinkContext const&) + 40(lldb) up frame #1: 0x000000010fd9f524 libtorch_cpu.dylib`at::mps::HeapAllocator::MPSHeapAllocatorImpl::MPSHeapAllocatorImpl() + 436 libtorch_cpu.dylib`at::mps::HeapAllocator::MPSHeapAllocatorImpl::MPSHeapAllocatorImpl: -> 0x10fd9f524 <+436>: movq %rax, 0x1b0(%rbx) 0x10fd9f52b <+443>: movw $0x0, 0x1b8(%rbx) 0x10fd9f534 <+452>: addq $0x8, %rsp 0x10fd9f538 <+456>: popq %rbx (lldb) disassemble ... 0x10fd9f514 <+420>: movq 0xf19ad15(%rip), %rsi ; "maxBufferLength" 0x10fd9f51b <+427>: movq %r14, %rdi 0x10fd9f51e <+430>: callq *0xeaa326c(%rip) ; (void *)0x00007fff7202be40: objc_msgSend ``` which corresponds to `[m_device maxBufferLength]` call, where `m_device` is not initialized in https://github.com/pytorch/pytorch/blob/2ae3c59e4bcb8e6e75b4a942cacc2d338c88e609/aten/src/ATen/mps/MPSAllocator.h#L171 Pull Request resolved: #78136 Approved by: https://github.com/seemethere

…78136) This prevents `import torch` accidentally crash on machines with no metal devices Should prevent crashes reported in pytorch#77662 (comment) and https://github.com/pytorch/functorch/runs/6560056366?check_suite_focus=true Backtrace to the crash: ``` (lldb) bt * thread pytorch#1, stop reason = signal SIGSTOP * frame #0: 0x00007fff7202be57 libobjc.A.dylib`objc_msgSend + 23 frame pytorch#1: 0x000000010fd9f524 libtorch_cpu.dylib`at::mps::HeapAllocator::MPSHeapAllocatorImpl::MPSHeapAllocatorImpl() + 436 frame pytorch#2: 0x000000010fda011d libtorch_cpu.dylib`_GLOBAL__sub_I_MPSAllocator.mm + 125 frame pytorch#3: 0x000000010ada81e3 dyld`ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) + 535 frame pytorch#4: 0x000000010ada85ee dyld`ImageLoaderMachO::doInitialization(ImageLoader::LinkContext const&) + 40(lldb) up frame pytorch#1: 0x000000010fd9f524 libtorch_cpu.dylib`at::mps::HeapAllocator::MPSHeapAllocatorImpl::MPSHeapAllocatorImpl() + 436 libtorch_cpu.dylib`at::mps::HeapAllocator::MPSHeapAllocatorImpl::MPSHeapAllocatorImpl: -> 0x10fd9f524 <+436>: movq %rax, 0x1b0(%rbx) 0x10fd9f52b <+443>: movw $0x0, 0x1b8(%rbx) 0x10fd9f534 <+452>: addq $0x8, %rsp 0x10fd9f538 <+456>: popq %rbx (lldb) disassemble ... 0x10fd9f514 <+420>: movq 0xf19ad15(%rip), %rsi ; "maxBufferLength" 0x10fd9f51b <+427>: movq %r14, %rdi 0x10fd9f51e <+430>: callq *0xeaa326c(%rip) ; (void *)0x00007fff7202be40: objc_msgSend ``` which corresponds to `[m_device maxBufferLength]` call, where `m_device` is not initialized in https://github.com/pytorch/pytorch/blob/2ae3c59e4bcb8e6e75b4a942cacc2d338c88e609/aten/src/ATen/mps/MPSAllocator.h#L171 Pull Request resolved: pytorch#78136 Approved by: https://github.com/seemethere

…78204) This prevents `import torch` accidentally crash on machines with no metal devices Should prevent crashes reported in #77662 (comment) and https://github.com/pytorch/functorch/runs/6560056366?check_suite_focus=true Backtrace to the crash: ``` (lldb) bt * thread #1, stop reason = signal SIGSTOP * frame #0: 0x00007fff7202be57 libobjc.A.dylib`objc_msgSend + 23 frame #1: 0x000000010fd9f524 libtorch_cpu.dylib`at::mps::HeapAllocator::MPSHeapAllocatorImpl::MPSHeapAllocatorImpl() + 436 frame #2: 0x000000010fda011d libtorch_cpu.dylib`_GLOBAL__sub_I_MPSAllocator.mm + 125 frame #3: 0x000000010ada81e3 dyld`ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) + 535 frame #4: 0x000000010ada85ee dyld`ImageLoaderMachO::doInitialization(ImageLoader::LinkContext const&) + 40(lldb) up frame #1: 0x000000010fd9f524 libtorch_cpu.dylib`at::mps::HeapAllocator::MPSHeapAllocatorImpl::MPSHeapAllocatorImpl() + 436 libtorch_cpu.dylib`at::mps::HeapAllocator::MPSHeapAllocatorImpl::MPSHeapAllocatorImpl: -> 0x10fd9f524 <+436>: movq %rax, 0x1b0(%rbx) 0x10fd9f52b <+443>: movw $0x0, 0x1b8(%rbx) 0x10fd9f534 <+452>: addq $0x8, %rsp 0x10fd9f538 <+456>: popq %rbx (lldb) disassemble ... 0x10fd9f514 <+420>: movq 0xf19ad15(%rip), %rsi ; "maxBufferLength" 0x10fd9f51b <+427>: movq %r14, %rdi 0x10fd9f51e <+430>: callq *0xeaa326c(%rip) ; (void *)0x00007fff7202be40: objc_msgSend ``` which corresponds to `[m_device maxBufferLength]` call, where `m_device` is not initialized in https://github.com/pytorch/pytorch/blob/2ae3c59e4bcb8e6e75b4a942cacc2d338c88e609/aten/src/ATen/mps/MPSAllocator.h#L171 Pull Request resolved: #78136 Approved by: https://github.com/seemethere Co-authored-by: Nikita Shulga <[email protected]>

…78136) Summary: This prevents `import torch` accidentally crash on machines with no metal devices Should prevent crashes reported in #77662 (comment) and https://github.com/pytorch/functorch/runs/6560056366?check_suite_focus=true Backtrace to the crash: ``` (lldb) bt * thread #1, stop reason = signal SIGSTOP * frame #0: 0x00007fff7202be57 libobjc.A.dylib`objc_msgSend + 23 frame #1: 0x000000010fd9f524 libtorch_cpu.dylib`at::mps::HeapAllocator::MPSHeapAllocatorImpl::MPSHeapAllocatorImpl() + 436 frame #2: 0x000000010fda011d libtorch_cpu.dylib`_GLOBAL__sub_I_MPSAllocator.mm + 125 frame #3: 0x000000010ada81e3 dyld`ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) + 535 frame #4: 0x000000010ada85ee dyld`ImageLoaderMachO::doInitialization(ImageLoader::LinkContext const&) + 40(lldb) up frame #1: 0x000000010fd9f524 libtorch_cpu.dylib`at::mps::HeapAllocator::MPSHeapAllocatorImpl::MPSHeapAllocatorImpl() + 436 libtorch_cpu.dylib`at::mps::HeapAllocator::MPSHeapAllocatorImpl::MPSHeapAllocatorImpl: -> 0x10fd9f524 <+436>: movq %rax, 0x1b0(%rbx) 0x10fd9f52b <+443>: movw $0x0, 0x1b8(%rbx) 0x10fd9f534 <+452>: addq $0x8, %rsp 0x10fd9f538 <+456>: popq %rbx (lldb) disassemble ... 0x10fd9f514 <+420>: movq 0xf19ad15(%rip), %rsi ; "maxBufferLength" 0x10fd9f51b <+427>: movq %r14, %rdi 0x10fd9f51e <+430>: callq *0xeaa326c(%rip) ; (void *)0x00007fff7202be40: objc_msgSend ``` which corresponds to `[m_device maxBufferLength]` call, where `m_device` is not initialized in https://github.com/pytorch/pytorch/blob/2ae3c59e4bcb8e6e75b4a942cacc2d338c88e609/aten/src/ATen/mps/MPSAllocator.h#L171 Pull Request resolved: #78136 Approved by: https://github.com/seemethere Test Plan: contbuild & OSS CI, see https://hud.pytorch.org/commit/pytorch/pytorch/c7ce4fcc619fab5c82071eac934b505b396ee015 Reviewed By: mehtanirav Differential Revision: D36633657 Pulled By: malfet fbshipit-source-id: 535c94ab2ef7cc80e22a5086e0d12453a899f53a

This prevents `import torch` accidentally crash on machines with no metal devices Should prevent crashes reported in #77662 (comment) and https://github.com/pytorch/functorch/runs/6560056366?check_suite_focus=true Backtrace to the crash: ``` (lldb) bt * thread #1, stop reason = signal SIGSTOP * frame #0: 0x00007fff7202be57 libobjc.A.dylib`objc_msgSend + 23 frame #1: 0x000000010fd9f524 libtorch_cpu.dylib`at::mps::HeapAllocator::MPSHeapAllocatorImpl::MPSHeapAllocatorImpl() + 436 frame #2: 0x000000010fda011d libtorch_cpu.dylib`_GLOBAL__sub_I_MPSAllocator.mm + 125 frame #3: 0x000000010ada81e3 dyld`ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) + 535 frame #4: 0x000000010ada85ee dyld`ImageLoaderMachO::doInitialization(ImageLoader::LinkContext const&) + 40(lldb) up frame #1: 0x000000010fd9f524 libtorch_cpu.dylib`at::mps::HeapAllocator::MPSHeapAllocatorImpl::MPSHeapAllocatorImpl() + 436 libtorch_cpu.dylib`at::mps::HeapAllocator::MPSHeapAllocatorImpl::MPSHeapAllocatorImpl: -> 0x10fd9f524 <+436>: movq %rax, 0x1b0(%rbx) 0x10fd9f52b <+443>: movw $0x0, 0x1b8(%rbx) 0x10fd9f534 <+452>: addq $0x8, %rsp 0x10fd9f538 <+456>: popq %rbx (lldb) disassemble ... 0x10fd9f514 <+420>: movq 0xf19ad15(%rip), %rsi ; "maxBufferLength" 0x10fd9f51b <+427>: movq %r14, %rdi 0x10fd9f51e <+430>: callq *0xeaa326c(%rip) ; (void *)0x00007fff7202be40: objc_msgSend ``` which corresponds to `[m_device maxBufferLength]` call, where `m_device` is not initialized in https://github.com/pytorch/pytorch/blob/2ae3c59e4bcb8e6e75b4a942cacc2d338c88e609/aten/src/ATen/mps/MPSAllocator.h#L171 Pull Request resolved: #78136 Approved by: https://github.com/seemethere

malfet · 2022-05-25T23:14:39Z

Just to close on this one: crashes were fixed by #78136

Move x86 binaries builder to macos-12 to enable MPS build

51b264e

[ghstack-poisoned]

albanD requested review from atalman, janeyx99 and seemethere as code owners May 17, 2022 17:31

This was referenced May 17, 2022

Fix MPS interaction with autograd engine #77644

Closed

Migrate x86 trunk build/test to macos12 #77645

Closed

Migrate cross compilation trunk test to use macos12 to build MPS #77647

Closed

facebook-github-bot added the cla signed label May 17, 2022

albanD added ciflow/binaries_conda ciflow/binaries_wheel Trigger binary build and upload jobs for wheel on the PR labels May 17, 2022

seemethere approved these changes May 17, 2022

View reviewed changes

Update on "Move x86 binaries builder to macos-12 to enable MPS build"

d31f88b

[ghstack-poisoned]

albanD added a commit that referenced this pull request May 17, 2022

Move x86 binaries builder to macos-12 to enable MPS build

4cbc22b

ghstack-source-id: 3d6192f Pull Request resolved: #77662

albanD changed the title ~~Move x86 binaries builder to macos-12 to enable MPS build~~ [DO NOT MERGE] Move x86 binaries builder to macos-12 to enable MPS build May 18, 2022

Update on "[DO NOT MERGE] Move x86 binaries builder to macos-12 to en…

ad4da3a

…able MPS build" [ghstack-poisoned]

albanD added a commit that referenced this pull request May 18, 2022

Move x86 binaries builder to macos-12 to enable MPS build

beeefae

ghstack-source-id: b1c95d2 Pull Request resolved: #77662

This was referenced May 18, 2022

Some operation are not implemented when using mps backend #77754

Closed

[DO NOT MERGE] Test x86 macos runner #77403

Closed

When will the amd gpu version for mac be released？ #77833

Closed

pytorchmergebot added the Merged label May 19, 2022

pytorchmergebot closed this in fd121df May 19, 2022

albanD changed the title ~~[DO NOT MERGE] Move x86 binaries builder to macos-12 to enable MPS build~~ Move x86 binaries builder to macos-12 to enable MPS build May 19, 2022

albanD added the topic: not user facing topic category label May 20, 2022

pmeier mentioned this pull request May 23, 2022

MacOS unittest and binary jobs failing pytorch/vision#6070

Closed

facebook-github-bot deleted the gh/albanD/98/head branch May 23, 2022 14:17

malfet mentioned this pull request May 23, 2022

[MPS] Initialize MPSDevice::_mtl_device property to nil #78136

Closed

atalman mentioned this pull request May 24, 2022

[MPS] Initialize MPSDevice::_mtl_device property to nil (#78136) #78204

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Move x86 binaries builder to macos-12 to enable MPS build #77662

Move x86 binaries builder to macos-12 to enable MPS build #77662

Uh oh!

albanD commented May 17, 2022 •

edited

Loading

Uh oh!

facebook-github-bot commented May 17, 2022 •

edited

Loading

🕵️ 1 new failure recognized by patterns

macos-binary-wheel / wheel-py3_8-cpu-build (1/1)

Uh oh!

albanD commented May 18, 2022

Uh oh!

albanD commented May 18, 2022

Uh oh!

albanD commented May 19, 2022

Uh oh!

albanD commented May 19, 2022

Uh oh!

github-actions bot commented May 19, 2022

Uh oh!

datumbox commented May 23, 2022 •

edited

Loading

Uh oh!

pmeier commented May 23, 2022

Uh oh!

albanD commented May 23, 2022

Uh oh!

malfet commented May 25, 2022

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants

Move x86 binaries builder to macos-12 to enable MPS build #77662

Move x86 binaries builder to macos-12 to enable MPS build #77662

Uh oh!

Conversation

albanD commented May 17, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

facebook-github-bot commented May 17, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🔗 Helpful links

❌ 1 New Failures

🕵️ 1 new failure recognized by patterns

macos-binary-wheel / wheel-py3_8-cpu-build (1/1)

Uh oh!

albanD commented May 18, 2022

Uh oh!

albanD commented May 18, 2022

Uh oh!

albanD commented May 19, 2022

Uh oh!

albanD commented May 19, 2022

Uh oh!

github-actions bot commented May 19, 2022

Uh oh!

datumbox commented May 23, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

pmeier commented May 23, 2022

Uh oh!

albanD commented May 23, 2022

Uh oh!

malfet commented May 25, 2022

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants

albanD commented May 17, 2022 •

edited

Loading

facebook-github-bot commented May 17, 2022 •

edited

Loading

datumbox commented May 23, 2022 •

edited

Loading