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

#13128: Enhance build_metal.sh #13141

Closed
wants to merge 6 commits into from
Closed

Conversation

blozano-tt
Copy link
Contributor

@blozano-tt blozano-tt commented Sep 26, 2024

Ticket

#13128

Problem description

Currently, we build tt-metal, ttnn, and tt-umd unit tests, or we build no tests.
Additionally, our users have no control over where build artifacts are installed when building from source.

What's changed

  • Three new CMake options are defined
    • TT_METAL_BUILD_TESTS -> Do we want to build tt_metal tests?
    • TTNN_BUILD_TESTS -> Do we want to build ttnn tests?
    • TT_UMD_BUILD_TESTS -> Do we want to build umd unit tests?
      • This option needs to be consumed by tt-umd, and would require a push to that repo, and submodule update.
  • CMAKE_INSTALL_PREFIX no longer tied to PROJECT_BINARY_DIR, give people freedom
  • Enhancements to build_metal.sh
    • Allow customer to provide long options; i.e. --help
    • Allow customer to provide installation directory, default to build_dir
    • Allow customer to provide extra cmake options
    • Add --clean option
    • Add --debug, --release, --development as shortcuts to pick build type

Checklist

  • Post commit CI passes
  • Blackhole Post commit (if applicable)
  • Model regression CI testing passes (if applicable)
  • Device performance regression CI testing passes (if applicable)
  • New/Existing tests provide coverage for changes

@ttmchiou ttmchiou self-requested a review September 26, 2024 17:13
@ttmchiou
Copy link
Contributor

"TT_UMD_BUILD_TESTS -> Do we want to build umd unit tests?
This option needs to be consumed by tt-umd, and would require a push to that repo, and submodule update."

Does this option need to be coordinated with UMD? if so, would suggest reaching out to @joelsmithTT @broskoTT @pjanevskiTT.

Is this a necessary change for getting rid of ARCH_NAME for tt-metal codebase?

@blozano-tt
Copy link
Contributor Author

@ttmchiou

Does this option need to be coordinated with UMD? if so, would suggest reaching out to @joelsmithTT @broskoTT @pjanevskiTT.

Yes, I was going to submit a PR to them today. Will keep them in the loop.

Is this a necessary change for getting rid of ARCH_NAME for tt-metal codebase?
Yes, it is a very necessary stop gap, until the umd unit tests don't depend on ARCH_NAME, or until we no longer have ownership of running umd unit tests in our CI.

It is sort of complicated to talk through all the scenarios, but adding this switch is sort of common sense cleanup for both projects.

By default, umd unit tests are not built. If TT_UMD_BUILD_TESTS=ON then only build them, and if it is defined, they can check ARCH_NAME variable.

It won't be a drastic change from what already happens, based on their use of EXCLUDE_FROM_ALL token in their tests.

@ttmchiou ttmchiou force-pushed the blozano/cmake_build_tests branch from b6b1ce8 to 449c93e Compare September 27, 2024 22:40
@TT-billteng
Copy link
Collaborator

you're changing a lot more than just controlling which tests to build in this PR, can you separate it out? We also currently have no way to test build_metal.sh so you need to be careful with the changes.

@blozano-tt
Copy link
Contributor Author

you're changing a lot more than just controlling which tests to build in this PR, can you separate it out? We also currently have no way to test build_metal.sh so you need to be careful with the changes.

Guilty as charged.

Will separate it out.


build_dir="build_$build_type"


# Set the python environment directory if not already set
if [ -z "$PYTHON_ENV_DIR" ]; then
Copy link
Collaborator

Choose a reason for hiding this comment

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

Is this needed in the CMake system? Don't think so right?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Not sure actually.

@@ -273,7 +276,7 @@ install(TARGETS ttnn
)
if(WITH_PYTHON_BINDINGS)
# Install .so into src files for pybinds implementation
install(FILES ${PROJECT_BINARY_DIR}/lib/_ttnn.so
Copy link
Collaborator

Choose a reason for hiding this comment

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

How does the install target know which file to copy over? I don't see this declared anywhere else

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The CMake target "ttnn" is a shared library target. CMake will always know where it is building it, so we don't have to tell CMake where it is. We just need to say "install target", just like we are doing a few lines above (line 272).

@@ -37,7 +37,7 @@ jobs:
echo "TT_METAL_HOME=$(pwd)" >> $GITHUB_ENV
- name: Build UMD device and tests
run: |
cmake -B build -G Ninja
cmake -B build -G Ninja -DTT_UMD_BUILD_TESTS=ON
Copy link
Collaborator

Choose a reason for hiding this comment

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

What the heck - why are we building the tests on the TG machine? We should be downloading build artifacts. Sounds like an issue to write up to do after

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Can you write up said issue? I don't know what a TG machine is yet.
Eventually, we don't want to be building UMD tests at all in tt-metal CI, because UMD Is an external third party library, and they are starting to run their own CI.

: '
TLDR: Follow the steps outlined below to build metal. For more in-depth information, keep reading

Steps:
Copy link
Collaborator

Choose a reason for hiding this comment

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

There was really nothing from here you wanted to keep as comments?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Correct, I want a single source of truth on documentation.
Anything worth documenting should be in README.md.

@@ -1,6 +1,6 @@

add_executable(watcher_dump ${CMAKE_CURRENT_SOURCE_DIR}/watcher_dump.cpp)
target_link_libraries(watcher_dump PRIVATE test_metal_common_libs)
Copy link
Collaborator

Choose a reason for hiding this comment

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

Damn, good catch

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Had to fix a build failure, after separating the libraries and executables from the tests.

@blozano-tt
Copy link
Contributor Author

Splitting this PR into:
#13251 and #13259
As requested by @TT-billteng
Closing #13141

@blozano-tt blozano-tt closed this Sep 30, 2024
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.

4 participants