New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[RFC] Developer Documentation Feedbacks #2469
Comments
Let me express some thoughts about documentation suggestions from my mind, with the hope that my crude remarks may draw forth by abler people.
I think In this part, we should write the tutorial very detail, from Moreover, we should supply FAQ / Notes of some common error messages. For example, ValueError: Direct host side access to device memory is detected... / can not open shared object... and tell users possible reasons and solutions.
Yes. it is very helpful. I think this diagram is good enough.
In In In In In
Current index is good enough.
Good title should have a help. However, we should list the information on the header of doc, includes the technical area (like frontend, topi and so on), hardware (ARM CPU, GPU, FPGA and so on). |
Having just started to look into using TVM I can only agree with what @FrozenGene is saying in its first part. A hands-on tutorial and please do not just focus it on Python. I think there are plenty of people that do not want to integrate this as another Python framework as there are so many others out that just are Python focused already. I'll get it Python is create for experimenting and doing network design and training but it is not a suitable platform in my eyes for serious end applications. And the C++ deployment documentation so far is thin (that's the best I can say) |
@FrozenGene In the |
@Ravenwater Yes. I propose |
writing new construct in relay has become incredibly tediuos. when i add reference I have to: the same apply for adding another function - pass.py, test_xxx.py, pass.h, xxx.cc, etc. |
I second @FrozenGene's comment. Right now, there's no clear hierarchy in tutorials. We need to consider our users and their level of familiarities. What we would like to give them first and have more for those with more interests. Writing great tutorial is an art and it needs caring which we should strive for when heading to v1.0 release. What we have is good but not good enough. We need
|
If getting more contribution to the docs is also part of the goal, then it's worth thinking about how to shorten the feedback cycle. Currently in TVM, if people find an issue in the doc, they would need to do one of the following:
We tried these things in other projects:
|
IMHO, I need two things to get started quickly.
|
@szha "edit button" will be very helpful. |
I want to clarify that people can directly send a pull request to change the docs, without having to send an RFC issue. RFC is only necessary for new features |
@tqchen I didn't see the RFC process in the contribute guide. Maybe the RFC process (and that doc change doesn't require one) needs to be documented here: https://docs.tvm.ai/contribute/ |
Agreed, that is something that would need to be properly documented, so far the decision of (whether RFC is necessary) is done by lazy consensus from committers |
Maybe starting by improving inline comment style documents? Many of them are only sentences built by five around words like example below. When I using these APIs, I really need to read the implementation detail to know what will happen :( def func_example(a):
"""This is Func example.
Parameters
----------
a: str
arg a
""" |
@jackwish it would be great if you can raise questions about the functions that you would like see improvements, contributions are more than welcomed |
@jackwish Agree. Maybe add usage cases as examples in the comments would be helpful. When I start with something that I don't really know, I usually look into the def func_example(a):
"""This is Func example.
Parameters
----------
a: str
arg a
Examples
--------
>>> a = A(p0=1, p1=2)
>>> b = func_example(a)
b = 1 + 2
""" |
On the other hand, I found there is |
tutorials and some of the apps(extension) are tested by Jenkins. |
@tqchen I will look into things to find where I may contribute some. Like many people have pointed out, maybe we can categorize the materials for users and developers, as users are likely to import/tune/deploy models rather than to dive into IR things. Managing decent documents requires extra effort for contributors. Balancing the tradeoff is art :) |
There are some good points that are mentioned above - having a set of good getting started guides based on different usecases would certainly be a good starting point. One of the things that I found hard to get started with was using tvm as a user was the absence of canned frontends as at the end of the build process one just gets a set of libraries. It is then that one goes and looks at the tutorials for checking that things work just fine - further figuring out the exact version of tensorflow that works with the current trunk of tvm took a bit of time as one cannot expect tensorflow==2.0.0-alpha to work out of the box. Thus follows the question of whether we should also be documenting the versions of the various frameworks that work with TVM for a given version of TVM . I also think that it is worth also creating an issues page which details what is expected in a bug report and how a user should report a bug / what's the minimal set of things we require to see in a bug report so that someone else can reproduce it in order to drive a higher quality of bug reports over time for the community. A link to the ci system from the main website seems due. I stumbled across ci.tvm.ai by accident but it would be good to have some of this handled from the top level. And thanks for reading till here. regards |
Dear all, @tqchen Do we have good documentation for TVM? I am interested in learning more about the TVM compiler optimization strategies especially for Scientific Data for HEP, NP, and DL models for these applications. Any feedback or hint where to start in the source code. |
I had been working on pytorch a bit lately. One thing that is really great about it, is that pytorch has a 'architecture/code structure' document. It is a detailed description of the core system that allow a good outside coder to build a 'mini-pytorch' just by reading it. Should such a thing exist for tvm? |
@MarisaKirisame #6097 aims to achieve part of the goal |
Closing for now, the new design and architecture guide now lands in the official docs https://tvm.apache.org/docs/dev/index.html let us open new ones for further improvements |
There has been a growing demand for better documentation which many of us totally agree. Good developer documentation makes others to quickly jump in to use TVM and helps us to get more community users.
We need your help in giving thoughts on how we can do better, in particular:
Please share your thoughts. We will keep this RFC open for a while. The committers and PMCs will then summarize the discussion into a documentation roadmap and we will make that our top priority in the 0.6 release cycle.
cc @dmlc/tvm-team
Please Comment on Global Docs Organization
This is something that we especially love to pick everyone's brain on. It is very easy to get a bunch of documents, but if we don't organize them clearly and provide pointers they will not be as helpful.
The text was updated successfully, but these errors were encountered: