-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[CoreML] Adapt to MLMultiArray.dataPointer
deprecation
#17726
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks for the PR! had a few comments.
I think it's fine to only handle the contiguous case for now. Not clear to me how to test that either. |
/azp run MacOS CI Pipeline |
Azure Pipelines successfully started running 1 pipeline(s). |
Thanks a lot for reviewing the PR! |
@microsoft-github-policy-service agree |
/azp run MacOS CI Pipeline |
Azure Pipelines successfully started running 1 pipeline(s). |
/azp run Linux CPU CI Pipeline, Linux CPU Minimal Build E2E CI Pipeline, Linux GPU CI Pipeline, Linux GPU TensorRT CI Pipeline, Linux OpenVINO CI Pipeline, MacOS CI Pipeline, ONNX Runtime Web CI Pipeline, onnxruntime-binary-size-checks-ci-pipeline, Linux QNN CI Pipeline |
/azp run Windows CPU CI Pipeline, Windows GPU CI Pipeline, Windows GPU TensorRT CI Pipeline, Windows ARM64 QNN CI Pipeline, orttraining-linux-ci-pipeline, orttraining-linux-gpu-ci-pipeline, orttraining-ortmodule-distributed, ONNX Runtime React Native CI Pipeline, Windows x64 QNN CI Pipeline |
Azure Pipelines successfully started running 9 pipeline(s). |
1 similar comment
Azure Pipelines successfully started running 9 pipeline(s). |
there are some errors from the MacOS CI build:
|
I run the ci_build pipeline on my side, looks ok. 'getBytesWithHandler:' is only available on macOS 12.3 or newer
note: 'getBytesWithHandler:' has been marked as being introduced in macOS 12.3 here, but the deployment target is macOS 10.14.0 What's your suggestion here? Do we check the target version and use the deprecated method for older builds or..? I dug a bit into the CI too but I am not sure if the macos version is left to azure availability to decide atm (couldn't spot a macos version, just |
I think the deployment target is specified here: onnxruntime/tools/ci_build/github/azure-pipelines/templates/mac-cpu-packing-jobs.yml Line 34 in 1bc1157
If we need to support older deployment targets, we can do something like you said, conditionally use the deprecated method. We are building on a more recent MacOS version, but MACOSX_DEPLOYMENT_TARGET specifies the minimum version we support. @snnn @pranavsharma @skottmckay What's the minimum MacOS version that we need to support? |
Hey, any news on the best strategy here? :) |
Sorry for the delay. Following up with the team about it. |
/azp run Linux MIGraphX CI Pipeline, orttraining-amd-gpu-ci-pipeline |
Azure Pipelines successfully started running 2 pipeline(s). |
Azure Pipelines successfully started running 9 pipeline(s). |
1 similar comment
Azure Pipelines successfully started running 9 pipeline(s). |
/azp run Linux CPU CI Pipeline, Linux CPU Minimal Build E2E CI Pipeline, Linux GPU CI Pipeline, Linux GPU TensorRT CI Pipeline, Linux OpenVINO CI Pipeline, MacOS CI Pipeline, ONNX Runtime Web CI Pipeline, onnxruntime-binary-size-checks-ci-pipeline, Linux QNN CI Pipeline |
/azp run Windows CPU CI Pipeline, Windows GPU CI Pipeline, Windows GPU TensorRT CI Pipeline, Windows ARM64 QNN CI Pipeline, orttraining-linux-ci-pipeline, orttraining-linux-gpu-ci-pipeline, orttraining-ortmodule-distributed, ONNX Runtime React Native CI Pipeline, Windows x64 QNN CI Pipeline |
/azp run Linux MIGraphX CI Pipeline, orttraining-amd-gpu-ci-pipeline |
Azure Pipelines successfully started running 2 pipeline(s). |
Azure Pipelines successfully started running 9 pipeline(s). |
1 similar comment
Azure Pipelines successfully started running 9 pipeline(s). |
Co-authored-by: Edward Chen <[email protected]>
/azp run Linux CPU CI Pipeline, Linux CPU Minimal Build E2E CI Pipeline, Linux GPU CI Pipeline, Linux GPU TensorRT CI Pipeline, Linux OpenVINO CI Pipeline, MacOS CI Pipeline, ONNX Runtime Web CI Pipeline, onnxruntime-binary-size-checks-ci-pipeline, Linux QNN CI Pipeline |
/azp run Windows CPU CI Pipeline, Windows GPU CI Pipeline, Windows GPU TensorRT CI Pipeline, Windows ARM64 QNN CI Pipeline, orttraining-linux-ci-pipeline, orttraining-linux-gpu-ci-pipeline, orttraining-ortmodule-distributed, ONNX Runtime React Native CI Pipeline, Windows x64 QNN CI Pipeline |
/azp run Linux MIGraphX CI Pipeline, orttraining-amd-gpu-ci-pipeline |
Azure Pipelines successfully started running 2 pipeline(s). |
Azure Pipelines successfully started running 9 pipeline(s). |
1 similar comment
Azure Pipelines successfully started running 9 pipeline(s). |
@NickLucche thanks for your contribution and your patience with this PR. glad we got it merged! |
Thank you for your help and patience! @edgchen1 |
…7726) ### Description This PR addresses microsoft#17652. The deprecated `MLMultiArray.dataPointer` is replaced with `.getBytesWithHandler`, as suggested by the docs. For now, I am only checking that the output `MLMultiArray` is contiguous, returning unsupported operation when that is not the case. I think this is already better than what we have right now, so we can block unsafe calls to `.dataPointer` (if any..). I would be happy to implement the handling of the non-contiguous case (replacing `memcpy` for such cases) as suggested by @edgchen1, but I am not sure how to reproduce that case to add a corresponding unit-test. Would we have to define a custom `MLCustomLayer` to get a non-contiguous output from a model..? ### Motivation and Context Fix microsoft#17652. --------- Co-authored-by: nicolo-lucchesi <[email protected]> Co-authored-by: Edward Chen <[email protected]>
Description
This PR addresses #17652.
The deprecated
MLMultiArray.dataPointer
is replaced with.getBytesWithHandler
, as suggested by the docs.For now, I am only checking that the output
MLMultiArray
is contiguous, returning unsupported operation when that is not the case.I think this is already better than what we have right now, so we can block unsafe calls to
.dataPointer
(if any..).I would be happy to implement the handling of the non-contiguous case (replacing
memcpy
for such cases) as suggested by @edgchen1, but I am not sure how to reproduce that case to add a corresponding unit-test.Would we have to define a custom
MLCustomLayer
to get a non-contiguous output from a model..?Motivation and Context
Fix #17652.