-
Notifications
You must be signed in to change notification settings - Fork 237
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
[Fix issue #1956] use 64bit index in im2col3d.cl #1966
Conversation
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.
@zjing14 I suspect this affects performance. Can we introduce a macro, like MIOPEN_USE_64BIT_INDEX
, define it as 1 when workspace size > 4 GiB or as 0 otherwise, and use it in the kernel? If you agree but do not have time, then I can do it for you.
Perhaps we shall use 2 GiB threshold because im_offset and ch_offset in the original code are of type int
?
@atamazov Yes, it may impact performance for small problem size. Let me fix it. |
[Recommendation] Use the following code in GemmBwdRest::GetSolution: const bool use_64_bit_index =
problem.GetConv().GetSpatialDimension() == 3
&& GetWorkspaceSize(context, problem) > 0xffffffffULL); Then pass AFAICS the current implementation of 2D Col2Im does not use it, but that's not a problem; we can engage it in the future if need arise. Hope this helps. |
@zjing14 Can you please update the PR description with:
Please also set the following labels on this PR: https://github.com/ROCmSoftwarePlatform/MIOpen/labels/bug https://github.com/ROCmSoftwarePlatform/MIOpen/labels/urgency_high |
@atamazov Thanks very much for your suggestions. I will fix it ASAP. |
@atamazov Added a switch that only enables 64bit for tensor larger than 4GB. Please review it. |
Will review/test tomorrow |
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.
Confirmed that this PR resolves issue #1956. |
@junliume Unfortunately I am unable to edit this branch directly. But I can copy it into my fork, update there, and open a new PR, if necessary due to urgency reasons. |
If the suggested change above is the only place, I can commit it directly :) |
Co-authored-by: Artem Tamazov <[email protected]>
std::size_t index_size = static_cast<size_t>(in_c) * out_d * out_h * out_w * wei_d * wei_w * | ||
wei_h * sizeof(ConstData_t); | ||
|
||
const bool use_64_bit_index = index_size > 0xffffffffULL; |
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.
[Performance]
- Hmm, why
* sizeof(ConstData_t)
, which issizeof(void*) == 8
for HIP backend? In the shader,
ch_offset = im_ch * col_d * col_w * col_h * wei_d * wei_w * wei_h
where max value of im_ch is in_c, right?
Multiplying this to 8 looks like an overkill.
- Another question is about
0xffffffffULL
(4 GiB - 1). In the kernel, computations are performed asint
, which has max value of0x7fffffffULL
(2 GiB - 1).
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.
@zjing14 please comment. 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.
@zjing14 WRT question 1. AFAICS sizeof(ConstData_t)
it should be GetTypeSize(type)
, which matches sizeof(_FLOAT)
in the kernel, right? It should be either 4 (fp32) or 2 (fp16), I think.
UPDATE: Please ignore point 1. We do not need to take the size of element into account because col_off
is actually not an offset but an index in the array col
. Index is multiplied by the sizeof(col[0])
automatically.
Question 2 remains the same.
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.
[Performance]
- Hmm, why
* sizeof(ConstData_t)
, which issizeof(void*) == 8
for HIP backend? In the shader,ch_offset = im_ch * col_d * col_w * col_h * wei_d * wei_w * wei_h
where max value of im_ch is in_c, right?
Multiplying this to 8 looks like an overkill.
Yes, it should be sizeof(ConstData_t)
.
- Another question is about
0xffffffffULL
(4 GiB - 1). In the kernel, computations are performed asint
, which has max value of0x7fffffffULL
(2 GiB - 1).
Yes, 0x7fffffffULL
(2 GiB - 1) makes sense or we change it to unsigned int
.
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.
@zjing14 Thanks for answering!
Yes, it should be sizeof(ConstData_t).
Excuse me, but I do not understand why. AFAIU the goal is to prevent overflows in the following computations in the shader:
https://github.com/ROCmSoftwarePlatform/MIOpen/blob/7ad167d2ecdc29ccebdf965055e1b1a8b9a835a8/src/kernels/MIOpenCol2Im3d.cl#L87-L91
and
https://github.com/ROCmSoftwarePlatform/MIOpen/blob/7ad167d2ecdc29ccebdf965055e1b1a8b9a835a8/src/kernels/MIOpenCol2Im3d.cl#L111-L119
For computation of ch_offset
we do not need the * sizeof(ConstData_t)
multiplier at all.
Is this multiplier necessary to prevent overflow during computation of col_off
?
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.
Yes. You are right, the goal of int64_t
is to prevent index overflow. We need to make sure all indices ch_offset
and col_off
do not overflow.
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.
We may change indices in the kernel to unsigned int
for 32bit. It may improve performance for some cases where indices > 16bit but < 32bit.
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.
@zjing14 Thanks for feedback. And yes, I'll change to unsigned. But what about removal of * sizeof(ConstData_t)
from the computation of index_size? Is it Ok to do that or I am missing something?
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.
🟢 This can be merged as is, provided that #1966 (comment) will be fixed later. The impact of unresolved comment is small: it affects performance for the GemmBwdRest in some relatively narrow range or FP16 problem configs (and also affects clarity/quality of the code).
* use 64bit index * add a switch that only enables 64bit index for large than 4GB * Update src/kernels/MIOpenCol2Im3d.cl Co-authored-by: Artem Tamazov <[email protected]> --------- Co-authored-by: Jun Liu <[email protected]> Co-authored-by: Artem Tamazov <[email protected]>
@zjing14 What do you think about #1966 (review)? You can delegate the actual work to somebody else (even to me), if you do not have time, but we need your opinion prior starting the actual work. |
Ping @zjing14 ... @atamazov I briefly discussed with Jing on this issue and the main concern is about performance impacts. |
@atamazov Sorry for the late reply. Yes, that will be great if someone else can take care of it. If any help is needed, just ping me. |
Okay, let's track this in #1985 |
@zjing14 There is something that is not clear to me, pls look at #1966 (comment). Thanks! |
Full-blown fix for issue #1956.