Skip to content
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

[NFC] Replace miopen::ProblemDescription with conv::ProblemDescription, part 3 #2303

Conversation

averinevg
Copy link
Collaborator

  • Make miopen::ProblemDescription derived from conv::ProblemDescription
  • miopen::ProblemDescription: remove getters that exist in the parent class
  • conv::ProblemDescription: use proper data type of return value for getters that use data from TensorDescriptor
  • conv::ProblemDescription: add trailing underscores to getters with changed data type in order to get the attention of developers who are not familiar with these changes (will be removed after ROCm 6.0)
  • Remove unused code

Copy link
Contributor

@atamazov atamazov left a comment

Choose a reason for hiding this comment

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

Something to discuss.

@@ -285,7 +285,7 @@ struct TensorDescriptor : miopenTensorDescriptor
};

template <class TElement>
constexpr auto GetNCDHW(int spatial_dims, const std::vector<TElement>& data)
constexpr auto GetNCDHW(unsigned spatial_dims, const std::vector<TElement>& data)
Copy link
Contributor

Choose a reason for hiding this comment

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

[Q] why this is necessary?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This variable is always positive and using a signed data type can be misleading

Copy link
Contributor

Choose a reason for hiding this comment

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

That is, you just caught a not quite high-quality code and decided to fix it, right? 😄

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yes, you are right 😄. I decided to change this too, because it is related to my changes

Comment on lines +193 to +203
unsigned GetInBatchSize_() const { return GetN5(GetSpatialDims(), in.GetLengths()); }
unsigned GetBatchSize_() const { return GetInBatchSize_(); } // alias of GetInBatchSize_()
unsigned GetInChannels_() const { return GetC5(GetSpatialDims(), in.GetLengths()); }
unsigned GetInDepth_() const { return GetD5(GetSpatialDims(), in.GetLengths()); }
unsigned GetInHeight_() const { return GetH5(GetSpatialDims(), in.GetLengths()); }
unsigned GetInWidth_() const { return GetW5(GetSpatialDims(), in.GetLengths()); }
unsigned GetInBatchStride_() const { return GetN5(GetSpatialDims(), in.GetStrides()); }
unsigned GetInChannelStride_() const { return GetC5(GetSpatialDims(), in.GetStrides()); }
unsigned GetInStrideD_() const { return GetD5(GetSpatialDims(), in.GetStrides()); }
unsigned GetInStrideH_() const { return GetH5(GetSpatialDims(), in.GetStrides()); }
unsigned GetInStrideW_() const { return GetW5(GetSpatialDims(), in.GetStrides()); }
Copy link
Contributor

Choose a reason for hiding this comment

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

[Q] I am not sure this is a good change. Let's discuss.

Copy link
Contributor

Choose a reason for hiding this comment

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

I would also like to know why we went to unsigned from size_t and why the names have an _ at the end of getters.

Copy link
Collaborator Author

@averinevg averinevg Aug 29, 2023

Choose a reason for hiding this comment

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

@amberhassaan You can find details here #2303 (comment) and here #2303 (comment)

In most places in the library miopen::ProblemDescription is used, its getters returned the int type, the getters of conv::ProblemDescription returned the size_t type. For now, it is enough for us to have int. unsigned is used because we don't need a sign.

@averinevg
Copy link
Collaborator Author

@averinevg

conv::ProblemDescription: add trailing underscores to getters with changed data type in order to get the attention of developers who are not familiar with these changes (will be removed after ROCm 6.0)

Are you going to remove those underscores after MIOpen 6.0 RC is cut off?

Yes, this is a temporary change

@atamazov
Copy link
Contributor

atamazov commented Aug 9, 2023

WRT #2303 (comment). After ~2 hours discussion we decided to continue as is and then switch to size_t in a dedicated PR.

DrizztDoUrden
DrizztDoUrden previously approved these changes Aug 10, 2023
Copy link
Contributor

@DrizztDoUrden DrizztDoUrden left a comment

Choose a reason for hiding this comment

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

LGTM

const auto W = (problem).GetInWidth(); \
const auto out_H = (problem).GetOutHeight(); \
const auto out_W = (problem).GetOutWidth();
#define DEFINE_SHADER_ALIASES(problem) \
Copy link
Contributor

Choose a reason for hiding this comment

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

An idea for future work to ease solver developers life:
Similar code is verbose and present in most of our solvers. We should add some method like CommonlyUsedConvParameters GetCommonlyUsedConvParameters with CommonlyUsedConvParameters being some type which is compatible to structured bindings so it would be possible to either extract them as const auto [grop_cnt, N, K, ...] = problem.GetCommonlyUsedConvParameters() or just as const auto params = GetCommonlyUsedConvParameters() to use as params.group_cnt and such.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Perhaps we should also refactor other "helpers" that get data from ProblemDescription. I assume that they partially overlap and can be generalized.

junliume
junliume previously approved these changes Aug 15, 2023
Copy link
Collaborator

@junliume junliume left a comment

Choose a reason for hiding this comment

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

LGTM but I am waiting for the good opportunity to merge. Too many files changed means higher chances for other PRs to have conflicts.

DrizztDoUrden
DrizztDoUrden previously approved these changes Aug 15, 2023
@JehandadKhan
Copy link
Collaborator

@junliume We can merge this when you get a chance

@junliume junliume merged commit 21df5bf into develop Aug 28, 2023
@@ -38,6 +38,8 @@
#include <cstdint>
#include <string>

#define FIN_OLD_PROBLEM_DESCRIPTION_COMPAT 1
Copy link
Contributor

Choose a reason for hiding this comment

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

Is this flag documented somewhere?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

No, it is supposed to be used with MIFin for backward compatibility and will be removed soon.

@averinevg averinevg deleted the ea_replace_problem_description_with_conv_problem_description_part_3_2 branch September 28, 2023 13:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants