rouault
commented
1 day ago Hi, thanks for your interest. May I ask you what's your interest in GDAL and/or RISC-V ? Perhaps you're affiliated with a RISC-V founder or some group that promotes for its adoption? I ran an informal poll on my Mastodon account in https://mastodon.social/@EvenRouault/113344940167220826. So 22 people responded: 0% use RISC-V currently, 9% might and 91% will presumably never. I would be really reluctant to having RISC-V specific code paths in our code paths:
- it would be really hard for GDAL maintainers to ensure they are correct, either in the initial implementation, and more critically within the 5, 10 or 15 next years, due to the absence of access to that hardware, either locally or with continuous integration platforms as provide by GitHub workflows
- platform specfic code paths that rote could means code that no longer compiles, or falls behind bugfixes, so a much worse situation than the current one where, if C/C++ compilers for RISC-V work correctly, users at least get correct results.
- there's the issue of how to make them evolve when the base portable code path evolve, and that happens regularly like in https://github.com/OSGeo/gdal/pull/11046
I would be much more supportive of RISC-V optimizations going through the use of an abstraction software layer. I see that libjxl uses https://github.com/google/highway and that it has RISC-V support. That would also enable us to cover other platforms like NEON / ARM64.
Currently we have a few specific SSE/SSE2/AVX2 code paths using Intel intrinsics, either directly, or through a thin abstraction layer such as gcore/gdalsse_priv.h. I'm undecided if adopting highway would totally deprecate those code paths, or if we would keep them. It all depends if we can reach the same level of performance, and also how we deal with the external dependency.
The main candidates for accelerated code paths are alg/gdalwarpkernel.cpp, gcore/overview.cpp and CopyWord related code of gcore/rasterio.cpp
Feature description
First off, thanks for all the amazing work on GDAL! I wanted to ask if there are any plans to optimize GDAL for the RISC-V platform, specifically using the RISC-V Vector Extension (RVV). With RISC-V gaining popularity, having RVV optimizations could potentially bring performance benefits to GDAL on that platform.
If there’s no plan yet, would this be something you’d consider? My team and I would be interested in contributing if there’s a need for testing or development in this area.
Thanks!
Additional context
No response