From: daichengrong <daichengrong@iscas.ac.cn> To: "FFmpeg development discussions and patches" <ffmpeg-devel@ffmpeg.org>, "Rémi Denis-Courmont" <remi@remlab.net> Subject: Re: [FFmpeg-devel] [PATCH] RISC-V:update ff_get_cpu_flags_riscv for RVV Date: Fri, 21 Mar 2025 10:12:14 +0800 Message-ID: <a7b912b6-14e1-437f-b7b1-df0530a2a9b9@iscas.ac.cn> (raw) In-Reply-To: <3736ED65-BD16-406B-996E-8C0E77668C8C@remlab.net> 在 2025/3/20 19:17:21, Rémi Denis-Courmont : > Hi, > > Le 20 mars 2025 11:27:39 GMT+02:00, daichengrong <daichengrong@iscas.ac.cn> a écrit : >>>> Availability of RVV and ZVBB should be determined with dl_hwcap. >>> No. That's completely superfluous since we already check for kernel support with hwprobe(). >> No. If the operating system does not enable dl_hwcap support for rvv, an illegal instruction exception will be reported , even if the hardware and kernel support RVV. > And so what? When running tests/checkasm, if the operating system has RVV support disabled, the program reports illegal instructions and the test crashes. Linux localhost.localdomain 6.13.0 #1 SMP Tue Mar 4 09:23:35 CST 2025 riscv64 riscv64 riscv64 GNU/Linux [root@localhost checkasm]# echo 0 > /proc/sys/abi/riscv_v_default_allow [root@localhost checkasm]# ./checkasm Illegal instruction [root@localhost checkasm]# echo 1 > /proc/sys/abi/riscv_v_default_allow [root@localhost checkasm]# ./checkasm checkasm: 128-bit vectors, using random seed 1986684884 RVI: - pixblockdsp.get_pixels [OK] - vc1dsp.mspel_pixels [OK] misaligned: - pixblockdsp.get_pixels [OK] - vp8dsp.mc [OK] - vp9dsp.mc [OK] RV_zbb: - ac3dsp.ac3_exponent_min [OK] - ac3dsp.ac3_extract_exponents [OK] - bswapdsp.bswap [OK] - sw_rgb.shuffle_bytes_3210 [OK] RV_zve32x: - aacpsdsp.hybrid_analysis_ileave [OK] - ac3dsp.ac3_exponent_min [OK] …… >>> And we can't check for Zb* and Zv* with hwcap anyhow. >>> >>>> As those extensions rely on vector registers, kernel vector support >>>> is required to save the state of context switching. >>> No. Kernel context switching is already ascertained. >> No. The kernel will not save and restore vector registers if the program does not use vector instructions. > That optimisation is a kernel implementation detail that is completely irrelevant to the subject matter. > > I still completely fail to see any justification for this patch. Maybe it would be better to switch the order of __riscv_hwprobe and ff_getauxval, but not sure if it conflicts with commit 0e32192548cd38a206ef3ed3c0ad8edc337a1e5f. --- libavutil/riscv/cpu.c | 30 +++++++++++++++--------------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/libavutil/riscv/cpu.c b/libavutil/riscv/cpu.c index 163e4fc14a..96cf364a08 100644 --- a/libavutil/riscv/cpu.c +++ b/libavutil/riscv/cpu.c @@ -48,7 +48,21 @@ static int __riscv_hwprobe(struct riscv_hwprobe *pairs, size_t pair_count, int ff_get_cpu_flags_riscv(void) { int ret = 0; -#if HAVE_SYS_HWPROBE_H || HAVE_ASM_HWPROBE_H +#if HAVE_GETAUXVAL || HAVE_ELF_AUX_INFO + { + const unsigned long hwcap = ff_getauxval(AT_HWCAP); + + if (hwcap & HWCAP_RV('I')) + ret |= AV_CPU_FLAG_RVI; + if (hwcap & HWCAP_RV('B')) + ret |= AV_CPU_FLAG_RVB_BASIC | AV_CPU_FLAG_RVB; + + /* The V extension implies all Zve* functional subsets */ + if (hwcap & HWCAP_RV('V')) + ret |= AV_CPU_FLAG_RVV_I32 | AV_CPU_FLAG_RVV_I64 + | AV_CPU_FLAG_RVV_F32 | AV_CPU_FLAG_RVV_F64; + } +#elif HAVE_SYS_HWPROBE_H || HAVE_ASM_HWPROBE_H struct riscv_hwprobe pairs[] = { { RISCV_HWPROBE_KEY_BASE_BEHAVIOR, 0 }, { RISCV_HWPROBE_KEY_IMA_EXT_0, 0 }, @@ -84,20 +98,6 @@ int ff_get_cpu_flags_riscv(void) default: } } -#elif HAVE_GETAUXVAL || HAVE_ELF_AUX_INFO - { - const unsigned long hwcap = ff_getauxval(AT_HWCAP); - - if (hwcap & HWCAP_RV('I')) - ret |= AV_CPU_FLAG_RVI; - if (hwcap & HWCAP_RV('B')) - ret |= AV_CPU_FLAG_RVB_BASIC | AV_CPU_FLAG_RVB; - - /* The V extension implies all Zve* functional subsets */ - if (hwcap & HWCAP_RV('V')) - ret |= AV_CPU_FLAG_RVV_I32 | AV_CPU_FLAG_RVV_I64 - | AV_CPU_FLAG_RVV_F32 | AV_CPU_FLAG_RVV_F64; - } #endif #ifdef __riscv_i -- 2.43.0 _______________________________________________ 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:[~2025-03-21 2:12 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2025-03-14 10:32 daichengrong 2025-03-15 4:03 ` Rémi Denis-Courmont 2025-03-20 9:27 ` daichengrong 2025-03-20 11:17 ` Rémi Denis-Courmont 2025-03-21 2:12 ` daichengrong [this message] 2025-03-21 4:11 ` 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=a7b912b6-14e1-437f-b7b1-df0530a2a9b9@iscas.ac.cn \ --to=daichengrong@iscas.ac.cn \ --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