feat(rocdbgapi): introduce clusters of workgroups - #7992
Conversation
✅ All Policy Checks Passed
📖 Need help? See the Policy FAQ for details on every check and how to fix failures. |
|
🚫 Please fix the failed policies before requesting reviews. The following policy checks failed:
The |
lancesix
left a comment
There was a problem hiding this comment.
A first quick pass, this looks promising already, thanks!
In the commit msg for "rocdbgapi: create clusters of workgroups"
"We have to consider take the cluster id" either "consider" or "take" is too much.
c6dff6d to
5c4c116
Compare
|
The update above has two major differences wrt to the previous revision:
|
5c4c116 to
6c615bc
Compare
|
I addressed some of Lancelot's comments. There are still a few opens that need to be clarified. |
8fd0911 to
e9ea232
Compare
e9ea232 to
5ccf7d9
Compare
|
The latest push is only a rebase. |
5ccf7d9 to
d171615
Compare
|
The update above addresses the comments received so far. |
I updated the GDB PR accordingly: |
| private: | ||
| /* If the cluster to which this workgroup belongs has non-empty | ||
| coordinates, the group ids give the coordinates of this workgroup | ||
| within the cluster. Otherwise it is the coordinates within the |
There was a problem hiding this comment.
Didn't this change?
We could also keep internal to dbgapi the workgroup in cluster, and only expose the workgroup in grid coordinates to the client.
There was a problem hiding this comment.
Didn't this change?
Yes, sorry. I'll fix this, too.
We could also keep internal to dbgapi the workgroup in cluster, and only expose the workgroup in grid coordinates to the client.
In HIP, blockIdx still refers to the coordinates within the grid, regardless of being in cluster mode. Hence, it makes some sense to use grid-wise index, but I don't have a strong connection to this choice.
There was a problem hiding this comment.
having blockIdx be grid-relative is probably the argument to go this way as well!
972adda to
62cfcaf
Compare
lancesix
left a comment
There was a problem hiding this comment.
I think we are almost there.
62cfcaf to
60892d9
Compare
|
@lancesix, the last force-push updates the |
60892d9 to
42d3a6e
Compare
|
The force-push above introduces queries to get workgroup ids within the cluster. |
42d3a6e to
18c37dd
Compare
In two places, we get a workgroup's ids by calling `group_ids ()`, which returns an optional tuple, and if the optional is non-empty, we call `group_ids ()` again. Avoid the duplicated call.
A workgroup is alive as long as it has a wave. Set the epoch mark unconditionally, whenever the mark of any wave of the workgroup is being set. In practice, this should not change the epoch value of a workgroup. This change is a refactoring to obtain clearer and simpler code.
Starting with gfx12-5, workgroups may belong to clusters. Add methods to read cluster ids from a CWSR record. The cluster and group ids are read from TTMP registers. The meaning of the registers depend on whether the wave is in cluster mode. If not in a cluster, group ids are obtained from TTMP7 and TTMP9 as in previous gfx12 architecture. If in a cluster, what we read from TTMP7 and TTMP9 are cluster ids. The group ids in this case are read from TTMP6. To figure out if the wave is in cluster mode, we keep track of the "first_of_cluster" and "last_of_cluster" bits in the compute relaunch wave register. All CWSR records created for waves between the first and the last of cluster (inclusive) are marked to be in a cluster. Bug: AIROCGDB-77
Add a first definition for clusters, which are groups of workgroups. Bug: AIROCGDB-77
Starting with gfx12-5, workgroups may be grouped into clusters. When creating workgroups, take this into account. Note that being part of a cluster is not mandatory. In that case, the cluster id would be std::nullopt. We nevertheless create clusters and associate workgroups to them, to avoid having to handle non-cluster mode separately. In cluster mode, a cluster id would be a valid 3D coordinate. In this case, a workgroup's group id is not necessarily unique. We have to take also the cluster id into account to identify workgroups uniquely. This patch adds clusters into the wave -> workgroup -> cluster -> dispatch hierarchy. API queries are added in the next patch. Bug: AIROCGDB-77
Define new enums in the API to query the cluster coordinate of a wave and a workgroup, and other cluster-related information. Bug: AIROCGDB-77
Add API query to obtain cluster sizes. To be in consistence with the existing queries that return workgroup sizes and grid sizes (i.e. AMD_DBGAPI_DISPATCH_INFO_WORKGROUP_SIZES and AMD_DBGAPI_DISPATCH_INFO_GRID_SIZES), the new query (i.e. AMD_DBGAPI_DISPATCH_INFO_CLUSTER_SIZES) returns the sizes in units of work-items. Bug: AIROCGDB-77
18c37dd to
95fde49
Compare
|
The latest push above is only a rebase. |
…uster Add a workgroup query and a wave query to get the workgroup coordinates within the cluster the workgroup belongs to.
95fde49 to
5a105b3
Compare
|
The push above removes two more "... in units of ..." sentences. |
Motivation
Add a new level of hierarchy, "clusters", to the layering of wave -> workgroup -> cluster -> dispatch.
Technical Details
Define clusters as a new layer, similar to how workgroups are defined.
JIRA ID: AIROCGDB-77
Test Plan
To be done covered by GDB tests.
Test Result
Not yet available.