Documentation
Documentation copied to clipboard
MegEngine
MegEngine Official Documentation
我注意到近期几个版本的文档更新在文档版本切换时将细粒度进行了提升，由 ```shell "." " # 1.13 ``` 变为了： ```shell "." "." " # 1.13.1 ``` 该做法在文档页面中并不常见，好奇这是出于何种考究？通常如果采取此做法，则建议在小的 patch 版本停止更新后，将默认的 minor 版本展示为对应的最新版，参考 [pandas](https://pandas.pydata.org/docs/index.html) 实现。例如：如果 1.12.4 是 1.12 的最后一个版本，那么在 [JSON](https://www.megengine.org.cn/doc/version.json) 格式的配置文件中，应当只保留 1.12 并指向...
需要添加 1. 如何创建一个量化的 Tensor 2. 量化训练时支持哪些量化类型 3. dump quantized 模型时哪些 op 支持哪些量化类型
Module -> Traced Module （下简称 tm） `.tm` -> dump `.mge` -> lite 将作为当前首推的一种训推流程，但目前的文档内容似乎还不足以让已经习惯了 Module -> dump `.mge` -> lite 流程的用户感知到 tm 的存在。 @CaoWGG 已经基于 tm 文档做了一些改进，但目前整个文档的情景连通性依然不足，其实不应该只依赖修改 tm 文档的内容来完成目标，可能需要对已有的文档内容进行补充拓展，希望在这个 Issue 中讨论具体的做法。...
- 在实际开发中，新的dnn kernel的执行过程很可能是复用已有kernel的实现，比如 RNN 理论上可以直接用 MatMul 实现，如何复用、有哪些细节要注意，可以写一下 - dnn 里的 kernel 基本都有 exec、check_exec、deduce_layout、get_workspace_in_bytes，直觉上会以为都是 OperatorBase 这个公共基类的虚函数，但实际上全都不是 - 其中 exec、get_workspace_in_bytes 是每个 kernel op 继承 OperatorBase 后自己定义的虚函数（只是约定俗成每个 op 都用这个名字），还需要每个平台的 Impl 类进一步实现，而 check_exec、deduce_layout 则是同一个...
对应 Meetup 视频：https://www.bilibili.com/video/BV1jw411Z7AG
- 每个新版本发布前后需要注意的流程（API 变动，CI 缓存的清理等等） - 翻译平台的使用，以及平台不可用时的处理方案