Skip to content

Bump rocm-systems from a08170b to 0eccbf0 #2533

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.

Sign up for GitHub

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

Closed
dependabot wants to merge 2 commits into from
Closed

Bump rocm-systems from a08170b to 0eccbf0 #2533

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
566c76e
Bump rocm-systems from `a08170b` to `0eccbf0`
dependabot[bot] Dec 12, 2025
765aeaa
Delete patch that is no longer needed
ScottTodd Dec 12, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
38 changes: 0 additions & 38 deletions patches/amd-mainline/rocm-systems/0002-Revert-hsakmt-bump-vgpr-count-for-gfx1151-1807.patch
View file
Open in desktop

This file was deleted.

2 changes: 1 addition & 1 deletion rocm-systems
Open in desktop

@ScottTodd ScottTodd Dec 13, 2025

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

MIOpen errors might be new? https://github.com/ROCm/TheRock/actions/runs/20178397152/job/57947116991?pr=2533#step:10:9651

[ RUN      ] Full/GPU_SoftMarginLossForward_FP32.Test/31
/__w/TheRock/TheRock/rocm-libraries/projects/miopen/test/gtest/main_hip.cpp:16: Failure
Expected equality of these values:
  hipError
    Which is: 709
  hipSuccess
    Which is: 0
 hipGetLastError returned error code 709 after test Full/GPU_SoftMarginLossForward_FP32.Test/31. Error string: context is destroyed

[  FAILED  ] Full/GPU_SoftMarginLossForward_FP32.Test/31, where GetParam() = dims:32x80x870 strides:69600x1x80 reduction_mode:2 (224 ms)
[ RUN      ] Full/GPU_SoftMarginLossForward_FP32.Test/35
/__w/TheRock/TheRock/rocm-libraries/projects/miopen/test/gtest/main_hip.cpp:16: Failure
Expected equality of these values:
  hipError
    Which is: 709
  hipSuccess
    Which is: 0
 hipGetLastError returned error code 709 after test Full/GPU_SoftMarginLossForward_FP32.Test/35. Error string: context is destroyed

[  FAILED  ] Full/GPU_SoftMarginLossForward_FP32.Test/35, where GetParam() = dims:16x1x512x512 strides:262144x262144x512x1 reduction_mode:2 (126 ms)
[ RUN      ] Full/GPU_SoftMarginLossForward_FP32.Test/39
/__w/TheRock/TheRock/rocm-libraries/projects/miopen/test/gtest/main_hip.cpp:16: Failure
Expected equality of these values:
  hipError
    Which is: 709
  hipSuccess
    Which is: 0
 hipGetLastError returned error code 709 after test Full/GPU_SoftMarginLossForward_FP32.Test/39. Error string: context is destroyed

[  FAILED  ] Full/GPU_SoftMarginLossForward_FP32.Test/39, where GetParam() = dims:64x3x80x80 strides:1632000x544000x6800x85 reduction_mode:2 (779 ms)
[ RUN      ] Full/GPU_SoftMarginLossForward_FP32.Test/43
/__w/TheRock/TheRock/rocm-libraries/projects/miopen/test/gtest/main_hip.cpp:16: Failure
Expected equality of these values:
  hipError
    Which is: 709
  hipSuccess
    Which is: 0
 hipGetLastError returned error code 709 after test Full/GPU_SoftMarginLossForward_FP32.Test/43. Error string: context is destroyed

I don't see those errors on prior runs like https://github.com/ROCm/TheRock/actions/runs/20161420559/job/57887263645 or https://github.com/ROCm/TheRock/actions/runs/20142068252/job/57828277825

@ScottTodd ScottTodd Dec 13, 2025

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Huh? Each of the 4 MIOpen test shards ran the same tests? Is sharding doing anything there?

@geomin12 geomin12 Dec 13, 2025

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

hm... it should be sharding: Note: This is test shard 2 of 4. based on the logs...

@jayhawk-commits jayhawk-commits Dec 15, 2025

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

CC'ing @BradPepersAMD for awareness

@BradPepersAMD BradPepersAMD Dec 16, 2025

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

We added a check at test end to verify that the hipGetLastError is hipSuccess. We did this a while back and things have been working so it seems like either there was a HIP systems change that broke this last error code or something we were doing before that didn't cause an error, is now actually getting caught. The error being that the context has been destroyed is maybe indicating we're now doing something we shouldn't after the context has been destroyed. we'll investigate but it seems odd it was running fine and then failed on a systems update.

@BradPepersAMD BradPepersAMD Dec 16, 2025

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

best way to test will be to get this env and run the test and see it fail and then run again with MIOPEN_LOG_LEVEL=7 and MIOPEN_ENABLE_LOGGING=1 to see all the hip calls and find what is failing. I can have someone do that tomorrow.

@ScottTodd ScottTodd Dec 16, 2025

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Docs for reproducing:

@DarylHawkinsAMD DarylHawkinsAMD Dec 16, 2025 •
edited
Loading

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Huh? Each of the 4 MIOpen test shards ran the same tests? Is sharding doing anything there?

For this test suite, it's running different test cases from the suite across different shards. You can see here that the test case number at the end of the full test name is different per shard:

miopen_gtest shard 1:

[  FAILED  ] Full/GPU_SoftMarginLossForward_FP32.Test/32, where GetParam() = dims:32x80x870 strides:69600x870x1 reduction_mode:2
[  FAILED  ] Full/GPU_SoftMarginLossForward_FP32.Test/36, where GetParam() = dims:2x3x160x160 strides:6528000x2176000x13600x85 reduction_mode:2
[  FAILED  ] Full/GPU_SoftMarginLossForward_FP32.Test/40, where GetParam() = dims:64x3x40x40 strides:408000x136000x3400x85 reduction_mode:2
[  FAILED  ] Full/GPU_SoftMarginLossForward_FP32.Test/44, where GetParam() = dims:56x4 strides:4x1 reduction_mode:2
...

miopen_gtest shard 2:

[  FAILED  ] Full/GPU_SoftMarginLossForward_FP32.Test/33, where GetParam() = dims:4x182403x91 strides:16598673x91x1 reduction_mode:2
[  FAILED  ] Full/GPU_SoftMarginLossForward_FP32.Test/37, where GetParam() = dims:2x3x80x80 strides:1632000x544000x6800x85 reduction_mode:2
[  FAILED  ] Full/GPU_SoftMarginLossForward_FP32.Test/41, where GetParam() = dims:22311x80 strides:85x1 reduction_mode:2
[  FAILED  ] Full/GPU_SoftMarginLossForward_FP32.Test/45, where GetParam() = dims:131x4 strides:4x1 reduction_mode:2
...

Shard 1 has cases /32, /36, /40, /44, ... and shard 2 has /33, /37, /41, /45, ...

I've tried to reproduce this, but these tests pass on a gfx942 with the environment recreated according to TheRock documentation you linked so we're still investigating.

Submodule rocm-systems updated 919 files
Loading