Skip to content
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

Merged
merged 15 commits into from
Nov 18, 2023

Conversation

NickLucche
Copy link
Contributor

@NickLucche NickLucche commented Sep 27, 2023

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.

Copy link
Contributor

@edgchen1 edgchen1 left a 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.

onnxruntime/core/providers/coreml/model/model.mm Outdated Show resolved Hide resolved
onnxruntime/core/providers/coreml/model/model.mm Outdated Show resolved Hide resolved
onnxruntime/core/providers/coreml/model/model.mm Outdated Show resolved Hide resolved
onnxruntime/core/providers/coreml/model/model.mm Outdated Show resolved Hide resolved
@edgchen1
Copy link
Contributor

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..?

I think it's fine to only handle the contiguous case for now. Not clear to me how to test that either.

@edgchen1
Copy link
Contributor

/azp run MacOS CI Pipeline

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@NickLucche
Copy link
Contributor Author

Thanks a lot for reviewing the PR!

@NickLucche
Copy link
Contributor Author

@microsoft-github-policy-service agree

@edgchen1
Copy link
Contributor

edgchen1 commented Oct 2, 2023

/azp run MacOS CI Pipeline

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

edgchen1
edgchen1 previously approved these changes Oct 3, 2023
@edgchen1
Copy link
Contributor

edgchen1 commented Oct 3, 2023

/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

@edgchen1
Copy link
Contributor

edgchen1 commented Oct 3, 2023

/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
Copy link

Azure Pipelines successfully started running 9 pipeline(s).

1 similar comment
@azure-pipelines
Copy link

Azure Pipelines successfully started running 9 pipeline(s).

@edgchen1
Copy link
Contributor

edgchen1 commented Oct 4, 2023

there are some errors from the MacOS CI build:

https://dev.azure.com/onnxruntime/onnxruntime/_build/results?buildId=1156472&view=logs&j=07136875-e4b3-5a15-ff50-026d13f57d01&t=ff34eec9-4cff-535b-345b-da5da417f512

/Users/runner/work/1/s/onnxruntime/core/providers/coreml/model/model.mm:177:21: error: comparison of integers of different signs: 'int' and 'NSUInteger' (aka 'unsigned long') [-Werror,-Wsign-compare]
  for (int i = 1; i < [shape count]; i++) batch_elems *= [shape[i] longLongValue];
                  ~ ^ ~~~~~~~~~~~~~
/Users/runner/work/1/s/onnxruntime/core/providers/coreml/model/model.mm:339:15: error: 'getBytesWithHandler:' is only available on macOS 12.3 or newer [-Werror,-Wunguarded-availability-new]
        [data getBytesWithHandler:^(const void* bytes, NSInteger size) {
              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Applications/Xcode_14.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.3.sdk/System/Library/Frameworks/CoreML.framework/Headers/MLMultiArray.h:125:1: note: 'getBytesWithHandler:' has been marked as being introduced in macOS 12.3 here, but the deployment target is macOS 10.14.0
- (void)getBytesWithHandler:(void (NS_NOESCAPE ^)(const void *bytes, NSInteger size))handler API_AVAILABLE(macos(12.3), ios(15.4), watchos(8.5), tvos(15.4)) NS_REFINED_FOR_SWIFT;
^
/Users/runner/work/1/s/onnxruntime/core/providers/coreml/model/model.mm:339:15: note: enclose 'getBytesWithHandler:' in an @available check to silence this warning
        [data getBytesWithHandler:^(const void* bytes, NSInteger size) {
              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/runner/work/1/s/onnxruntime/core/providers/coreml/model/model.mm:352:50: error: comparison of integers of different signs: 'int64_t' (aka 'long long') and 'const unsigned long' [-Werror,-Wsign-compare]
            ORT_RETURN_IF_NOT(coreml_buffer_size == output_data_byte_size,
                              ~~~~~~~~~~~~~~~~~~ ^  ~~~~~~~~~~~~~~~~~~~~~
/Users/runner/work/1/s/include/onnxruntime/core/common/common.h:202:19: note: expanded from macro 'ORT_RETURN_IF_NOT'
  ORT_RETURN_IF(!(condition), __VA_ARGS__)
                  ^~~~~~~~~
/Users/runner/work/1/s/include/onnxruntime/core/common/common.h:193:9: note: expanded from macro 'ORT_RETURN_IF'
    if (condition) {                                                                                           \
        ^~~~~~~~~
/Users/runner/work/1/s/onnxruntime/core/providers/coreml/model/model.mm:359:50: error: comparison of integers of different signs: 'int64_t' (aka 'long long') and 'const unsigned long' [-Werror,-Wsign-compare]
            ORT_RETURN_IF_NOT(coreml_buffer_size == output_data_byte_size,
                              ~~~~~~~~~~~~~~~~~~ ^  ~~~~~~~~~~~~~~~~~~~~~
/Users/runner/work/1/s/include/onnxruntime/core/common/common.h:202:19: note: expanded from macro 'ORT_RETURN_IF_NOT'
  ORT_RETURN_IF(!(condition), __VA_ARGS__)
                  ^~~~~~~~~
/Users/runner/work/1/s/include/onnxruntime/core/common/common.h:193:9: note: expanded from macro 'ORT_RETURN_IF'
    if (condition) {                                                                                           \
        ^~~~~~~~~
/Users/runner/work/1/s/onnxruntime/core/providers/coreml/model/model.mm:370:50: error: comparison of integers of different signs: 'int64_t' (aka 'long long') and 'unsigned long' [-Werror,-Wsign-compare]
            ORT_RETURN_IF_NOT(coreml_buffer_size == num_elements * sizeof(int32_t),
                              ~~~~~~~~~~~~~~~~~~ ^  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/runner/work/1/s/include/onnxruntime/core/common/common.h:202:19: note: expanded from macro 'ORT_RETURN_IF_NOT'
  ORT_RETURN_IF(!(condition), __VA_ARGS__)
                  ^~~~~~~~~
/Users/runner/work/1/s/include/onnxruntime/core/common/common.h:193:9: note: expanded from macro 'ORT_RETURN_IF'
    if (condition) {                                                                                           \
        ^~~~~~~~~
5 errors generated.

@NickLucche
Copy link
Contributor Author

I run the ci_build pipeline on my side, looks ok.
The only error to be addressed is this one:

'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 MacosArch). Could be good to additionally build on latest macOS anyway (I take that back if it's already being done).

@edgchen1
Copy link
Contributor

edgchen1 commented Oct 4, 2023

I run the ci_build pipeline on my side, looks ok. The only error to be addressed is this one:

'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 MacosArch). Could be good to additionally build on latest macOS anyway (I take that back if it's already being done).

I think the deployment target is specified here:

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?

@NickLucche
Copy link
Contributor Author

Hey, any news on the best strategy here? :)

@edgchen1
Copy link
Contributor

Hey, any news on the best strategy here? :)

Sorry for the delay. Following up with the team about it.

@edgchen1
Copy link
Contributor

/azp run Linux MIGraphX CI Pipeline, orttraining-amd-gpu-ci-pipeline

Copy link

Azure Pipelines successfully started running 2 pipeline(s).

Copy link

Azure Pipelines successfully started running 9 pipeline(s).

1 similar comment
Copy link

Azure Pipelines successfully started running 9 pipeline(s).

edgchen1
edgchen1 previously approved these changes Nov 17, 2023
@edgchen1
Copy link
Contributor

/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

@edgchen1
Copy link
Contributor

/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

@edgchen1
Copy link
Contributor

/azp run Linux MIGraphX CI Pipeline, orttraining-amd-gpu-ci-pipeline

Copy link

Azure Pipelines successfully started running 2 pipeline(s).

Copy link

Azure Pipelines successfully started running 9 pipeline(s).

1 similar comment
Copy link

Azure Pipelines successfully started running 9 pipeline(s).

Co-authored-by: Edward Chen <[email protected]>
@NickLucche NickLucche requested a review from edgchen1 November 17, 2023 19:22
@edgchen1
Copy link
Contributor

/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

@edgchen1
Copy link
Contributor

/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

@edgchen1
Copy link
Contributor

/azp run Linux MIGraphX CI Pipeline, orttraining-amd-gpu-ci-pipeline

Copy link

Azure Pipelines successfully started running 2 pipeline(s).

Copy link

Azure Pipelines successfully started running 9 pipeline(s).

1 similar comment
Copy link

Azure Pipelines successfully started running 9 pipeline(s).

@edgchen1 edgchen1 merged commit cbb85b4 into microsoft:main Nov 18, 2023
72 checks passed
@edgchen1
Copy link
Contributor

@NickLucche thanks for your contribution and your patience with this PR. glad we got it merged!

@NickLucche
Copy link
Contributor Author

Thank you for your help and patience! @edgchen1

kleiti pushed a commit to kleiti/onnxruntime that referenced this pull request Mar 22, 2024
…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]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[CoreML] Adapt to MLMultiArray.dataPointer being deprecated
3 participants