Skip to content

Conversation

@bartekxk
Copy link
Contributor

@bartekxk bartekxk commented Jun 8, 2025

Proposed changes

Change multi kernel launch to grouped gemm to avoid launching a lot of kernels with one stream. It could cause the situation that a lot of workgroups are idle.

Checklist

Please put an x into the boxes that apply. You can also fill these out after creating the PR. If you're not sure, please don't hesitate to ask.

  • I have added tests relevant to the introduced functionality, and the unit tests are passing locally
  • I have added the test to REGRESSION_TESTS list defined at the top of CMakeLists.txt in tests/CMakeLists.txt, IF the test takes more than 30 seconds to run.
  • I have added inline documentation which enables the maintainers with understanding the motivation
  • I have removed the stale documentation which is no longer relevant after this pull request
  • (If this change is user-facing) I have added release notes which provide the end users with a brief summary of the improvement from this pull request
  • I have run clang-format on all changed files
  • Any dependent changes have been merged

Discussion

If this is a relatively large or complex change, feel free to start a discussion by explaining why you chose the solution you did and what alternatives you considered

group_id = index_t((left + right) / 2);
}

if(gemm_kernel_args[group_id].HasMainKBlockLoop_)
Copy link
Collaborator

Choose a reason for hiding this comment

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

This will likely result in scratch... It would be better to keep HasMainKBlockLoop tparam. Can we make such assumption that all groups have the same HasMainKBlockLoop value?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

HasMainKBlockLoop can be different for each gemm so we cant assume that. I dont see any scratch with such implementation

Comment on lines 99 to 106
this->conv_params.push_back(
{2, 2, 2, 16, 16, {3, 3}, {28, 28}, {2, 2}, {1, 1}, {1, 1}, {1, 1}});
this->conv_params.push_back(
{2, 2, 2, 16, 16, {3, 3}, {28, 28}, {6, 6}, {1, 1}, {1, 1}, {1, 1}});
this->conv_params.push_back(
{2, 2, 2, 16, 16, {6, 6}, {28, 28}, {6, 6}, {1, 1}, {1, 1}, {1, 1}});
this->conv_params.push_back(
{2, 2, 2, 16, 16, {4, 8}, {28, 28}, {4, 8}, {1, 1}, {1, 1}, {1, 1}});
Copy link
Collaborator

Choose a reason for hiding this comment

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

How many groups per each case would you test here? Do you cover as well case with just one group? And a case where you exceed the MaxKernelArgsNum ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It covers 4, 9 (but with ZTilde *YTilde * XTilde = 36), 36, 32. So each case. I will add a description

aosewski
aosewski previously approved these changes Jun 11, 2025
Copy link
Collaborator

@aosewski aosewski left a comment

Choose a reason for hiding this comment

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

Lovely :D

@bartekxk bartekxk merged commit bb4f471 into develop Jun 12, 2025
39 of 46 checks passed
@bartekxk bartekxk deleted the barkocot/lwpck-3165 branch June 12, 2025 08:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants