question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

[RFC] tvm.build API for multiple device types

See original GitHub issue

Current Signature

There are two usages of build:

  • Directly takes in a schedule and lower and build a single function
  • Takes in list of LoweredFunc and build a module that support on kind of on device code.
def build(inputs, args=None, target=None, target_host=None, name=None, binds=None):
    pass

The problem of current interface is that it does not support combining module devices code into a single module. Here are some possible API proposals to solve this issue.

Note

Ideally we want to keep API backward compatible, intuitive and concise to use

Proposal 1

Introduce another possible signature handling of build. Allow list of device target and lowered function list being passed, and the build will run the build and combine. The old behavior is always supported for backward compatible reasons.

def build([(device1, lowered_f_list1), (device2, lowered_f_list2)], target_host=target_host):
    passs

Proposal 2

Same as proposal one, but allow input of dict {device : list_of_lowered_f}.

Proposal 3

Add a flag to build to allow it return a pair of (host_code_list, device_module). Run the device module later.

def build(inputs, target, target_host=target_host, delay_host_codegen=True):
    passs

Then the combination codegen and import can happen manually. Please also feel free to put your two cents on what do you think the API should be

Issue Analytics

  • State:closed
  • Created 5 years ago
  • Comments:5 (5 by maintainers)

github_iconTop GitHub Comments

1reaction
zhiicscommented, Sep 25, 2018

I will take this up. I had some preliminary implementation using proposal 3. It looks that proposal 2 is more user-friendly. Let me change to it.

I think there would be more discussions about how we should pass multiple targets to GraphCompile and how a node should take the device information, etc. I will update here when the PR is out.

0reactions
tqchencommented, Sep 29, 2018

closed by #1773 we are not converged to use proposal 2

Read more comments on GitHub >

github_iconTop Results From Across the Web

[RFC] tvm.build API for multiple device types #1752 - GitHub
There are two usages of build: Directly takes in a schedule and lower and build a single function; Takes in list of LoweredFunc...
Read more >
Pre-RFC: Multiple device support in Relay VM
Currently the Relay VM only supports a single device: It would be useful to support multiple devices, e.g. for heterogeneous splitting of ...
Read more >
TVM Change Log - Google Git
TVM Change Log. On-going version; 0.8. Accepted RFCs; Features and Improvements. TE, TIR, TVMScript; AutoTVM, AutoScheduler, Meta Schedule ...
Read more >
[GitHub] [tvm-rfcs] gromero commented on a change in pull request ...
This search process requires that TVM iteratively build and time code on the ... API server `connect_transport` method to connect to the remote...
Read more >
RFC 7807: Problem Details for HTTP APIs
This specification does this by identifying a specific type of problem (e.g. ... Likewise, in many situations, there is an appropriate HTTP status...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found