Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

WanliZhong
Copy link
Member

@WanliZhong WanliZhong commented Dec 29, 2022

Merge with: opencv/opencv_extra#1033

This PR tries to make GEMM can be supported with transA and transB in CUDA. It's a follow-up to #22882
GEMM onnx documentation: https://github.com/onnx/onnx/blob/main/docs/Operators.md#Gemm

Because MatMul can be seen as a specific case of GEMM, I put the GEMM into MatMulOp. This may make it possible to implement the whole GEMM operation: αAB+βC in the future.

Pull Request Readiness Checklist

See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request

  • I agree to contribute to the project under Apache 2 License.
  • To the best of my knowledge, the proposed patch is not based on a code under GPL or another license that is incompatible with OpenCV
  • The PR is proposed to the proper branch
  • There is a reference to the original bug report and related work
  • There is accuracy test, performance test and test data in opencv_extra repository, if applicable
    Patch to opencv_extra has the same branch name.
  • The feature is well documented and sample code can be built with the project CMake
force_builders=Custom
buildworker:Custom=linux-1
docker_image:Custom=ubuntu-cuda:16.04

@WanliZhong WanliZhong added category: dnn category: dnn (onnx) ONNX suport issues in DNN module labels Dec 29, 2022
@WanliZhong WanliZhong requested review from rogday and zihaomu December 29, 2022 12:53
@WanliZhong WanliZhong marked this pull request as ready for review December 29, 2022 12:53
Copy link
Member

@zihaomu zihaomu left a comment

Choose a reason for hiding this comment

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

LGTM! 👍

}

layerParams.set("bias_term", node_proto.input_size() == 3);
layerParams.set("is_matmul", true);
Copy link
Member

Choose a reason for hiding this comment

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

is_matmul

Do we really need this?
Where is it used?

Does InnerProduct without is_matmul make sense (used somewhere)?

Such layer parameters should be described in headers' documentation, because this behavior is not obvious.

Copy link
Member Author

@WanliZhong WanliZhong Jan 19, 2023

Choose a reason for hiding this comment

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

In the current implementation, InnerProduct and MatMul are implemented using the same code. Previously, it used to distinguish the two by judging whether InputB is const or not, which could not distinguish the two in some cases, so the is_matmul parameter was introduced.

I add this parameter in #22828. If it is acceptable, I will add some description in header's documentation.

Copy link
Member

Choose a reason for hiding this comment

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

Why importer should know about that implementation details?

Interfaces should be kept clear and stay implementation agnostic.
Implementation should use inheritance instead of adding of new strange external parameters.

Copy link
Member Author

@WanliZhong WanliZhong Feb 1, 2023

Choose a reason for hiding this comment

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

Because the implementation cannot tell whether the operator is matrix multiplication or inner product, it needs to be informed by the importer.

If it is just 2D matrix multiplication, it can share the same code with inner product, but high-dimensional matrix multiplication cannot be implemented with inner product code. I haven't thought a better way to distinguish them than separating the implementation part of the matrix multiplication from the inner product.

Copy link
Member

@alalek alalek Feb 1, 2023

Choose a reason for hiding this comment

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

cannot tell whether the operator is matrix multiplication or inner product, it needs to be informed by the importer

It is done by name/type of the layer: layerParams.type = "InnerProduct";

Copy link
Member Author

Choose a reason for hiding this comment

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

Thanks! This is really useful! I will remove this parameter later.

Copy link
Member Author

Choose a reason for hiding this comment

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

It is done by name/type of the layer: layerParams.type = "InnerProduct";

This solution can‘t be implemented to distinguish MatMul, GEMM and InnerProduct, because their layerParams.type are all InnerProduct. They all use the fully_connected_layer to implement. I still have to specific a parameter in importer.

MatMul use layerParams.type = "InnerProduct":

void ONNXImporter::parseMatMul(LayerParams& layerParams, const opencv_onnx::NodeProto& node_proto_)
{
opencv_onnx::NodeProto node_proto = node_proto_;
CV_Assert(node_proto.input_size() == 2);
layerParams.type = "InnerProduct";

GEMM use layerParams.type = "InnerProduct":

void ONNXImporter::parseGemm(LayerParams& layerParams, const opencv_onnx::NodeProto& node_proto)
{
CV_Assert(node_proto.input_size() >= 2);
layerParams.type = "InnerProduct";

Other operators:

case V1LayerParameter_LayerType_INNER_PRODUCT:
return "InnerProduct";

cv::dnn::LayerParams getParamFullyConnected(int output)
{
cv::dnn::LayerParams params;
params.name = "FullyConnected-name";
params.type = "InnerProduct";

int id = dstNet.addLayer(name, "InnerProduct", layerParams);

newModule->apiType = "InnerProduct";

@WanliZhong
Copy link
Member Author

@alalek Why there are some warnings about gtest? What should I do to solve them?

@alalek
Copy link
Member

alalek commented Jan 31, 2023

Ignore. Warnings are not related to this PR - they are everywhere on "macOS - ARM64".

/cc @asmorkalov

@alalek
Copy link
Member

alalek commented Jan 31, 2023

Looks like macOS runner has been upgraded and enabled back(!) without any checks or necessary fixes.

@asmorkalov
Copy link
Contributor

@alalek My fault. Will take a look ASAP.

@alalek alalek merged commit 96a45e8 into opencv:4.x Feb 8, 2023
@WanliZhong WanliZhong deleted the gemm_cuda branch May 16, 2023 12:33
@asmorkalov asmorkalov mentioned this pull request May 31, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

category: dnn (onnx) ONNX suport issues in DNN module category: dnn category: gpu/cuda (contrib) OpenCV 4.0+: moved to opencv_contrib optimization

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants