areusch commented on PR #12509:
URL: https://github.com/apache/tvm/pull/12509#issuecomment-1233135918

   We discussed this in the [TVM Community 
Meeting](https://discuss.tvm.apache.org/t/next-tvm-community-meeting-aug-31/13439/4)
 this morning. Here are notes:
   
   - All targets derive from a given target kind
   - Targets derived from the `llvm` target kind share common components but it 
is special cased in TVM
       - LLVM targets are presumed to generate a shared library
   - Target kind’s also share a device type relationship, and for llvm this is 
exclusivel kDLCPU
   - Hexagon is an llvm target, however the HexagonDeviceAPI used for Hexagon 
is unique and cannot be supported by the CPUDeviceAPI
   - Desire: Use the llvm target for the compiler and codegeneration, but 
utilize a unique runtime DeviceAPI
       - Q: (and possibly a unique DLDeviceType?)
       - Right now to achieve this one has to override the global registration 
for a kDLCPU DeviceAPI with the HexagonDeviceAPI
   - This PR proposes that just like a target can derive it’s properties from a 
target kind, the target can override the default device type so that a target 
is not bound to a specific device (ie for llvm the user wouldn’t be required to 
utilize a kDLCPU device type for the backing runtime apis)
       - GetTargetDeviceType is the proposed api in the PR to offer the ability 
for different target to provide their own DeviceAPI.
   - Are there other analogies
   - Andrew:
       - Two things being coordinated
           - 1. A runtime module is produced (not contentious)
           - 2. The C++ DeviceAPI, this can change between targets
       - Work has been done in the C-API to support different type of hardware 
runtimes for accelerators
           - Currently makes global function calls based on names with a device 
name prefix
   - Two places to extend the abstraction
   - Current approach in PR has the advantage of changing existing code
       - If we were going to map multiple device types to multiple device api’s 
there would likely need to be more code changes.
   - The DeviceAPI is some what a metadata structure that is provided
   - Virtual device: goal to map between device type and particular subtarget
   - Making a change to allow a target to have it’s own target device type 
would require making some changes about virtual device subtargetting
   - KP: If this PR goes in, I would support it with Hexagon and then would try 
to address different the overuse of kDLCPU as host devices


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to