Thanks @MichaelJKlaiber, that makes sense. So I was wondering if this is the
case, perhaps in the future this interface is used by other backend's (not
accelerators) we would need to think about renaming UMA to something more
generic e.g. UMB _Universal Modular Backend_ - I'm not the best with n
+1
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm/issues/11415#issuecomment-1140867800
You are receiving this because you are subscribed to this thread.
Message ID:
+1
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm/issues/12583#issuecomment-1231558359
You are receiving this because you are subscribed to this thread.
Message ID:
+1, thanks @AndrewZhaoLuo!
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm/issues/13026#issuecomment-1274276016
You are receiving this because you are subscribed to this thread.
Message ID:
+1
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm/issues/14129#issuecomment-1445998174
You are receiving this because you are subscribed to this thread.
Message ID:
Merged #15059 into main.
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm/pull/15059#event-9499825004
You are receiving this because you are subscribed to this thread.
Message ID:
Thanks @ashutosh-arm @NicolaLancellotti!
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm/pull/15059#issuecomment-1586928480
You are receiving this because you are subscribed to this thread.
Message ID:
Merged #15092 into main.
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm/pull/15092#event-9537316075
You are receiving this because you are subscribed to this thread.
Message ID:
Thanks @ashutosh-arm!
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm/pull/15092#issuecomment-1592597165
You are receiving this because you are subscribed to this thread.
Message ID:
Cython `v3.0.0` was recently released
(https://github.com/cython/cython/releases/tag/3.0.0) and is used in newly
built docker images. This causes a compilation issue since 3.0.0 expects
function definitions to be explicitly declared with the `noexcept` annotation.
This change should be backward
Windows and MacOS builds are failing as they use cython==0.29.28 which is not
compatible with the new `noexcept` keyword. This functionality was added in
0.29.31
(https://github.com/cython/cython/blob/master/CHANGES.rst#02931-2022-07-27). We
could either upgrade the Windows and MacOS builds to
After updating the python version to 3.8, the same issues mentioned in
https://github.com/apache/tvm/pull/15346#issuecomment-1640409277 seem to persist
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm/pull/15346#issuecomment-1641976374
You are receiving this be
I've tried reproducing the conda environment used for MacOS with this patch
checked out, although I've been unable to recreate the same failure. The latest
version of cython `3.0.0` is successfully installed.
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm/pu
Closing in favour of https://github.com/apache/tvm/pull/15469, thanks @tqchen!
Let's pull the conda python version upgrade into a separate PR
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm/pull/15346#issuecomment-1664181279
You are receiving this because you
Closed #15346.
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm/pull/15346#event-1338323
You are receiving this because you are subscribed to this thread.
Message ID:
Merged #15747 into main.
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm/pull/15747#event-10588194263
You are receiving this because you are subscribed to this thread.
Message ID:
Thanks @ashutosh-arm @NicolaLancellotti @leandron @neildhickey
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm/pull/15747#issuecomment-1752560774
You are receiving this because you are subscribed to this thread.
Message ID:
Regarding the changes required to support scalability in the data type, I've
been prototyping adding a new `scalable_` attribute to `DataType` that wraps
`DLDataType`.
However, I've ran into what I believe is an issue when accessing data types at
compile-time across the FFI boundary between pyt
A change that has not yet been included in the prototype was the predicate
representation on buffer loads/stores in TVMScript programs. This was briefly
referenced in the RFC:
https://github.com/apache/tvm-rfcs/pull/104/files#diff-6724c2a24eb34f7094b4ff2e8562f7812e6e22c8197f51792f4b5cdfa811fec4R
A RFC for enabling Scalable Matrix Extension code generation in TVM.
You can view, comment on, or merge this pull request online at:
https://github.com/apache/tvm-rfcs/pull/107
-- Commit Summary --
* [RFC] Scalable Matrix Extension enablement
-- File Changes --
A rfcs/0106-scalable-mat
Thanks for taking a look @tqchen! Since scheduling will be completed with
TensorIR, it will provide the building blocks for being plugged into an
IRModule=>IRModule transformation pass. For our current use-case, it's
important to be able to fallback to previous optimizations in the form of TE
s
Got it, thanks @tqchen :) It sounds as though we're already doing something
similar by adding a tag in the compute definition to identify the block during
scheduling.
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/107#issuecomment-1945716982
You ar
Closed #18.
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/18#event-11860567122
You are receiving this because you are subscribed to this thread.
Message ID:
Closing as superseded by: https://github.com/apache/tvm-rfcs/pull/104
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/18#issuecomment-1954039440
You are receiving this because you are subscribed to this thread.
Message ID:
Thanks for the discussion so far @tqchen, I added a small example detailing how
we're registering schedules for the Relay flow. I believe this will have
minimal impact for how the schedule might be used in a Relax based flow, but it
would be good to hear your thoughts.
--
Reply to this email d
Thanks @tqchen, at the moment the Relax flow would be out of scope for our
current use-cases, although we'd want to make sure this RFC doesn't introduce
obstacles for porting to the Relax flow in the future. Do you foresee any
blockers with the current approach, or could we consider merging?
--
Hi, @aca88 I believe your example would be taken care of using the Merge
Composite pass before partitioning. You can imagine that after running this
pass add+conv2d for the blue compiler would be represented by a single node.
The partitioning would then happen as you described. However, this w
Yes that's correct :slight_smile:
---
[Visit
Topic](https://discuss.tvm.ai/t/relay-improved-graph-partitioning-algorithm/5830/20)
to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [click
here](https://discuss.tvm.ai/email/unsubsc
Thanks, I think this will be very useful. I think the benefit of this approach
is that it allows the run-time to be customized much more easily. I like the
idea of being able to cache an *engine* (in my case this will be a series of
ACL functions) - this opens up opportunity for optimization o
## Motivation
[Arm Compute Library](https://github.com/ARM-software/ComputeLibrary) (ACL) is
an open source project that provides hand-crafted assembler routines for Arm
CPU's and GPU's. This integration will look at how we can accelerate CPU
performance for Arm devices in TVM using ACL. The
30 matches
Mail list logo
