Skip to content

Workaround nearbyint() for Kokkos SYCL backend#74

Draft
NamjaeChoi wants to merge 1 commit into
libMesh:masterfrom
NamjaeChoi:nearbyint
Draft

Workaround nearbyint() for Kokkos SYCL backend#74
NamjaeChoi wants to merge 1 commit into
libMesh:masterfrom
NamjaeChoi:nearbyint

Conversation

@NamjaeChoi

@NamjaeChoi NamjaeChoi commented Jul 16, 2026

Copy link
Copy Markdown

Kokkos does not provide portable nearbyint() implementation for SYCL backend.

@NamjaeChoi
NamjaeChoi force-pushed the nearbyint branch 2 times, most recently from 83d7020 to 2774977 Compare July 16, 2026 23:26
@NamjaeChoi NamjaeChoi changed the title Do not provide nearbyint() overload for Kokkos Manually implement nearbyint() overload for Kokkos SYCL backend Jul 16, 2026
@NamjaeChoi

Copy link
Copy Markdown
Author

@lindsayad @roystgnr Objections?

@roystgnr

Copy link
Copy Markdown
Member

Not a fan of us putting things in namespace Kokkos. No way to make this work via ADL?

@NamjaeChoi

Copy link
Copy Markdown
Author

I don't think so. ADL does not apply to fundamental types

@roystgnr

Copy link
Copy Markdown
Member

I'm not a fan of the MOOSE "you must file an issue before you can put up a PR" policy, but I think this is one case where it would have paid off; I'm instead trying to reverse-engineer what must be wrong here.

I take it Kokkos calls Kokkos::nearbyint() explicitly (so we can't change the call to a wrapper in our own namespace), in some function we can't reimplement to avoid the call, and Kokkos doesn't implement nearbyint() for one backend ... but isn't that missing implementation a bug report we should file or a PR we could submit there? As is, if we merge this PR and they do fix that backend, then won't we no longer be able to compile against the result, because the compiler will see two definitions?

@NamjaeChoi

NamjaeChoi commented Jul 20, 2026

Copy link
Copy Markdown
Author

I'm not a fan of the MOOSE "you must file an issue before you can put up a PR" policy, but I think this is one case where it would have paid off; I'm instead trying to reverse-engineer what must be wrong here.

I take it Kokkos calls Kokkos::nearbyint() explicitly (so we can't change the call to a wrapper in our own namespace), in some function we can't reimplement to avoid the call, and Kokkos doesn't implement nearbyint() for one backend ... but isn't that missing implementation a bug report we should file or a PR we could submit there? As is, if we merge this PR and they do fix that backend, then won't we no longer be able to compile against the result, because the compiler will see two definitions?

They state in the code not available as of current SYCL 2020 specification (revision 11). Also explicitly mentioned in their documentation that it is not available in SYCL

@NamjaeChoi

Copy link
Copy Markdown
Author

Opened roystgnr#90.

@NamjaeChoi

Copy link
Copy Markdown
Author

Also it looks like rint and nearbyint are not distinguishable on GPUs due to the lack of standard floating point exceptions. So I guess nearbyint can simply invoke rint.

@NamjaeChoi

NamjaeChoi commented Jul 22, 2026

Copy link
Copy Markdown
Author

Does the change look reasonable?

@NamjaeChoi NamjaeChoi changed the title Manually implement nearbyint() overload for Kokkos SYCL backend Workaround nearbyint() for Kokkos SYCL backend Jul 22, 2026
@NamjaeChoi
NamjaeChoi marked this pull request as draft July 23, 2026 20:17
@NamjaeChoi

Copy link
Copy Markdown
Author

rint is available from Kokkos 5.1, so we should hold it

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