This looks reasonable to me, it's not something we require for Ethos-N but I
can see why it may be desirable. I am noticing quite a bit of API creep around
BYOC though. We never really settled on a way to encapsulate the partitioning
passes and now we have another special pass that may or may
Welcome to the TVM community :)
Mali doesn't really have an equivalent to Nvidia's shared memory, it uses the
system RAM backed by an unconfigurable cache. Local is just OpenCL's term for
CUDA's shared. This means that using explicit cache read/writes to shared/local
aren't advised when optim
Thanks for this RFC, it looks awesome! I've had a quick read through the paper
but I think it will take me some time to understand the details. Just a few
initial questions:
* Do you see this replacing most or all of the scheduling that's currently in
TOPI eventually?
* Will there be a way t
By this do you mean, for instance, paritioning a graph for GPU/CPU with both
going via TIR lowering?
---
[Visit
Topic](https://discuss.tvm.ai/t/rfc-ethosn-arm-ethos-n-integration/6680/18) to
respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these
For our codegen, the check functions are actually quite complex. They're not
just attribute checks, there's also things relating to tensor sizes, number of
dimensions and quantisation parameters. Additionally, our codegen library
exposes an API to check whether a given operator is supported fo
I think it would be good to know the pattern matcher has the flexibility to
annotate rather than partition. However, that will be a more significant change
to the overall BYOC flow so the priority first should be just replicating
existing functionality as described in this RFC.
---
[Visit
Thanks for this RFC Cody! I fully agree this pass should be re-implemented
using the pattern language, the logic was very much a stop-gap solution until
more powerful pattern matching appeared.
Do you envisage this having a similar API to the existing pass? In particular
it's important for us
@comaniac Regarding composite vs. single operators, we actually have more
single ops than patterns. The composite functions appear more frequently though
pretty much entirely because of qnn.conv2d.
>From our perspective, composite pattern matching and merging annotation
>regions are no more o
This would be a welcome addition to the BYOC infrastructure, particularly in
reducing the fragmentation between approaches for different backends. I think
it's also important we have a robust alternative to the CSourceModule approach
as it's becoming clear that's not yet suitable for full scal
As far as I can tell, we'd still need MergeComposite. The main difference would
be that we could replace the custom pattern-matching solution with this generic
and more powerful pattern-matching. However, the creation of the composite
functions will need to remain.
---
[Visit
Topic](http
10 matches
Mail list logo
