Skip to content

[SYCL][libdevice] Add IMF support in devicelib #5999

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

Merged
merged 32 commits into from
Jun 13, 2022

Conversation

jinge90
Copy link
Contributor

@jinge90 jinge90 commented Apr 11, 2022

Signed-off-by: jinge90 [email protected]

To provide support for math APIs and functions, not included in standard or <CL/sycl.hpp>.
These math APIs are implemented in "imf" (Intel math functions) SYCL device library. All function names are decorated with __imf_ prefix. These functions may be further categorized into:

  1. Different accuracy implementation for some math functions such as log, exp, cos, sin…
  2. Type cast util functions for float, double, half, bfloat16
  3. Integer type util functions
  4. SIMD util functions
  5. Half type util functions
  6. Bfloat16 type util functions

This PR is 1st of a series of patches to add “imf” SYCL device library, it includes type cast util functions for float, double and integer type util functions.

@jinge90 jinge90 requested review from a team as code owners April 11, 2022 11:50
@jinge90 jinge90 requested a review from v-klochkov April 11, 2022 11:50
@jinge90 jinge90 marked this pull request as draft April 11, 2022 11:50
@v-klochkov v-klochkov removed their request for review April 19, 2022 18:28
Copy link

@akolesov-nv akolesov-nv left a comment

Choose a reason for hiding this comment

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

Thank you, JIn Ge, I will look at the IMF part. Try to add me to reviewer using this username.

#endif
}

class _iml_half {

Choose a reason for hiding this comment

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

Consider to split this source by several ones because

  1. There are logically different parts: one for half emulation class and routines, another ones for device independent basic plugins (__fma, ...)
  2. Basic plugins list are going to be expanded in future (__fma, __floor, ....)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hi, @akolesov-intel
I split the original device_imf.hpp into 2 separate files. All _iml_half related parts are in imf_half.hpp, everything else is still in device_imf.hpp. And device_imf.hpp will include imf_half.hpp, so we only need to include device_imf.hpp in source code.

Choose a reason for hiding this comment

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

Thank you, @jinge90 . Now it is more clear and easy to find - having all fp16 emulation stuff in the separate file.

#ifdef __LIBDEVICE_IMF_ENABLED__

DEVICE_EXTERN_C_INLINE
float __devicelib_imf_saturatef(float x) { return __fclamp(x, .0f, 1.f); }

Choose a reason for hiding this comment

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

Numerics team owns a number of trivial math functions like __devicelib_imf_copysign, __devicelib_imf_fabs, __devicelib_imf_rsqrt which can be either mapped to just one device independent builtin or implemented by a couple of simple operations - these functions are better to be inlined from header file than called from binary. We would like to gather them all under the ./imf folder which our team owns, promotes and supports. All trivial functions may combined within just one file. Could you please add such header inside ./imf, say, ./imf/imf_inline.hpp, with one function example (floor?)? Thanks!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hi, @akolesov-intel
If we want to inline those trivial functions in header, then the header should be exposed to users, users will include it in their source code. And in the header file, we need to include:

  1. declarations for all imf functions provided by us.
  2. Some trivial functions inline definition.

Choose a reason for hiding this comment

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

I am fine if these functions are going to be inlined as IR, not as sources in header. I am just suggesting to gather them all into one file, not to spread by many separate tiny sources. I did that in my package through imf_inline.cpp source (can be named differently).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hi, @akolesov-intel
I updated the patch to integrate all "trivial inline" functions, those functions are inlined as IR.
If we inline in LLVM IR level, we need also split imf_inline.cpp into imf_inline_fp32.cpp and imf_inline_fp64.cpp, I did this in the latest patch and basic tests for fp32, fp64, fp16 passed. Could you help review?
Thanks very much.

Choose a reason for hiding this comment

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

Thank you, @jinge90 , the split looks good to me.

Choose a reason for hiding this comment

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

Would be better to move saturatef implementation to imf_inline_fp32.cpp to gather all trivial functions mapped to math builtins in one place. And this file may be deleted.

set(fallback-imf-src imf_utils/saturatef.cpp
imf_utils/float_convert.cpp
imf_utils/half_convert.cpp
imf/exp_s_la.cpp

Choose a reason for hiding this comment

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

Just curious is it possible to take the section with all Numerics function out of this file in a separate small cname include file and move it under the ../imf folder? This case Numerics team is going to be responsible to expand this list after all new function additions and no needs for Compiler team assistance required this case.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hi, @akolesov-intel
Moving the section with all Numerics function out of this file in a separate small cmake is OK. However, moving it to ../imf folder doesn't align with libdevice's building system.

Choose a reason for hiding this comment

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

I am Ok not to move the section under ./imf, but we would need to agree on promotion process in details and document it somewhere.

xtian-github
xtian-github previously approved these changes May 6, 2022
Copy link

@xtian-github xtian-github left a comment

Choose a reason for hiding this comment

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

LGTM

@jinge90
Copy link
Contributor Author

jinge90 commented May 10, 2022

Hi, all.
I am focusing on implement type cast functions for float, double in this PR. When those functions are done, I will focus on addressing your comments. Type cast for fp16 and bfloat16 will be in future PR.
Thanks very much for the review.

@jinge90 jinge90 marked this pull request as ready for review May 12, 2022 10:39
@xtian-github
Copy link

With all the latest changes, the patch LGTM. But, we need to define the promotion/merge process between CE and MKL teams. Thanks.

@xtian-github
Copy link

@jinge90 *fp32.hpp and *fp64.hpp splitting is good. as fp64 does not work for ATS-M.

zettai-reido
zettai-reido previously approved these changes May 13, 2022
Copy link

@zettai-reido zettai-reido 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 addressing the comments.
LGTM as it of now.

@jinge90 jinge90 closed this May 17, 2022
@jinge90 jinge90 reopened this May 17, 2022
Signed-off-by: jinge90 <[email protected]>
akolesov-nv
akolesov-nv previously approved these changes Jun 8, 2022
@jinge90 jinge90 dismissed stale reviews from akolesov-nv and asudarsa via 61b50ed June 9, 2022 04:03
Signed-off-by: jinge90 <[email protected]>
steffenlarsen
steffenlarsen previously approved these changes Jun 9, 2022
Copy link
Contributor

@steffenlarsen steffenlarsen left a comment

Choose a reason for hiding this comment

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

LGTM!

@jinge90
Copy link
Contributor Author

jinge90 commented Jun 9, 2022

Hi, all.
We made a little change in comments and added one compile-time macro check, could you help review again? The patch is ready to merge now.

Thanks very much.

mdtoguchi
mdtoguchi previously approved these changes Jun 9, 2022
akolesov-nv
akolesov-nv previously approved these changes Jun 9, 2022
@jinge90
Copy link
Contributor Author

jinge90 commented Jun 10, 2022

Hi, @pvchupin
We have finished review for this patch, could you help merge it?
Thanks very much.

@pvchupin
Copy link
Contributor

@jinge90, can you please add PR description
@asudarsa, feel free to reapprove.

asudarsa
asudarsa previously approved these changes Jun 10, 2022
Copy link
Contributor

@asudarsa asudarsa left a comment

Choose a reason for hiding this comment

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

LGTM. Thanks

@xtian-github
Copy link

@jinge90 is @zettai-reido going to do merge? or you?

@pvchupin
Copy link
Contributor

@xtian-github, I'm going to merge as soon as somebody update PR description above (to be used as commit message).

@xtian-github
Copy link

@pvchupin Thanks Pavel!

@jinge90
Copy link
Contributor Author

jinge90 commented Jun 12, 2022

Hi, @pvchupin
I just updated the PR description and also made a little change to the patch, since the latest change only includes some little bugfix, it is OK to merge.

Thanks very much.

Copy link

@zettai-reido zettai-reido left a comment

Choose a reason for hiding this comment

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

LGTM

@pvchupin pvchupin merged commit a310952 into intel:sycl Jun 13, 2022
againull pushed a commit that referenced this pull request Aug 25, 2022
We added some imf(intel math) APIs in libdevice: #5999, #6327, those APIs are C interface which means we don't expect users to call them directly in SYCL kernel since SYCL programming uses cpp. This PR will provide cpp wrapper for those imf APIs which users can call directly in source, the approach is similar to STL , std math functions will call corresponding C math functions or compiler math builtins. The user scenario should be following:
cpp
#include <sycl/ext/intel/math.hpp>
...
float x, y, z;
z = sycl::ext::intel::math::copysign(x, y);
...
``
@jinge90 jinge90 deleted the libdevice_imf branch August 26, 2022 03:09
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.

8 participants