Closed tqchen closed 4 years ago
test_forward_ssd_mobilenet_v1
to tflite/test_forward (#3350)ci_cpu,i386
to include verilator (#3738){ci_gpu, demo_cpu, demo_gpu}
docker images (#3692)relay.testing.mobilenet
(#3886)USE_LLVM
to take extra arguments (#3954)test_forward_ssd_mobilenet_v1
(#4373)get_int_tuple
. (#2691)__init__
for cpu (#2855)init_proj.py
: Team ID expected (#2824) find_llvm
when specify llvm-config (#2758) out_dtype
for conv2d_NCHWc
and Relay (#2702)std::unary_function
(#2962)conv2d_transpose
(#3138)get_valid_counts
(#3151)group_conv2d_nchw
not supported (#3195)build_module
creation (#3198)vta_conv2d
crash issue after change vta_config.json
(#3213)tensor_expr_get_started
(#3330)alter_op_layout
(#3264)sum
and all
on axis=0
(#3422)LSTMBlockCell
in Tensorflow frontend (#3410)device_api.ext_dev
call in VTA. (#3843)if_then_else
, power (#3829)visit_pattern
in ExprMutator (#3769)compile_cmd
kwarg name change (#3746)ir_pass.h
(#3741)div_sqrt_dim
(#3701)gather_nd
in Relay (#3442)tvm.convert
and tvm.const
(#3861)pad_mode
support for onnx converter (#4029)post_stmt
in loop partition (#3734)floormod(x, y) != 0
(#4127)y < x && x <= y
(#4220)n_trial
number in autotvm tutorials' progress bar if n_trial
is larger then config space. (#4070)__floatdihf
in libtvmruntime.so on aarch64. (#4119)callback_get_section_size()
(#4221)batch_norm
op params well (#4310)memory_id
is VTA_MEM_ID_OUT
(#4330)schedule_conv2d
(#4358)python
command exist on the host. See forum discussion for details.topi.floor_div
is inconsistent with floor division semantic when result number is close to an integer.Though C++ RPC haven't been reviewed, personally, I wish C++ RPC https://github.com/apache/incubator-tvm/pull/4281 could enter into 0.6, which is a very useful feature in embedded devices, we almost use it in our production development every day.
I updated the issue, please let us know if anything's missing. (I didn't include "Build and Test" and "Bug fixes" section as the entire content happens to be long enough that github prevents me from posting it.)
One thing we need to discuss is whether NNVM needs to be deprecated in v0.6 release and how.
wrt to nnvm. Our original proposal is to keep nnvm until v0.6 release. Which means nnvm will appear in v0.6 with limited support(the legacy api still passes test cases). Then we will remove nnvm compiler support after v0.6 release
@tqchen Shall we print warning message when ppl use nnvm?
Yes, we can do that
Should we have a known issues section ?
These are some initial thoughts from the top of my head over the last 5 minutes. I am sure that there are more.
Tflite rounding vs tvm rounding causing differences in accuracy and potentially off by 1 errors. For reference https://github.com/apache/incubator-tvm/pull/3900#discussion_r334324818 . If we release without the PR, atleast we need a note about this.
We should make it clear that the tflite pre-quantized network support is still a work in progress and the project would welcome further contributions.
Do we as a community need to get any open correctness issues fixed before the release ? I'm assuming a quick scan has been performed.
In terms of 0.7 onwards I think we should be starting to think about criteria for a release and come up with some initial strawman proposals.
regards Ramana
@u99127 Good idea, will add.
Kindly remind that we would like to cut the release branch as well as the RC tag (RC0) this week. If you want to get any feature into the v0.6 release, please let us know. Once the release branch is cut, we no longer take new features. Bug fixes can still get in if necessary (but that means we need to cut another RC and go through the voting process again). @apache/tvm-committers
Symbolic Shape Enhancement: Add more shape functions commonly used in cv models: https://github.com/apache/incubator-tvm/pull/4179
@kevinthesun Thanks. I'll go through the merging history make sure everything since the last monthly report gets into the release note.
We need to update benchmarks to use Relay, before we deprecate NNVM.
I don't have access to some of the devices, I can update the others. @merrymercy @tqchen what's your suggestion?
@yzhliu We'd love to push #4305 #4321 #4341 #4342 (fix and refactoring for AMD gpu backend) into TVM 0.6 release. thx
@ZihengJiang can you help look into update the benchmark script?
@yzhliu @ZihengJiang I can provide some input for AMD gpu backend. please tag me in your PR. thanks
I updated the release notes to include recent changes, as well as some known issues as @u99127 suggested. please let me know if I missed anything.
typo: enhence -> enhance
@vinx13 thanks. updated.
folks, is there anything need to be merged? I plan to cut the release branch the end of the day.
@yzhliu let's get #4295 in, it's ready to merge once ci passed
There is a temporary ci outrage due to http request timeout of the dataset let us make sure the ci is green. See also https://github.com/apache/incubator-tvm/issues/4378
@tqchen should we wait till #4378 is fixed?
That should be a quick fix(see the reference PR which fixed a related problem. I would recommend doing so
There are two weird characters, I am not sure if this is the issue of my browser:
1) After the sentence "Formalize Integer Arithmetic Analysis" 2) After the sentence "Support SpaceToBatchND/BatchToSpaceND in Tensorflow frontend".
do we have the deadline now? because i have one pr of thread performance #4344
I have created v0.6.0 branch. I'm about to update the release notes.
Release note updated. Also remove the unexpected characters Thanks @junrushao1994
The next steps are roughly,
@yzhliu can we start a RFC thread before vote on dev@? just like a discuss thread that we can get feedbacks, before we open a vote, we can also invite ASF mentors to help check (after some thoughts, i think we could go with vote by checking the following items)
FYI, the common checklist used for apache incubator release
@tqchen RFC after tag?
sounds good
@tqchen , @yzhliu - please send request to review release candidate to dev@ list for TVM because not everyone probably subscribe or follow the Github repo list.
Before going to general@ list, let's vet and review the release candidate in the podling community to reduce the noise in the channel.
Thanks
Thanks Henry This thread is already on dev@ :) — all github thread with RFC and DEV tags are automatically mirrored at dev@
To further reduce the noise for our ASF PMC members and mentors, I would recommend future tag release related thread with [RELEASE] prefix, so our those who only want to watch related thread can setup email filter to watch this prefix
Thanks, @tqchen, Yes, I just noticed the emails also sent to dev@ list too :+1:
@hsaputra , I remember the release artifact needs to be uploaded to apache dist svn https://dist.apache.org/repos/dist/dev/incubator/ , is it still required? I don't see tvm under the repository, shall we create one?
Dear Community, thanks to everyone's effort in the past few months. This is a proposal to do a v0.6 release.
This release will be managed by the TVM PMC, with @yzhliu and myself as moderators. In the next few days we will be populating the release note in this thread. Most release note content will be derived from our monthly report
We also encourage everyone in the community to reply to the thread about pending PRs that should be included in the v0.6.
It is our first release after moving to the apache repo. So the main goal is about passing the general reviews to make sure the released product matches the ASF requirements. We hope that we can use this release to streamline the future releases
New Features
Relay in Production
Relay is a functional, differentiable programming language designed to be an expressive intermediate representation for machine learning systems. Relay supports algebraic data types, closures, control flow, and recursion, allowing it to directly represent more complex models than computation graph-based IRs (e.g., NNVM) can. In TVM v0.6, Relay is in stable phase and is ready for production.
Relay Virtual Machine
The Relay Virtual Machine (Relay VM) is the new generation of runtime to strike a balance between performance and flexibility when deploying and executing Relay programs. Previously, the graph runtime is able to utilize the fully static nature of the input graphs to perform aggressive optimization such as fully static allocation, and optimal memory reuse. When we introduce models which make use of control-flow, recursion, dynamic shapes, dynamic allocation we must change how execution works.
Relay VM is now usable and is able to achieve decent performance for a various of models and targets.
Training
Relay is designed to natively support first-order and higher-order differentiation. The automatic differentiation infrastructure is now usable and a count of operators with gradient support are available in v0.6 release.
Quantization
Low-bit inference is getting more and more popular as it benefits both the performance and storage usage. TVM now supports two types of quantization. 1. Automatic quantizaion takes floating-point precision model, does per-layer calibration and generates low-bit model. 2. TVM also imports pre-quantized model from Tensorflow and MXNet, a new dialect QNN is introduced to handle further lowering to normal operators.
Accelerator and Microcontroller Support
TSIM is introduced to improve software and hardware integration and simulation accuracy. It integrates the hardware development process into the software stack. TSIM enables VTA to provide a more accurate performance feedback, i.e. clock cycles, compared to the traditional functional model of a hardware accelerator. Moreover, Chisel implementation for VTA is availale and it runs on top of TSIM.
There has been a proliferation of resource-constrained and embedded devices that do not have operating systems or a mature software stack. MicroTVM is intended to support TVM on such bare-metal devices.
Rust Support
Rust language support in TVM includes two parts. 1. The frontend wraps the current C API and exposes a Rust programming model. 2. The backend serves as an alternative to C++ runtime. It privdes a standalone WASM module and security support, e.g., SGX.
Operator Support
annotation.stop_fusion
to prevent it being fused with previous expressions (#2624).batch_matmul
supported (#2561).reverse_reshape
supported (#2503).yolo_reorg
(#1941).slice
operator for MXNet (#2662).arange
supported (#2621).roi_align
(#2618).where
operator for MXNet (#2647).intel_graphics
conv2d , depthwise conv2d (#2729, #2806)conv2d_transpose
CUDA schedule template (#3796)sparse_transpose
for Square CSR matrices (#3707)erf
,logical_and
,logical_or
,logical_not
,isnan
(#3702, #3929, #3979)ceil_divide
in tile/split (#3842)crossentropy_with_logits
and its gradient (#4075)Frontend and User Interface
_convert_reshape
(#3846)batch_to_space_nd
,space_to_batch_nd
, tanh, greater, relu (#3850, #3996, #3963, #4022)zeros_like
tflite operator (#4042)tf.no_op
to TF Relay frontend. (#4172)build_create_shared_func
to tvm/contrib/cc.py (#3840)HybridModule
(#2477) so that normal TVM schedule can be compiled to hybrid target, run and dumped to Hybrid Script.add_n
(#4181)quant.mul
operator in tflite frontend (#4283)conv2d_transpose
. (#4300)Runtime and Backend Support
Language and Architecture
conv_2d_transpose
(#3469)mac_count
pass (#3083)EQ
op in the deduce bound and the loop partition (#3775)Feature Improvement
Symbolic shape enhancement
Language and Architecture
build_func
in measure module of autotvm to better support cross compiler (#2927)schedule_injective_from_existing
and unify external schedules for all targets (#3983)lift_if_then_else
pass to improve loop partitioning (#3865)tensor_t
(#4233)disable_assert
to control whether to generate assert. (#4340)Arithmetic Analysis
Runtime and Backend Support
code_object_v2
for amd gpu backend (#4099)Frontend and User Interface
max_num_threads
to Hybrid Script, which allows users to get max number of threads for GPU targets (#2672).input_0d_mismatch
special handling for TF Frontend(#3087)get_workload
- (#3483)AutoTVM
register_topi_compute
andregister_topi_schedule
. (#3292)Performance Improvements
non_max_suppression
andget_valid_counts
for CPU (#3305)roi_align
performance for CPU (#3296)nms
andget_valid_count
performance (#3282)set_input
andset_input_zero_copy
overhead (#3805)conv2d_transpose
schedule on X86 and CUDA (#3948)Depreciations