ekalda commented on PR #104:
URL: https://github.com/apache/tvm-rfcs/pull/104#issuecomment-1906190519
[The tracking issue](https://github.com/apache/tvm/issues/16455)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
leandron merged PR #104:
URL: https://github.com/apache/tvm-rfcs/pull/104
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscr...@tvm.apache
ekalda commented on PR #104:
URL: https://github.com/apache/tvm-rfcs/pull/104#issuecomment-1898806879
Thanks @tqchen, good point! I updated the Future Possibilities section with
some ideas for enabling the scalable vector support in the meta schedule.
--
This is an automated message from
tqchen commented on PR #104:
URL: https://github.com/apache/tvm-rfcs/pull/104#issuecomment-1895905346
Thanks for working through this. One final comment, on `Exposing scalable
vectors to tuning`. Iet us discuss through
[MetaSchedule](https://github.com/apache/tvm-rfcs/blob/main/rfcs/0005-me
ekalda commented on PR #104:
URL: https://github.com/apache/tvm-rfcs/pull/104#issuecomment-1895548963
Thanks everyone for all the good discussion so far! ❤️ We've had this RFC
public for over 4 months now and the prototype up for few weeks and from what I
can see, there are currently no ou
ekalda commented on PR #104:
URL: https://github.com/apache/tvm-rfcs/pull/104#issuecomment-1887453205
> if predication is involved, maybe we can explicitly do A.store(...)? where
predicate can be a kwarg
Thanks @tqchen for the good suggestion, I included it into the RFC text (as
an e
tqchen commented on PR #104:
URL: https://github.com/apache/tvm-rfcs/pull/104#issuecomment-1881743971
if predication is involved, maybe we can explicitly do A.store(...)? where
predicate can be a kwarg
--
This is an automated message from the Apache Git Service.
To respond to the message,
lhutton1 commented on PR #104:
URL: https://github.com/apache/tvm-rfcs/pull/104#issuecomment-1881431496
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://gi
ekalda commented on PR #104:
URL: https://github.com/apache/tvm-rfcs/pull/104#issuecomment-1876831048
Happy new year everyone! 🎉 Here's the SVE prototype, as promised -
https://github.com/apache/tvm/pull/16347. It's made by @lhutton1, @neildhickey
and me.
@tqchen @cbalint13 @Lunder
tqchen commented on PR #104:
URL: https://github.com/apache/tvm-rfcs/pull/104#issuecomment-1847333994
> I'm also not sure how this would interoperate with the DLDataType
dependent runtime implementation (but I also don't know the runtime
implementation very well).
Given SVE is only a
ekalda commented on PR #104:
URL: https://github.com/apache/tvm-rfcs/pull/104#issuecomment-1847090278
@cbalint13 @tqchen Thank you for your input! This thread has been dormant
for a bit, but we're still on it!
> A comprehensive presentation on SVE design booth on RISCV and ARM from
tqchen commented on PR #104:
URL: https://github.com/apache/tvm-rfcs/pull/104#issuecomment-1845530627
Just to circle back here a bit. the main root issue is that we are using
runtime::DataType, which is supposely being concrete through out the TIR node.
This places restrictions on wha
cbalint13 commented on PR #104:
URL: https://github.com/apache/tvm-rfcs/pull/104#issuecomment-1841969278
FYI,
@ekalda , @lhutton1 , @tqchen
An comprehensive presentation on SVE design booth on RISCV and ARM from
perspective of LLVM.
The presentation captures all the design details
lhutton1 commented on PR #104:
URL: https://github.com/apache/tvm-rfcs/pull/104#issuecomment-1779468180
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'v
cbalint13 commented on PR #104:
URL: https://github.com/apache/tvm-rfcs/pull/104#issuecomment-1772429695
Thanks @ekalda for the nice work of the proposal, permit few personal point
of views supporting the initiative:
### Pros
> 1. When eyeballing the TIR, the meaning of the `vs
ekalda commented on PR #104:
URL: https://github.com/apache/tvm-rfcs/pull/104#issuecomment-1759954046
I think there's a confusion about the difference between what we have
referred to as `vscale` and `vfactor`. I'll try to summarise the the difference
and the respective pros and cons.
tqchen commented on PR #104:
URL: https://github.com/apache/tvm-rfcs/pull/104#issuecomment-1757910627
I think assuming a single vector width(vscale) and use
`kScalableVectorMark=-1` to mark it would be a good tradeoff, given it may not
be that useful to create vectors with multiple vector w
ekalda commented on PR #104:
URL: https://github.com/apache/tvm-rfcs/pull/104#issuecomment-1757833764
Regarding to changing the `DLDataType`, I can see how it could have a wide
disruptive impact. Scalable vectors are here to stay though, so could be a way
to future proof `DLPack` standard?
ekalda commented on PR #104:
URL: https://github.com/apache/tvm-rfcs/pull/104#issuecomment-1757817798
> I guess we could pass an argument to the vectorizer whether to generate
SVE-friendly code. If this is limited to emitting additional TIR builtins, then
I'm ok with that. I just want to be
kparzysz-quic commented on PR #104:
URL: https://github.com/apache/tvm-rfcs/pull/104#issuecomment-1755730601
> Is there any technical reason blocking us from extending DLDataType to
have a `is_scalable` vector field, allowing us to maintain the meaning of the
lanes field to represent the nu
neildhickey commented on PR #104:
URL: https://github.com/apache/tvm-rfcs/pull/104#issuecomment-1755692891
> Another idea to handle this would be to add a new field to DLDataType,
e.g. bool is_scalable, but I'm not sure how feasible changing that standard is.
I feel extending DLDataTy
kparzysz-quic commented on PR #104:
URL: https://github.com/apache/tvm-rfcs/pull/104#issuecomment-1755456586
I guess we could pass an argument to the vectorizer whether to generate
SVE-friendly code. If this is limited to emitting additional TIR builtins,
then I'm ok with that. I just wan
ekalda commented on PR #104:
URL: https://github.com/apache/tvm-rfcs/pull/104#issuecomment-1753096151
> What I'm aiming at is to be able to lower the TIR to a generic CPU, that
is to an architecture that does not support SVE. The TIR will need to have some
default lowering in CodeGenLLVM/Co
kparzysz-quic commented on PR #104:
URL: https://github.com/apache/tvm-rfcs/pull/104#issuecomment-1751113275
> Could it instead be in a target-dependent lowering pass?
Sure. My idea is to have a single SVE-aware vectorization pass in TVM, and
then be able to utilize it for all target
Lunderberg commented on PR #104:
URL: https://github.com/apache/tvm-rfcs/pull/104#issuecomment-1751100613
> What I'm aiming at is to be able to lower the TIR to a generic CPU, that
is to an architecture that does not support SVE. The TIR will need to have some
default lowering in CodeGenLLV
kparzysz-quic commented on PR #104:
URL: https://github.com/apache/tvm-rfcs/pull/104#issuecomment-1751038124
Sorry for the delay... What I'm aiming at is to be able to lower the TIR to
a generic CPU, that is to an architecture that does not support SVE. The TIR
will need to have some defa
ekalda commented on PR #104:
URL: https://github.com/apache/tvm-rfcs/pull/104#issuecomment-1750730364
I'm back from holiday and want to get this RFC moving again! Thanks for all
the good discussion so far, I've made some changes to the RFC:
* Use `vscale` directly instead of `vfactor` and
27 matches
Mail list logo
