May 10, 2023, 10:47 by arnie.ch...@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. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
