Skip to content

[XNNPACK] support building xnnpack EP for IOS#13461

Merged
wejoncy merged 24 commits intomainfrom
jicwen/xnnpack_in_ios_build
Oct 28, 2022
Merged

[XNNPACK] support building xnnpack EP for IOS#13461
wejoncy merged 24 commits intomainfrom
jicwen/xnnpack_in_ios_build

Conversation

@wejoncy
Copy link
Contributor

@wejoncy wejoncy commented Oct 26, 2022

Description

support building xnnpack for IOS

Motivation and Context

@wejoncy wejoncy requested a review from a team October 26, 2022 04:21
@wejoncy wejoncy changed the title Jicwen/xnnpack in ios build [XNNPACK] support building for IOS Oct 26, 2022
@wejoncy wejoncy changed the title [XNNPACK] support building for IOS [XNNPACK] support building xnnpack EP for IOS Oct 26, 2022
--parallel
displayName: (CoreML EP) Build onnxruntime for iOS x86_64 and run tests using simulator

- job: iOS_CI_XNNPACK_on_Mac
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we really need to run this job for every pull request? We have limited macOS machines available, and this build pipeline already takes long.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What if this job will be running when we trigged it or merged it into main branch

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That would be better.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If ORT has 10 cmake options, then there would be 2^10=1024 different combinations. Our build pipelines can't cover all of them, and we have far more than 10 build options(or probably more than 100). So I suggest focusing on the things we ship. For example, if every iOS package we release contains this XNNPack EP, then we may consider to adjust our pull request pipelines to match it. Meanwhile, you may have extra pipelines to test the combinations that you think are important, but because of resource limitations we can't trigger all such pipelines for all pull requests.

Copy link
Contributor Author

@wejoncy wejoncy Oct 27, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this way, maybe we can combine multi build pipelines into one for pull-request. Take IOS-build as example, we can only build once for (CPU-ep,CORE-ep,XNNPACK-ep), How do you think?

When a PR merged, all seperate pipelines are triggered at that time.

variables:
MACOSX_DEPLOYMENT_TARGET: '10.14'
timeoutInMinutes: 100
condition: or(eq('${{parameters.BuildXnnpack}}', 'true'), eq(variables['Build.SourceBranch'], 'refs/heads/main'))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

use template instead.

Like:

      ${{ if eq(parameters.BuildXnnpack, 'true') }}:

Such statements are evaluated earlier than what you have. "condition" is evaluated at runtime.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see, thanks

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I probably gave you a wrong suggestion. How about this: you move this job to a template file, then include that template file from here. Like

  - ${{ if eq(parameters.enable_ubuntu_cpu, true) }}:
      - template: py-linux-ubuntu.yml
        parameters:
          arch: 'x86_64'

Then you create another pipeline that will be auto-triggered by every commit in the main branch, but not PRs. Then that pipeline's yaml file include this template too. In this way, your mac-iso-ci-pipeline could still choose to run both jobs or just one of them.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you don't want to do that, your previous commit is fine too.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I want to control it with both triggerd by mannuly and merged into main, I have to evaluated in the runtime. Because I can only get the parameters.BuildXnnpack when I set it as true, Is that right?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, it is not right. parameters are known when you submitted the build run. But at that time, most variables are still unknown. "runtime" means something is only known when the build step starts to run.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got it.

--path_to_protoc_exe $(Build.BinariesDirectory)/protobuf_install/bin/protoc \
--parallel
displayName: (CoreML EP) Build onnxruntime for iOS x86_64 and run tests using simulator
- ${{ or(if eq(parameters.BuildXnnpack, 'true'), if eq(variables['Build.SourceBranch'], 'refs/heads/main')) }}:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We won't know if it works until you merge this PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now, we know,

    1. parameters.BuildXnnpack it works, I have tested it.
    1. when variables['Build.SourceBranch'] is not equal to 'refs/heads/main', it doesn't build

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can test it by merging it into another branch, and have the condition of comparing it to the target branch.

@wejoncy wejoncy merged commit 20c3c35 into main Oct 28, 2022
@wejoncy wejoncy deleted the jicwen/xnnpack_in_ios_build branch October 28, 2022 07:03
linnealovespie pushed a commit that referenced this pull request Oct 28, 2022
### Description
support building xnnpack for IOS


### Motivation and Context
<!-- - Why is this change required? What problem does it solve?
- If it fixes an open issue, please link to the issue here. -->
nums11 pushed a commit that referenced this pull request May 23, 2023
### Description
support building xnnpack for IOS


### Motivation and Context
<!-- - Why is this change required? What problem does it solve?
- If it fixes an open issue, please link to the issue here. -->
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.

2 participants