-
Notifications
You must be signed in to change notification settings - Fork 218
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
[HIP] We should not be including cmath in our kernels... #1926
Comments
[Attribution] @junliume https://github.com/ROCmSoftwarePlatform/MIOpen/labels/request_for_comments https://github.com/ROCmSoftwarePlatform/MIOpen/labels/urgency_normal I recommend assigning @asroy @zjing14 @aska-0096 @ltqin @qianfengz @JehandadKhan @shurale-nkn @carlushuang @pfultz2 for awareness at least. |
@pfultz2 Let me describe the status of cmath usage in our kernels and in CK:
|
Another topic. We need to clearly understand what is legal and what is not in HIP language. So far I see the following: In HIP Kernel Language/C++ Support:
In HIP Kernel Language/Math Functions:
CUDA informs about the restriction that standard libs are not supported unless specified otherwise. And there is comprehensive reference on device specific math, which, among other things tells that these functions are always available in device code. Idealized policy for HIP programs:
Let's consider a use case is when both host and device code want to use Ditto all other cases when device code wants to use entities that match the standard ones. Of course I understand that the above policy is an extreme solution (maybe too extreme) and requires a lot of work. Guys, what do you think? |
For the CK backend, Found 7 files including the cmath header, while 5 of them in host code. |
I will fix the CK including of |
Yes. Including of |
PR 551 submitted |
Yes, this mainly applies to runtime compilation(ie using hipRTC). Although, CK will be used in MIGraphX as device code, so those changes will eventually need to be made(or at least ifdef the host code).
We have other constraints when we are doing runtime compilation(ie hipRTC). We cannot rely on header files being installed, such as from the c++ standard library as those headers are for building packages and not for runtimes.
hipRTC provides
Yes and thats what we are doing in MIGraphX. You can then ifdef the definitions to use |
@pfultz2 May I ask for advice? Currently:
Do you recommend moving from from "workaround" to "standard practice"? The necessary code changes are cosmetic; most likely, it is adequate to simply replace |
@atamazov May I close this issue? As CK backend has accepted "remove cmath" PR. |
@zjing14 this is the issue I was referring to earlier. Thanks @aska-0096 |
Basically I do not want this ticket to be ever closed. It is intended to hold the description of the problem, analysis, discussions, and hopefully an agreed decision. That is why it is marked with "RFC" label. Maybe it is worth converting this to recently introduced "discussion" (if we do not want to use "issues" for sustained topics), but I am still conservative. |
@pfultz2 Can you please let me know your opinion about #1926 (comment)? |
We should not be including cmath in our kernels if we are using hiprtc as all the math function should already be provided by HIP.
If we are doing
#include <cmath>
in our kernels then this needs to be fixed in either MIOpen or CK.Originally posted by @pfultz2 in #1921 (comment)
The text was updated successfully, but these errors were encountered: