for zip, you don’t need to use vrgather. instead, use vector widening (eg vwaddu with x0) to double the element size (ensuring the MSBs are 0) for one half of the set. apply vslide1up and widening to the second set, then add the two sets (using original SEW).
for unzip, you can do the reverse. use narrowing for one half and vslide1dn (in SEW/2) + narrowing for the other half.
sorry, what is trn?
g
Hi, I agree that computing those indexes is not always trivial Some ideas you can consider (not claiming these are the most
efficient ways)
- reverse is not too complex: vid.v + vrsub.vx using vl as the
scalar to subtract
- zip is harder: start with the "halved indexes" vid + vsrl.vi
(0, 0, 1, 1, 2, 2, 3, 3, ...) then compute the "even elements"
vector (0, 1, 0, 1, 0, 1, ...) and then multiply it (or if a
power of two, shift) with the first index of the second vector
(which maybe is vl/2 in your case). So you get 0, vl/2, 0, vl/2,
0, vl/2, .... Then add this vector to the halved indexes so you
get 0, vl/2, 1, 1+vl/2, 2, 2+vl/2, ...
- unzip worst of the cases you can reverse what you did for zip
- trn I don't have any ideas from the top of my head, /cc Romain
Dolbeau who may recall how he worked around the cases in FFTW
where he needed a trn-like operation
Hope this helps. Kind regards,
Dear Craig and Roger,
Thanks a lot for providing me good
solution. I have tried them, they are all good solutions of
upsample application. But, when it comes to other applications, such as zip/unzip,
trn，reverse and so on. The Index value is still difficult to be initialized.
------------------原始邮件
------------------
发送时间:06/11/21 18:51:12
主题:Re: 回复：[RISC-V] [tech-vector-ext] RISC-V Vector
Spec version 1.0-rc1-20210608
Hi Linjie,
I'm not sure I understood your question. I think a vid.v (with a vl of your choice) that then you
(logical) shift right 1 bit (vsrl.vi)
would generate an index like the one you have now the "index[]" array.
This looks like it does not require to hardcode any size and
you don't have to load a materialised value from memory (you
compute it instead).
Hope this helps.
Kind regards,
Hi, all
I encountered a difficulty of applying
"vrgather" instruction recently. The details are shown blow: The date from source should be duplicated as pair
in a upsample application. Eg: src = [0, 1, 2, 3, 4, 5, 6, 7, 8] dst = [0, 0, 1, 1, 2, 2, 3, 3, 4, 4, 5,
5, 6, 6, 7, 7, 8, 8] So, my relazation is: -------------------------------------------------------------------------------------------------- int inex[64] = {0, 0, 1, 1, 2, 2, 3, 3, 4, 4, 5, 5
........，31，31}；// to be compatibled of all the VLEN(128
~ 1024)
vfloat32m2_t data = vundefined_f32m2();
vfloat32m1_t zero =
( vfloat32m1_t )vmv_v_i_i32m1(0); while(length >0) { int gvl = vsetvl_e32m1(length); vuint32m2_t v_index = vle32_v_u32m2(index,
gvl);
vfloat32m1_t src_data = vle32_v_f32m1(src,
gvl); data = vset_f32m2(data, src_data, 0);
data = vset_f32m2(data, zero, 1); vfloat32m2_t res =
vrrgather_vv_f32m2(data, v_index, gvl); length -=gvl;
src += gvl;
vse32_v_f32m2(out, res, gvl); dst +=gvl;
} -----------------------------------------------------------------------------------------------
As shown before, the index data should be
initialized as the max VLEN to make the code compatibled. So do all the
applications, that need a constant. I think it is
contrary to the idea of RISC-V, that one code can run
on all the RISC-V hardware. Does anyone have a better
method ?
------------------原始邮件
------------------
发送时间:06/09/21 14:46:30
主题:[RISC-V] [tech-vector-ext] RISC-V Vector Spec
version 1.0-rc1-20210608
I've just tagged the first release candidate for v1.0 of the vector
spec in github. PDF attached below.
I've included the TG agreed updates and handled almost all of the
outstanding issues for v1.0. Thanks for all the feedback.
I would appreciate if folks could read through the whole thing and
give comments over email and through Github issues. Please also
submit PRs for typos and other wording improvements.
I'd like to try and settle most concerns over email if possible, and
assume it'll take a little while for everyone to go through the doc.
I'll tentatively schedule a vector TG meeting on Friday June 25 to go
over issues best dealt with on a call. I'm hoping we can enter public
review at the same point in time. Remember, we don't have to reach
agreement on all the issues before starting public review, just be OK
as a group with putting this out for public review.
Krste
-- Roger Ferrer Ibáñez - roger.ferrer@...Barcelona Supercomputing Center - Centro Nacional de Supercomputación
WARNING / LEGAL TEXT: This message is intended only for the use
of theindividual or entity to which it is addressed and may
containinformation which is privileged, confidential,
proprietary, or exemptfrom disclosure under applicable law. If
you are not the intendedrecipient or the person responsible for
delivering the message to theintended recipient, you are
strictly prohibited from disclosing,distributing, copying, or in
any way using this message. If you havereceived this
communication in error, please notify the sender anddestroy and
delete any copies you may have received.
http://www.bsc.es/disclaimer
--
Roger Ferrer Ibáñez - roger.ferrer@...
Barcelona Supercomputing Center - Centro Nacional de Supercomputación
|
