[FFmpeg-devel] [PATCH 0/5] RISC-V: Improve H264 decoding performance using RVV intrinsic

[Lynne]

May 10, 2023, 10:47 by arnie.chang at sifive.com:

> Hi Lynne
>
> I fully respect the policy and understand the disadvantages of intrinsic
> code.
> Considering the benefits of the open ISA like RISC-V,
> the intrinsic code should still have a better chance of being optimized by
> the compiler for hardware variants.
>

ISA being open or not is irrelevant. Power9 is open and yet compilers
still fail at having consistent performance rather than thrashing vectors
to stack.
Optimizing assembly code for new ISA features is simple with the
much more advanced templating system present in assemblers.
Plus, we can confirm that it's a net gain rather than a compiler artifact.

As advanced compilers are, we cannot even trust them to compile
C code correctly. GCC still has issues and miscompiles/misvectorizes
our code, so we have to disable tree vectorization. Not that it's a big
issue, performance-sensitive code is all assembly for us.


> At this moment, the intrinsic implementation is the only thing available.
> It would take a significant amount of time to rewrite it in assembly due to
> the large amount of functions.
>

It's precisely because there isn't a lot of code written that this ought to
be done now. Rewriting intrinsics or inline assembly is a hard process
after being merged, and all sorts of bugs and weird behavior appears
when rewriting to assembly.
You could start by just disassembling the compiled version and cleaning
it up. We've had to do this in the past.


> I was wondering if we could treat the intrinsic code as an initial version
> for the RISC-V port with the following modification.
>  - Add an option --enable-rvv-intrinsic to EXPLICITLY enable the
> intrinsic optimization, which is disabled by default.
>  Based on the given conditions, vector supports in GCC and intrinsics
> dislike and limits. Disabling it by default seems a reasonable way.
>
> For those who want to be involved in the optimization of H.264 decoder on
> RISC-V can work on the assembly and decide whether to refer to intrinsic
> code.
> I believe this would be a good starting point for future optimization.
>

Well, sort of, no. No CPU has support for RVV 1.0 at the moment.
There's no reason to hurry with this at all and merge less than desirable
code, disabled by default, which hasn't even been tested on actual hardware.

There's hardly real hardware on the horizon either. The P670 was
allegedly released last year, but even you had to test your code on an FPGA.
Even then, the P670 only has 128bit ALUs, which is suboptimal as
variable vector code tends to be more latency-bound.
The XuanTie C908 is a better candidate that I heard is getting released
sooner, and it has 256bit ALUs.

I've been wanting to write RVV code for years now, but the hardware
simply hasn't been there yet.