Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
* [FFmpeg-devel] [PATCH] RISC-V:update ff_get_cpu_flags_riscv for RVV
@ 2025-03-14 10:32 daichengrong
  2025-03-15  4:03 ` Rémi Denis-Courmont
  0 siblings, 1 reply; 6+ messages in thread
From: daichengrong @ 2025-03-14 10:32 UTC (permalink / raw)
  To: ffmpeg-devel

From: daichengrong <daichengrong@iscas.ac.cn>

Availability of RVV and ZVBB should be determined with dl_hwcap.

As those extensions rely on vector registers, kernel vector support 
is required to save the state of context switching.

FFmpeg requires hwprobe for hardware capability detection, and cooperates 
with dl_hwcap to detect whether the kernel supports vector.

---
 libavutil/riscv/cpu.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/libavutil/riscv/cpu.c b/libavutil/riscv/cpu.c
index 163e4fc14a..fad63eccea 100644
--- a/libavutil/riscv/cpu.c
+++ b/libavutil/riscv/cpu.c
@@ -55,6 +55,10 @@ int ff_get_cpu_flags_riscv(void)
         { RISCV_HWPROBE_KEY_CPUPERF_0, 0 },
     };
 
+#if HAVE_GETAUXVAL || HAVE_ELF_AUX_INFO
+    const unsigned long hwcap = ff_getauxval(AT_HWCAP);
+#endif
+
     if (__riscv_hwprobe(pairs, FF_ARRAY_ELEMS(pairs), 0, NULL, 0) == 0) {
         if (pairs[0].value & RISCV_HWPROBE_BASE_BEHAVIOR_IMA)
             ret |= AV_CPU_FLAG_RVI;
@@ -62,6 +66,12 @@ int ff_get_cpu_flags_riscv(void)
         if (pairs[1].value & RISCV_HWPROBE_IMA_V)
             ret |= AV_CPU_FLAG_RVV_I32 | AV_CPU_FLAG_RVV_I64
                  | AV_CPU_FLAG_RVV_F32 | AV_CPU_FLAG_RVV_F64;
+#if HAVE_GETAUXVAL || HAVE_ELF_AUX_INFO
+        /* 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
 #endif
 #ifdef RISCV_HWPROBE_EXT_ZBB
         if (pairs[1].value & RISCV_HWPROBE_EXT_ZBB)
@@ -76,6 +86,10 @@ int ff_get_cpu_flags_riscv(void)
 #ifdef RISCV_HWPROBE_EXT_ZVBB
         if (pairs[1].value & RISCV_HWPROBE_EXT_ZVBB)
             ret |= AV_CPU_FLAG_RV_ZVBB;
+#if HAVE_GETAUXVAL || HAVE_ELF_AUX_INFO
+        if (!(hwcap & HWCAP_RV('V')))
+            ret &= ~AV_CPU_FLAG_RV_ZVBB;
+#endif
 #endif
         switch (pairs[2].value & RISCV_HWPROBE_MISALIGNED_MASK) {
             case RISCV_HWPROBE_MISALIGNED_FAST:
-- 
2.25.1

_______________________________________________
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".

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [FFmpeg-devel] [PATCH] RISC-V:update ff_get_cpu_flags_riscv for RVV
  2025-03-14 10:32 [FFmpeg-devel] [PATCH] RISC-V:update ff_get_cpu_flags_riscv for RVV daichengrong
@ 2025-03-15  4:03 ` Rémi Denis-Courmont
  2025-03-20  9:27   ` daichengrong
  0 siblings, 1 reply; 6+ messages in thread
From: Rémi Denis-Courmont @ 2025-03-15  4:03 UTC (permalink / raw)
  To: FFmpeg development discussions and patches

Hi,

Le 14 mars 2025 17:32:57 GMT+07:00, daichengrong@iscas.ac.cn a écrit :
>From: daichengrong <daichengrong@iscas.ac.cn>
>
>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().

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. And we don't care about libc context support, since vectors are clobbered by function calls, e.g. for long jumps or ucontext.
_______________________________________________
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".

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [FFmpeg-devel] [PATCH] RISC-V:update ff_get_cpu_flags_riscv for RVV
  2025-03-15  4:03 ` Rémi Denis-Courmont
@ 2025-03-20  9:27   ` daichengrong
  2025-03-20 11:17     ` Rémi Denis-Courmont
  0 siblings, 1 reply; 6+ messages in thread
From: daichengrong @ 2025-03-20  9:27 UTC (permalink / raw)
  To: FFmpeg development discussions and patches, Rémi Denis-Courmont

hi,

The reply email was mistakenly classified as spam, resulting in not 
being seen in time.

Late reply.

在 2025/3/15 12:03:09, Rémi Denis-Courmont :
> Hi,
>
> Le 14 mars 2025 17:32:57 GMT+07:00, daichengrong@iscas.ac.cn a écrit :
>> From: daichengrong <daichengrong@iscas.ac.cn>
>>
>> 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 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.
> And we don't care about libc context support, since vectors are clobbered by function calls, e.g. for long jumps or ucontext.
I'm confused about this
> _______________________________________________
> 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".

_______________________________________________
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".

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [FFmpeg-devel] [PATCH] RISC-V:update ff_get_cpu_flags_riscv for RVV
  2025-03-20  9:27   ` daichengrong
@ 2025-03-20 11:17     ` Rémi Denis-Courmont
  2025-03-21  2:12       ` daichengrong
  0 siblings, 1 reply; 6+ messages in thread
From: Rémi Denis-Courmont @ 2025-03-20 11:17 UTC (permalink / raw)
  To: FFmpeg development discussions and patches

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?

>> 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.
_______________________________________________
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".

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [FFmpeg-devel] [PATCH] RISC-V:update ff_get_cpu_flags_riscv for RVV
  2025-03-20 11:17     ` Rémi Denis-Courmont
@ 2025-03-21  2:12       ` daichengrong
  2025-03-21  4:11         ` Rémi Denis-Courmont
  0 siblings, 1 reply; 6+ messages in thread
From: daichengrong @ 2025-03-21  2:12 UTC (permalink / raw)
  To: FFmpeg development discussions and patches, Rémi Denis-Courmont


在 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".

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [FFmpeg-devel] [PATCH] RISC-V:update ff_get_cpu_flags_riscv for RVV
  2025-03-21  2:12       ` daichengrong
@ 2025-03-21  4:11         ` Rémi Denis-Courmont
  0 siblings, 0 replies; 6+ messages in thread
From: Rémi Denis-Courmont @ 2025-03-21  4:11 UTC (permalink / raw)
  To: FFmpeg development discussions and patches

Hi,

Le 21 mars 2025 04:12:14 GMT+02:00, daichengrong <daichengrong@iscas.ac.cn> a écrit :
>
>在 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.

No, it does not. We even test this multiple times a day in FATE.

>
>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

If you use that option, you are responsible for ensuring that libc will re-enable vectors using prctl() before running any programme or library with vector code. You just shot yourself in the foot.
_______________________________________________
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".

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2025-03-21  4:11 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-03-14 10:32 [FFmpeg-devel] [PATCH] RISC-V:update ff_get_cpu_flags_riscv for RVV 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
2025-03-21  4:11         ` Rémi Denis-Courmont

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