Le sunnuntaina 4. syyskuuta 2022, 0.38.32 EEST Lynne a écrit : > I need to know the length in C, not assembly.
There may be some corner cases where that makes sense, but typically it doesn't. Even if you're dealing in fixed-size macro blocks, you should leverage the larger vectors to unroll and process multiple macro blocks in parallel. And besides, how do you want to get the value if not with assembler? This is currently not found in ELF HWCAP and probably never will be. So the only way to find out in pure C is in the embedded case, by checking out the __riscv_zlvXXXb preprocessor predefined constants. But that only tells what is the guaranteed minimum vector size for the compile-time target. Outside of embedded world, that's currently always undefined because everybody uses RVA20 as the baseline, which does not require vector support. Going forward, RVA22 will require 128 bits, but that says nothing of what the run- time CPU can actually do. > I think it makes sense to support all code that's targetting RISC-V, not just the ones it's convenient to. I disagree. There are currently no means to negotiate a vector length with the OS, so that seems highly premature. And even if there was such a mechanism, it's simply much faster to call VSETVL in an inline assembler macro where needed than to compute the whole set of CPU flags. -- レミ・デニ-クールモン http://www.remlab.net/ _______________________________________________ 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".