1. Deprecation of DeviceMode and Changes in DeviceConfig
DeviceMode::MultiCore is no longer supported, rendering DeviceMode unnecessary as there is sufficient information in CoreRange to determine fusion.
Due to this, DeviceConfig has undergone significant changes:
Removal of .fused(). Users must now explicitly specify the number of PEs to fuse using .cores(N).
Elimination of device configuration via device filenames like npu0pe0, since device filenames are not unique among different Archs.
2. Deprecation of CoreStatus::Unavailable
This status previously indicated that at least one core in a range was Occupied by another process. Since this concept overlaps with Occupied, we now return the first Occupied status when a range is unavailable.
Request for Feedback:
There may be a better design around .cores(N). My concerns are:
The term "core" is inaccurate, as (1) the correct term is "PE" and (2) "cores" may imply multicore functionality. Perhaps a term like .fusing(N) might be more appropriate?
Users are now able to specify any number N for fusion, even when N is not feasible. This might not cause runtime issues, as non-fusible N does not correspond to any DeviceFiles, but anyway this design requires users to understand our fusion mechanism better.
This PR introduces two changes.
1. Deprecation of
DeviceModeand Changes inDeviceConfigDeviceMode::MultiCoreis no longer supported, renderingDeviceModeunnecessary as there is sufficient information inCoreRangeto determine fusion.Due to this,
DeviceConfighas undergone significant changes:.fused(). Users must now explicitly specify the number of PEs to fuse using.cores(N).npu0pe0, since device filenames are not unique among differentArchs.2. Deprecation of
CoreStatus::UnavailableThis status previously indicated that at least one core in a range was
Occupiedby another process. Since this concept overlaps withOccupied, we now return the firstOccupiedstatus when a range is unavailable.Request for Feedback:
There may be a better design around
.cores(N). My concerns are:.fusing(N)might be more appropriate?Nfor fusion, even whenNis not feasible. This might not cause runtime issues, as non-fusibleNdoes not correspond to anyDeviceFiles, but anyway this design requires users to understand our fusion mechanism better.Feedback on these points is highly appreciated.