Skip to content

Conversation

@yingluAMD
Copy link
Contributor

@yingluAMD yingluAMD commented Nov 27, 2025

Proposed changes

CKProfiler files are actually CPU code. __gfx macros doesn't work. Remove them and use CK_ENABLE_TF32 control whether enroll this datatypes compilation.

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

bartekxk
bartekxk previously approved these changes Nov 28, 2025
aosewski
aosewski previously approved these changes Nov 28, 2025
@yingluAMD yingluAMD dismissed stale reviews from aosewski and bartekxk via 85a34fd December 1, 2025 04:34
@illsilin
Copy link
Collaborator

illsilin commented Dec 2, 2025

Well, you're not actually removing any of the gfx macros, you're just replacing the individual ones like gfx942 or gfx950 with a combined one, gfx9, which gets defined when any of the gfx908, gfx90a, gfx942, or gfx950 are defined. So I'm not sure whether these changes will have the desired effect. Have you actually verified them? Are you able to run ckProfiler with tf32 convolutions on any of the gfx9xx devices with these changes?

@yingluAMD
Copy link
Contributor Author

Well, you're not actually removing any of the gfx macros, you're just replacing the individual ones like gfx942 or gfx950 with a combined one, gfx9, which gets defined when any of the gfx908, gfx90a, gfx942, or gfx950 are defined. So I'm not sure whether these changes will have the desired effect. Have you actually verified them? Are you able to run ckProfiler with tf32 convolutions on any of the gfx9xx devices with these changes?

Yes. __gfx9__ has same scope as __gfx942__ & __gfx950__. It doesn't work on CPU code also. After removing **gfx** macros, ckProfiler build fail on gfx110x. Because TF32 are not supported on those platform currently.
I'm working on a solution to this PR, particularly how to ensure successful compilation when multiple arch build.

@yingluAMD yingluAMD marked this pull request as draft December 3, 2025 02:05
@yingluAMD
Copy link
Contributor Author

Convert to draft PR because it is under development now.

@yingluAMD yingluAMD marked this pull request as ready for review December 4, 2025 09:24
@yingluAMD yingluAMD requested review from a team and ddembeckAMD as code owners December 4, 2025 09:24
@yingluAMD
Copy link
Contributor Author

Update this PR, remove gfx from CPU code is not final solution which introduces build fail on un-support TF32 platform.
Add CK_ENABLE_TF32 to control whether enroll this datatypes compilation. Validated on gfx90a, gfx942 and gfx950.

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.

6 participants