[TVM Discuss] [Development] Google lasted work: MLIR Primer
[quote="tqchen, post:2, topic:1721"] MLIR as itself is a meta-way of defining IRs, in the folks’ word “XML for IRs” ... Concrete compiler solutions still need to be built for each layer of the dialect languages, and they can be very different due to the difference in the semantics of the operators. [/quote] So correct me if I am wrong at interpreting your view: MLIR would be the abstract class of IRs, and IRs at different scopes (i.e. the scope of TVM IR is at a higher level than LLVM IR) would be derived classes of it. In these derived classes (MLIR dialects) the MLIR methods are overloaded (and extended) for specifics of the derived classes. Therefore TVM IR passes are these overloaded methods and we dont have to worry that MLIR will make TVM obsolete? A couple of things which still kind of bugs me with this interpretation are: 1. MLIR seems to (natively?) support descriptions targeted for polyhedral dialects. Since TVM does not use the polyhedral model, I guess we would be limited in the usage of this information but could it also be an impairment? 2. If MLIR is the "root class" of all other dialects, then if a parser reads the highest level input form (ex. ONNX) and translates it into MLIR, how can we ensure that the parser doesnt omit any information which we need in the TVM dialect? --- [Visit Topic](https://discuss.tvm.ai/t/google-lasted-work-mlir-primer/1721/14) to respond. You are receiving this because you enabled mailing list mode. To unsubscribe from these emails, [click here](https://discuss.tvm.ai/email/unsubscribe/79f528aa7e515ec11585670dc434dc73370cf86b45297b42838259e2b137f761). Tianqi Chen, UW, Seattle, WA, 98105, United States http://tracking.discuss.tvm.ai/tracking/unsubscribe?msgid=bLwWY4h8tuQ8Lqt2DFNA5w2
Re: [dmlc/tvm] [RFC][AUTOTVM] Auto-Schedule from Compute Declaration (#2954)
@jroesch There is no easy description for a backend. Currently these meta-templates are mainly based on the summary of existing human schedule code in TOPI. So adding a new backend is still hard. What can be reused is the classification of compute type. @kevinthesun There is only one template for one specific op. The auto-scheduler first creates this template. Then, for static usage, it will fill the knobs in the template according to hardware paremeters. The example shown above falls in this category. For tuning usage, the auto-scheduler won't use hardware parameters. Instead, it relies real tuning. In this case, you need to explicitly create `autotvm.Task`, `autotvm.Tuner`. An example is shown in the tutorial. @yzhliu The `tvm.compute` dsl is much easier to analyze than general Halide IR, because of its clean dependency relations and well-defined loop structure. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/dmlc/tvm/issues/2954#issuecomment-479842520
[TVM Discuss] [Development] Google lasted work: MLIR Primer
Good comments. I would like to separate the answer in two parts, and this is an updated view after I take look at the MLIR's codebase. ## Interpretation of MLIR's Vision I think what you answered reflects MLIR's vision. Make the abstract class of IR and derive dialects. But not necessarily provide specific pass for the dialect, so if X-IR is a dialect of MLIR, then there are dialect specific passes that is needed in the pass. Polyhedral dialect is a dialect in MLIR. In the current case, the polyhedral IR is part of the mlir codebase, which gives the view of "native", but non-the-less it is a dialect just like the other automatic optimization dialect. The fact that it is part of the native code base does give an opinionated view of what what automatic optimization should be like in MLIR ecosystem. I think it is still very much an open problem, TVM has done a lot in this direction, and we can collectively innovate on this area. ## How TVM can work with MLIR First of all, MLIR won't make TVM obsolete. In the contrary, it can help TVM stack by providing insights in IR design and possibly some lowering infrastructure.The community will keep improving our current IR infrastructure toward a better unified TVM-IR infra. We will try to define TVM dialects in MLIR to see if it makes sense to allow bi-directional translation between MLIR and TVM-IR, this way we can take benefit of some of the infra provided by MLIR and make TVM work together with MLIR's ecosystem. --- [Visit Topic](https://discuss.tvm.ai/t/google-lasted-work-mlir-primer/1721/15) to respond. You are receiving this because you enabled mailing list mode. To unsubscribe from these emails, [click here](https://discuss.tvm.ai/email/unsubscribe/ce284d9a37cb5de47ee3fcab532dd17b2fff248996213b64a072d0bd95980f33). Tianqi Chen, UW, Seattle, WA, 98105, United States http://tracking.discuss.tvm.ai/tracking/unsubscribe?msgid=oFfzY6AgreTn0Y-vgk1jfw2
Re: [dmlc/tvm] [RFC][SGX] Use Fortanix EDP instead of rust-sgx-sdk (#2887)
No offense. The difference between rust-sgx-sdk and Fortanix EDP roots from basic assumptions of security. Fortanix EDP is not designed for security, so it has assumptions of trusting the OS. For example, the atomicity of EDP's SGX `RwLock` is **untrusted**. Technically, Fortanix EDP maintains an event queue in **untrusted** space and `RwLock`'s atomicity roots from it -- resulting in untrusted atomicity. For other input/output, they are all interacting with untrusted input/output sources. Are you sure you want it? Every dependency crate would potentially depends on untrusted I/O and weaken your trustworthyness. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/dmlc/tvm/issues/2887#issuecomment-480101073
Re: [dmlc/tvm] [RFC][SGX] Use Fortanix EDP instead of rust-sgx-sdk (#2887)
Hey @dingelish cool to see you here! Thanks a lot for the input. One point of note for the TVM use-case is that the [TVM modules' thread pool already requires cooperation from the OS](https://github.com/dmlc/tvm/blob/master/rust/runtime/src/threading.rs#L132). In almost all (or maybe actually all?) cases, the TVM threads operate on mutually exclusive portions of the output; the operation also doesn't return until all threads have finished their tasks. Accordingly, it's not so important that the thread pool be trusted. TVM also doesn't make use of `fs` nor `net`, so really it's just a matter of threads. With due respect to you and your fantastic `std` facade (and, trust me, there's plenty of that from my end :), the Fortanix programming model is so much nicer more pleasant and flexible. That it is integrated as a Tier 3 target in rustc is no small factor in this proposal. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/dmlc/tvm/issues/2887#issuecomment-480129068
Re: [dmlc/tvm] [RFC][SGX] Use Fortanix EDP instead of rust-sgx-sdk (#2887)
Yeah I 100% trust you :) Correct me if I'm wrong: [`SGX_QUEUE`](https://github.com/dmlc/tvm/blob/7cd986db0e67583bc347ed208c25be4c0d0c32a0/rust/runtime/src/threading.rs#L198) relies on the implementation of `Mutex` inside SGX. In Fortanix's solution, it's relies on [`WaitQueue`](https://github.com/rust-lang/rust/blob/53f2165c544cceeafb308b80ace656ed328c1dc2/src/libstd/sys/sgx/mutex.rs#L25) which depends on [`usercall`](https://github.com/rust-lang/rust/blob/53f2165c544cceeafb308b80ace656ed328c1dc2/src/libstd/sys/sgx/waitqueue.rs#L154) to provide its atomicity. An attacker could easily hi-jack the enclave-runner thus modify the behavior of `WaitQueue` then gain access to the behavior of that `SGX_QUEUE` and further ruins the SGX environment. A short gif to show how an attacker cheats on Fortanix's SGX app:  -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/dmlc/tvm/issues/2887#issuecomment-480147860
Re: [dmlc/tvm] [RFC][SGX] Use Fortanix EDP instead of rust-sgx-sdk (#2887)
Well, if it's any consolation, the [rustc sgx thread implementation does the exact same thing](https://github.com/rust-lang/rust/blob/master/src/libstd/sys/sgx/thread.rs#L64) as we're already doing. Might as well reduce code duplication, right? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/dmlc/tvm/issues/2887#issuecomment-480150939
[TVM Discuss] [Development] [Relay][ONNX] KeyError: 'W' when compiling from onnx
The following error occurs when I try to compile an onnx model. From what I can tell using [Netron](https://lutzroeder.github.io/netron/), there is an input `W`. However, it's not another node but instead some (static) initialization data for the current node. The model can be downloaded here (md5: 2c4009c79e2a5b62d8a3fef14f1fc03b): https://we.tl/t-5E4oXO0Rmq ```python File "/home/martin/Dev/xyz/src/tvm/compile_model.py", line 79, in compile_model relay_func, params = relay.frontend.from_onnx(onnx_model, shape=input_shape_dict, dtype=input_dtype_dict) File "/home/martin/.local/lib/python3.6/site-packages/tvm-0.6.dev0-py3.6-linux-x86_64.egg/tvm/relay/frontend/onnx.py", line 1126, in from_onnx sym, params = g.from_onnx(graph, opset) File "/home/martin/.local/lib/python3.6/site-packages/tvm-0.6.dev0-py3.6-linux-x86_64.egg/tvm/relay/frontend/onnx.py", line 942, in from_onnx inputs = [self._nodes[self._renames.get(i, i)] for i in node.input] File "/home/martin/.local/lib/python3.6/site-packages/tvm-0.6.dev0-py3.6-linux-x86_64.egg/tvm/relay/frontend/onnx.py", line 942, in inputs = [self._nodes[self._renames.get(i, i)] for i in node.input] KeyError: 'W' ``` --- [Visit Topic](https://discuss.tvm.ai/t/relay-onnx-keyerror-w-when-compiling-from-onnx/2102/1) to respond. You are receiving this because you enabled mailing list mode. To unsubscribe from these emails, [click here](https://discuss.tvm.ai/email/unsubscribe/7af8371929998f022d64106c91d401b759bfe3a07bd22e62bd76c9ac17261af7). Tianqi Chen, UW, Seattle, WA, 98105, United States http://tracking.discuss.tvm.ai/tracking/unsubscribe?msgid=t0uhxK4H1l4-VnjUtMSDyA2
Re: [dmlc/tvm] [RFC][SGX] Use Fortanix EDP instead of rust-sgx-sdk (#2887)
The current code of SGX_QUEUE (with rust-sgx-sdk) is not depending on untrusted Mutex -- it relies on sgx_spin to provide atomicity which keeps everything inside. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/dmlc/tvm/issues/2887#issuecomment-480156718
Re: [dmlc/tvm] [RFC][SGX] Use Fortanix EDP instead of rust-sgx-sdk (#2887)
The code you referred to is exactly Fortanix's code. The JoinHandle is implemented using untrusted Mutex. I don't think their implementation could provide any trustworthiness. They bring too much uncertainty to the SGX environment. Personally, I strongly disagree with their implementation because they provide a LibOS-like Rust-SGX environment without any ability to control/audit the usercalls in compile time. It sounds like pushing the programmers to the edge of a cliff and say: you have the choice to not step forward. As an experienced researcher, you can hardly got away from the falling down because too much stuffs depends on their usercalls. The bad design is not desired by Fortanix, but a result of combining libstd to an environment without thread/fs/time/env/process/net. Similar runtimes such as webassembly are facing the same problem. I think you must know [pwasm-std](https://github.com/paritytech/pwasm-std). Parity create this to provide a real runtime for wasm instead of using the default one -- you can open a file in a .rs file and compile it to webassembly, which would triggers a runtime panic. "if it builds, it works" is not true today, due to a bad design of libstd. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/dmlc/tvm/issues/2887#issuecomment-480156261
[TVM Discuss] [Development] Zero copy DLManagedTensor for "set_input"
Any thoughts on the best way to do this? I gave it a shot here: https://gist.github.com/bwasti/a9d3b82d06f0de7df34a04e0c1ae4764 but didn't make much headway -- I hit a hard to decipher error in the Bind logic: ``` RuntimeError: [23:10:17] /home/bwasti/local/pytorch_tvm/tvm/src/runtime/module_util.cc:54: Check failed: ret == 0 (-1 vs. 0) : Assert fail: (int32(arg0.shape[0]) == 33554432), Argument arg0.shape[0] has an unsatisfied constraint ``` --- [Visit Topic](https://discuss.tvm.ai/t/zero-copy-dlmanagedtensor-for-set-input/2103/1) to respond. You are receiving this because you enabled mailing list mode. To unsubscribe from these emails, [click here](https://discuss.tvm.ai/email/unsubscribe/b769a62f38adf9eb2fdc2ee8e22a8f121950a36446d3ae629fc3d6f803e09714). Tianqi Chen, UW, Seattle, WA, 98105, United States http://tracking.discuss.tvm.ai/tracking/unsubscribe?msgid=LNzAk8DCVP3FNYJaemDd8A2
