Device API Review #16497
ayerofieiev-tt
started this conversation in
General
Device API Review
#16497
Replies: 1 comment
-
CC @tt-asaigal |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Device API Review
Device class has 177 symbols exposed (members and member functions).
After initial cleanup we get to 132, which is still unreasonable.
Here we share the review of existing Device functions.
Summary
Recommendations
get_soc_descriptor() const
Details
These methods are just proxying a call to Cluster giving it device id.
For example
It is convenient, but it also means MeshDevice and MockDevice have to implement.
Where possible - return metal_SocDescriptor or let user ask Cluser directly
Whats arch specific vs device specific?
Next group of methods is proxying a call to Allocator.
For example
Convert Allocator to a class. Move these convinience methods to it.
Let user get allocator from device and query info from there
Only used in tests
Can be extracted out of device? (No longer has to be this way as of couple weeks ago)
We don’t really need them both
Next group could be private but they are actively used by DevicePool to maintain device lifecycle
17 arguments, (already fixed)
Only used in Buffer
Template will have to be removed for interface
We are leaking a detail about Worker here. If we are ok about it - we should remove methods and give worker outside?
Delete, users can ask ProgramCache directly
Lets review if we can remove the template from here
Only used by Program
Have no idea what these methods are
Subdevice concept and apis must be reviewed and revisited
Single usage in Command Queue
Single usage in tt_metal
Trace maintains the value and device is only used to store the value, bad design
Single use in device pool
Should device init allocator wit this scheme and should users ask allocator directly?
Beta Was this translation helpful? Give feedback.
All reactions