-
Notifications
You must be signed in to change notification settings - Fork 577
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
Trilinos SYCL build failing: llvm-foreach: Error: Device name missing. #12420
Comments
@eugeneswalker AFAIK, that is a "compiler is not installed correctly on the system" error. Progress on #12295 is blocked on the same problem. |
Not all of Trilinos has been ported to SYCL. Only packages that were ECP funded could work on sycl port. I know that sacado, phalanx and panzer will not work on that hardware. There are probably other packages as well. |
Do you know how to make this print the exact
|
make VERBOSE=1 |
@bartlettroscoe Comments on the above? |
@eugeneswalker, CMake variables are case sensitive, so if you want to build Trilinos against a pre-installed Kokkos, you should have to configure with:
If you try setting:
you should get a warning at the end of the CMake STDOUT that the variable |
@jwillenbring and @rppawlo, do you know what internal SNL program is funding Trilinos support of SYCL? You can contact me offline to respond. |
@eugeneswalker, as far as I know, there should be no difference in behavior for downstream Trilinos packages depending on if Kokkos is built as part of Trilinos or pulled in from a prebuilt Kokkos. But it is possible given that Kokkos does not export every variable from its installed For starters, we would need to be able to inspect the produced cmake STDOUT and CMakeCache.txt files produced by both methods. Can we get those? That may provide a clue to what is happening without having to debug these locally. But otherwise, we would need to be able to reproduce both cases locally to debug something like this. (Then the debugging process should be pretty straightforward, if not tedious.) But then there is the official Trilinos policy: so I am not sure that we are authorized to support this build configuration yet since there is no official Trilinos SYCL build configuration that posts to the Trilinos CDash site that duplicates this configuration.
@jwillenbring and @rppawlo, how would Trilinos developers be expected to reproduce these builds on UO Frank using these Spack containers? Given the info above, I am not sure I know how to do that. I think I would need the exact set of commands to run. |
I used the correct case when doing the build, just did not notice that when I wrote the post here. The build with external kokkos worked. |
@eugeneswalker Can you describe what your end goal is? It is better not to enable all of trilinos for SYCL. Please reach out to @iyamazaki @lucbv to get the subset we have ported to this backend to support ECP. Testing those would be nice. |
We have only worked on the new solvers stack that would be: Tpetra, Ifpack2, Belos, Amesos2, Xpetra, Zoltan2 and MueLu. |
We could make it so that Trilinos disables, by default, any packages that don't support SYCL when Then, we can deal with the packages that should support SYCL. Update: See the new issue: |
That said, it looks like it does work with external Kokkos, so it seems it might be an internal cmake issue in Trilinos and or Kokkos? |
@crtrott That comment on external Kokkos is confusing to me. The original build had so many packages enabled most of which do not support SYCL. With external Kokkos, Tpetra tests passed. This is what we would expect. I would also expect that Tpetra tests pass with the Kokkos in Trilinos. I don't know if that comment means rest of packages built fine or just Tpetra built fine. Let us wait for @eugeneswalker to respond. Even if the packages built fine, I would not trust anything there as we do not support/test SYCL with most of the packages except the packages listed by @lucbv above + Kokkos Core + Kokkos Kernels. |
Hm yeah if it was only Tpetra that might be the difference. I assumed it was the same configure with external Kokkos or internal. |
Everything about the Trilinos configuration was the same except that I had it use external Kokkos. The same set of packages were turned on. I only ran the tpetra ctests.
|
FYI: From looking at the configure output given above, we see the set of enabled and disabled packages:
So it looks like most of Trilinos is being enabled in that configuration. Which of those packages listed under |
I can try the build again, using internal Kokkos, but with everything turned off except the packages identified a few comments above as having support for SYCL. Is that worth trying as part of the process here? |
@eugeneswalker This is strange behavior for sure. In theory, it shouldn't matter which version of Kokkos you use, SYCL support in packages shouldn't be affected by those. From the configure: Final set of enabled packages: Kokkos TeuchosCore TeuchosParser TeuchosParameterList TeuchosComm TeuchosNumerics TeuchosRemainder TeuchosKokkosCompat TeuchosKokkosComm Teuchos KokkosKernels RTOp Sacado MiniTensor Epetra Zoltan Shards Triutils EpetraExt TpetraTSQR TpetraCore Tpetra TrilinosSS ThyraCore ThyraEpetraAdapters ThyraEpetraExtAdapters ThyraTpetraAdapters Thyra Xpetra Isorropia AztecOO Galeri Amesos Zoltan2Core Ifpack ML Belos Amesos2 Anasazi Ifpack2 Stratimikos Teko Intrepid STKUtil STKCoupling STKMath STKSimd STKExprEval STKTopology STKSearch STKTransfer STKMesh STKUnit_tests STKDoc_tests STKEmend STK Phalanx NOX MueLu Zoltan2 ShyLU_DDFROSch ShyLU_DDCore ShyLU_DD ShyLU Tempus Stokhos ROL Piro TrilinosCouplings 69 This is the set of packages that we have tested with SYCL: There are packages like Epetra, Zoltan that it probably doesn't matter whether you use SYCL or not. I do not know how to quickly go from that first list down the dependency tree to say a package requires SYCL testing. Some probably do, say NOX. The same is true for ROL, ShyLU*, STK etc. I believe they have to be tested as they will all rely on Kokkos. Some probably don't. Say TrilinosSS, Triutils. You see my dilemma? |
The failing compile line looks like the following to me:
whereas the linker step should look something like
which means that |
#9514 would probably solve this problem as well. |
Fixed by #12707. |
Bug Report
Unsure who to ping here. @nchaimov @sameershende
Description
Trying to build
trilinos@develop
w/ SYCL using OneAPI Toolkit 2023.2.1 for use with Intel A770.This is failing with the error shown below:
Steps to Reproduce
Reproduced here on the Mothra system on UO Frank, which has an Intel A770.
Using Docker image
esw123/trilinos-intel:2023.10.18
where all dependencies and artifacts needed for reproduction are already present.CMake output here: trilinos-sycl-cmake.txt
Concretization / Dependency Information
The text was updated successfully, but these errors were encountered: