[Doc] Visualize the architecture using a UML sequence diagram

[vacu9708]

Summary

I thought that high-level diagrams of each TVM module would help new contributors make sense of the architecture, lower the barrier to entry, and ultimately speed up development.
Therefore, I've started with visualizing Relax.

Candidate diagrams

I created two diagrams illustrating the same workflow—a block diagram and a UML sequence diagram—and I’d appreciate your feedback on which is more effective.

Block diagram (drawn with draw.io)
relax-block_diagram.drawio.txt

UML sequence diagram (drawn with plantUML)
relax-sequence_diagram.puml.txt

In my opinion, the text-based diagram drawn with plantUML would be better for maintainability.

Changes

• Add a diagram to the document to visually represent interactions between Relax components and their dependencies
• Fix typos

Since this is my first time uploading images to the docs, please let me know if anything needs adjusting.

[tqchen]

usually we don't include the image source in the tree to avoid binary blob, in the past we put image links (see other tutorials) and refer to them.

From the perpsective if overall architecture, I think documenting general philosophy that centeralizes IRModule would help , without going into too much details, like the overall flow image in https://tvm.apache.org/docs/how_to/tutorials/e2e_opt_model.html

[vacu9708]

@tqchen I understand your point that the detailed diagrams for each TVM module are unnecessary.

I’ve now created a more abstract UML sequence diagram that centralizes the IRModule.
Would this help lower the barrier to entry for new contributors?

• If so, I’ll update the commit for the docs to include it below the "Overall Flow" image.
• Otherwise, I’ve left only the typo fixes in the commit. Could this commit be merged?

relax-sequence_diagram.puml.txt

[tqchen]

Thanks @vacu9708 , the main issue is that we don't want to focus on a single flow, for example, meta-schedule step can be optional, and we would like to focus on the general setups, e.g. what would the overall flow composition and API related to them looks like. Maybe what we can do first is to give examples of API used wrt to the overall flow figure.

We are in middle of refactoring that hopefully to finalize in next few month, where the architecture roughly will follow the generall overall patterns. At high-level we would like to convey:

• We have target specific pipelines that follows a general pattern https://github.com/apache/tvm/blob/main/python/tvm/relax/backend/gpu_generic/pipeline.py and https://github.com/apache/tvm/blob/main/python/tvm/relax/pipeline.py
  • library_dispatch->legalize->dataflow_lower->finalize
  • Each pass in such transformation is customizable
• The executable part runs on an unified FFI mechanism that we are in the process of refactoring and likely should be documented separately

also cc @Hzfengsy

[Hzfengsy]

Thanks @tqchen, I agree that we don't want to focus on a single compilation path. However, it would be good to have documentation for common practice, I think those documents PR should be welcomed by the community