-
Notifications
You must be signed in to change notification settings - Fork 795
[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
Conversation
Signed-off-by: jinge90 <[email protected]>
Signed-off-by: jinge90 <[email protected]>
Signed-off-by: jinge90 <[email protected]>
There was a problem hiding this 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.
libdevice/device_imf.hpp
Outdated
#endif | ||
} | ||
|
||
class _iml_half { |
There was a problem hiding this comment.
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
- There are logically different parts: one for half emulation class and routines, another ones for device independent basic plugins (__fma, ...)
- Basic plugins list are going to be expanded in future (__fma, __floor, ....)
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
libdevice/imf_utils/saturatef.cpp
Outdated
#ifdef __LIBDEVICE_IMF_ENABLED__ | ||
|
||
DEVICE_EXTERN_C_INLINE | ||
float __devicelib_imf_saturatef(float x) { return __fclamp(x, .0f, 1.f); } |
There was a problem hiding this comment.
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!
There was a problem hiding this comment.
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:
- declarations for all imf functions provided by us.
- Some trivial functions inline definition.
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Hi, all. |
With all the latest changes, the patch LGTM. But, we need to define the promotion/merge process between CE and MKL teams. Thanks. |
@jinge90 *fp32.hpp and *fp64.hpp splitting is good. as fp64 does not work for ATS-M. |
There was a problem hiding this 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.
Signed-off-by: jinge90 <[email protected]>
Signed-off-by: jinge90 <[email protected]>
…ice_imf.hpp Signed-off-by: jinge90 <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
Hi, all. Thanks very much. |
Hi, @pvchupin |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Thanks
@jinge90 is @zettai-reido going to do merge? or you? |
@xtian-github, I'm going to merge as soon as somebody update PR description above (to be used as commit message). |
@pvchupin Thanks Pavel! |
6dfa250
Signed-off-by: jinge90 <[email protected]>
Signed-off-by: jinge90 <[email protected]>
Hi, @pvchupin Thanks very much. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
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); ... ``
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:
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.