Message ID | 20240719154623.3546-1-remi@remlab.net |
---|---|
State | New |
Headers | show |
Series | [FFmpeg-devel] lavu/riscv: do not fallback to AT_HWCAP auxillary vector | expand |
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); >
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".
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);