[FFmpeg-devel] [PATCH] lavu/riscv: do not fallback to AT_HWCAP auxillary vector

[FFmpeg-devel] [PATCH] lavu/riscv: do not fallback to AT_HWCAP auxillary vector

[Rémi Denis-Courmont]

If __riscv_hwprobe() fails, then the kernel version is presumably too
old. There is not much point falling back to the auxillary vector.

- The Linux kernel requires I, so the flag is always set on Linux, and
  run-time detection is unnecessary. Our RISC-V assembler does anyway not
  support targets without I.

- Linux can compile with or without F and D, but it cannot perform
  run-time detection for them (a kernel with F support will not boot a
  processor without F). The run-time detection is thus useless in that
  case. Besides F and D extensions are used throughout the C code, so
  their run-time detection would not be practical.

- Support for V was added in a later kernel version than riscv_hwprobe(),
  so the system call will always be available if the kernel supports V.
  The only exception would be vendor kernel forks, but those are known to
  haphasardly pretend to support V on systems without actual V support, or
  with only pre-ratification binary-incompatible version. Furthermore, a
  large chunk of our optimisations require Zba and/or Zbb which cannot be
  detected with HWCAP in those kernels.

For what it is worth, OpenJDK already took a similar action. Note that this
keeps AT_HWCAP usage for platforms with neither C run-time <sys/hwprobe.h>
nor kernel <asm/hwprobe.h>, notably kernels other than Linux.
---
 libavutil/riscv/cpu.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/libavutil/riscv/cpu.c b/libavutil/riscv/cpu.c
index 73abd289a6..04ac404bbf 100644
--- a/libavutil/riscv/cpu.c
+++ b/libavutil/riscv/cpu.c
@@ -83,9 +83,8 @@ int ff_get_cpu_flags_riscv(void)
                 break;
             default:
         }
-    } else
-#endif
-#if HAVE_GETAUXVAL
+    }
+#elif HAVE_GETAUXVAL
     {
         const unsigned long hwcap = getauxval(AT_HWCAP);
 
-- 
2.45.2

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

Re: [FFmpeg-devel] [PATCH] lavu/riscv: do not fallback to AT_HWCAP auxillary vector

[Brad Smith]

On 2024-07-19 11:46 a.m., Rémi Denis-Courmont wrote:
> If __riscv_hwprobe() fails, then the kernel version is presumably too
> old. There is not much point falling back to the auxillary vector.
>
> - The Linux kernel requires I, so the flag is always set on Linux, and
>    run-time detection is unnecessary. Our RISC-V assembler does anyway not
>    support targets without I.
>
> - Linux can compile with or without F and D, but it cannot perform
>    run-time detection for them (a kernel with F support will not boot a
>    processor without F). The run-time detection is thus useless in that
>    case. Besides F and D extensions are used throughout the C code, so
>    their run-time detection would not be practical.
>
> - Support for V was added in a later kernel version than riscv_hwprobe(),
>    so the system call will always be available if the kernel supports V.
>    The only exception would be vendor kernel forks, but those are known to
>    haphasardly pretend to support V on systems without actual V support, or
>    with only pre-ratification binary-incompatible version. Furthermore, a
>    large chunk of our optimisations require Zba and/or Zbb which cannot be
>    detected with HWCAP in those kernels.
>
> For what it is worth, OpenJDK already took a similar action. Note that this
> keeps AT_HWCAP usage for platforms with neither C run-time <sys/hwprobe.h>
> nor kernel <asm/hwprobe.h>, notably kernels other than Linux.

Thanks for the last part. The bits for OpenBSD have just landed for 
supporting
elf_aux_info() so I'll look at adding support for FreeBSD and OpenBSD.

> ---
>   libavutil/riscv/cpu.c | 5 ++---
>   1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/libavutil/riscv/cpu.c b/libavutil/riscv/cpu.c
> index 73abd289a6..04ac404bbf 100644
> --- a/libavutil/riscv/cpu.c
> +++ b/libavutil/riscv/cpu.c
> @@ -83,9 +83,8 @@ int ff_get_cpu_flags_riscv(void)
>                   break;
>               default:
>           }
> -    } else
> -#endif
> -#if HAVE_GETAUXVAL
> +    }
> +#elif HAVE_GETAUXVAL
>       {
>           const unsigned long hwcap = getauxval(AT_HWCAP);
>   
_______________________________________________
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".

Re: [FFmpeg-devel] [PATCH] lavu/riscv: do not fallback to AT_HWCAP auxillary vector

[Rémi Denis-Courmont]

Le 20 juillet 2024 00:28:23 GMT+03:00, Brad Smith <brad-at-comstyle.com@ffmpeg.org> a écrit :
>On 2024-07-19 11:46 a.m., Rémi Denis-Courmont wrote:
>> If __riscv_hwprobe() fails, then the kernel version is presumably too
>> old. There is not much point falling back to the auxillary vector.
>> 
>> - The Linux kernel requires I, so the flag is always set on Linux, and
>>    run-time detection is unnecessary. Our RISC-V assembler does anyway not
>>    support targets without I.
>> 
>> - Linux can compile with or without F and D, but it cannot perform
>>    run-time detection for them (a kernel with F support will not boot a
>>    processor without F). The run-time detection is thus useless in that
>>    case. Besides F and D extensions are used throughout the C code, so
>>    their run-time detection would not be practical.
>> 
>> - Support for V was added in a later kernel version than riscv_hwprobe(),
>>    so the system call will always be available if the kernel supports V.
>>    The only exception would be vendor kernel forks, but those are known to
>>    haphasardly pretend to support V on systems without actual V support, or
>>    with only pre-ratification binary-incompatible version. Furthermore, a
>>    large chunk of our optimisations require Zba and/or Zbb which cannot be
>>    detected with HWCAP in those kernels.
>> 
>> For what it is worth, OpenJDK already took a similar action. Note that this
>> keeps AT_HWCAP usage for platforms with neither C run-time <sys/hwprobe.h>
>> nor kernel <asm/hwprobe.h>, notably kernels other than Linux.
>
>Thanks for the last part. The bits for OpenBSD have just landed for supporting
>elf_aux_info() so I'll look at adding support for FreeBSD and OpenBSD.

Well if they're using the `misa` CSR layout for HWCAP as Linux did, then there should be nothing to do, except maybe for compile fixes.

But if they use a custom bit-field layout then you probably need to rewrite the code.

>
>> ---
>>   libavutil/riscv/cpu.c | 5 ++---
>>   1 file changed, 2 insertions(+), 3 deletions(-)
>> 
>> diff --git a/libavutil/riscv/cpu.c b/libavutil/riscv/cpu.c
>> index 73abd289a6..04ac404bbf 100644
>> --- a/libavutil/riscv/cpu.c
>> +++ b/libavutil/riscv/cpu.c
>> @@ -83,9 +83,8 @@ int ff_get_cpu_flags_riscv(void)
>>                   break;
>>               default:
>>           }
>> -    } else
>> -#endif
>> -#if HAVE_GETAUXVAL
>> +    }
>> +#elif HAVE_GETAUXVAL
>>       {
>>           const unsigned long hwcap = getauxval(AT_HWCAP);
>>   
>_______________________________________________
>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".