From: Khem Raj <raj.khem@gmail.com> To: "Rémi Denis-Courmont" <remi@remlab.net> Cc: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> Subject: Re: [FFmpeg-devel] [PATCH] libswscale/riscv: Fix syntax of vsetvli Date: Mon, 3 Jul 2023 08:52:13 -0700 Message-ID: <CAMKF1sqNPTmpMT3Dk64sq4hUOs9b1Tbx3i8QbNwF9LocQ7uXUw@mail.gmail.com> (raw) In-Reply-To: <CBF7C7FC-2AAC-4595-8EAD-7FA30FF3C23E@remlab.net> On Mon, Jul 3, 2023 at 1:00 AM Rémi Denis-Courmont <remi@remlab.net> wrote: > > Hi, > > The diff is ok. I even have a slight incline in favour thereof for the sake of consistency. Yet, I may be vainly pedantic but I do have problems with the description. > > Le 3 juillet 2023 05:44:12 GMT+03:00, Khem Raj <raj.khem@gmail.com> a écrit : > >Add missing operand > > The spec does explicitly make the mask and tail policy mandatory, but I can't see any such requirements for the group multiplier. To the contrary, there are several examples in the spec _without_ explicit multiplier. > > In reality, `vsetvli` (and `vsetivli`) merely transfers an immediate value to the vector configuration register. Missing fields are to be left at zero for forward compatibility, and `m1` happens to encode as 0b000. > I just replicated what GAS is doing here implicitly. > > Which clang complains about but gcc assumes it to be > >'m1' if not specifiied. > > The technical term for the RISC-V support in LLVM AS version 15 and earlier is "useless junk". If you want to compile FFmpeg on RISC-V with Clang, you *must* disable the integrated AS and use binutils GNU/as instead. > > The Linux RISC-V kernel altogether gave up on LLVM entirely, requiring GCC for RVV, so they're even stricter (and without kernel support, FFmpeg support is obviously useless). > > *Hopefully* LLVM gets their act together by release 16, and ship a usable assembler, rather than tell us to use automatic RVV vectorisation (which *is* a release 16 feature, though it was half-baked last time I tried). > I am on clang/llvm trunk ( future 17.0 release ), I will also open an issue with llvm on github regarding this. > > > >Fixes building with clang > > More like bug-compatible work-around than fix, AFAIU. I can do it although I did not find a relevant section in spec about these being optional, I did see examples omitting them though. > > >| src/libswscale/riscv/rgb2rgb_rvv.S:88:25: error: operand must be e[8|16|32|64|128|256|512|1024],m[1|2|4|8|f2|f4|f8],[ta|tu],[ma|mu] > > Do you have a reference to the Github RVV spec to validate this, that I overlooked, or it's just misled and misleading spew from LLVM? Perhaps the latter but I also did not see reference to the former. Here is a small example a.S #.option arch, +zve32x # OK #vsetvli t4, t3, e8, m1, ta, ma # BAD vsetvli t4, t3, e8, ta, ma clang -target riscv64 -march=rv64izve32x1p0 a.S -c > > >| vsetvli t4, t3, e8, ta, ma > >| ^ > > > >Signed-off-by: Khem Raj <raj.khem@gmail.com> > >--- > > libswscale/riscv/rgb2rgb_rvv.S | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > >diff --git a/libswscale/riscv/rgb2rgb_rvv.S b/libswscale/riscv/rgb2rgb_rvv.S > >index 5626d906eb..bbdfdbebbc 100644 > >--- a/libswscale/riscv/rgb2rgb_rvv.S > >+++ b/libswscale/riscv/rgb2rgb_rvv.S > >@@ -85,7 +85,7 @@ func ff_interleave_bytes_rvv, zve32x > > mv t3, a3 > > addi a4, a4, -1 > > 2: > >- vsetvli t4, t3, e8, ta, ma > >+ vsetvli t4, t3, e8, m1, ta, ma > > sub t3, t3, t4 > > vle8.v v8, (t0) > > add t0, t4, t0 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
next prev parent reply other threads:[~2023-07-03 15:52 UTC|newest] Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-07-03 2:44 Khem Raj 2023-07-03 8:00 ` Rémi Denis-Courmont 2023-07-03 15:52 ` Khem Raj [this message] 2023-07-03 20:08 ` Rémi Denis-Courmont
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAMKF1sqNPTmpMT3Dk64sq4hUOs9b1Tbx3i8QbNwF9LocQ7uXUw@mail.gmail.com \ --to=raj.khem@gmail.com \ --cc=ffmpeg-devel@ffmpeg.org \ --cc=remi@remlab.net \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel This inbox may be cloned and mirrored by anyone: git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \ ffmpegdev@gitmailbox.com public-inbox-index ffmpegdev Example config snippet for mirrors. AGPL code for this site: git clone https://public-inbox.org/public-inbox.git