Promoting RISC-V to a Tier 3 supported platform
Ralf Gommers via NumPy-Discussion <[email protected]> Tue, 12 May 2026 15:20:47 +0200
| Newsgroups | gmane.comp.python.numeric.general |
|---|---|
| Message-ID | <CABL7CQghmg00O03aNVG_zy7vdRTHagc-7mfggF5_n4nb-N1+Tg@mail.gmail.com> |
--===============5731384013196958861== Content-Type: multipart/alternative; boundary="000000000000da7bf806519ebb8b" --000000000000da7bf806519ebb8b Content-Type: text/plain; charset="UTF-8" Hi all, There has been sustained interest in, and responsive contributors for, RISC-V support in NumPy. There are now self-hosted runners from the RISE project (https://riseproject.dev/), which we're about to get green (I hope) on https://github.com/numpy/numpy/pull/30995. Their interest extends to adding RISC-V as a supported platform for which we ship wheels on PyPI - see https://github.com/numpy/numpy/issues/30216. It seems a little too early to consider crossing that bridge today, but it's an up-and-coming platform so it's fairly likely that we'll consider it in the future I'd think. For now, I propose we add RISC-V as a Tier 3 platform at https://numpy.org/neps/nep-0057-numpy-platform-support.html#tier-3, next to ppc64le and Pyodide. That means we have CI support and contributors who have stuck up their hand and can be pinged in case of platform-specific issues that need addressing. We also have SIMD and CPU detection code specific to RISC-V, so having native runners in CI will be quite helpful either way. And hopefully we can disable the slow QEMU-based job once we're happy with the self-hosted runners. Thoughts or concerns? Cheers, Ralf --000000000000da7bf806519ebb8b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>Hi all,</div><div><br></div><div>There has been susta= ined interest in, and responsive contributors for, RISC-V support in NumPy.= There are now self-hosted runners from the RISE project (<a href=3D"https:= //riseproject.dev/">https://riseproject.dev/</a>), which we're about to= get green (I hope) on=C2=A0<a href=3D"https://github.com/numpy/numpy/pull/= 30995">https://github.com/numpy/numpy/pull/30995</a>.</div><div><br></div><= div>Their interest extends to adding RISC-V as a supported platform for whi= ch we ship wheels on PyPI - see <a href=3D"https://github.com/numpy/numpy/i= ssues/30216">https://github.com/numpy/numpy/issues/30216</a>. It seems a li= ttle too early to consider crossing that bridge today, but it's an up-a= nd-coming platform so it's fairly likely that we'll consider it in = the future I'd think.</div><div><br></div><div>For now, I propose we ad= d RISC-V as a Tier 3 platform at=C2=A0<a href=3D"https://numpy.org/neps/nep= -0057-numpy-platform-support.html#tier-3">https://numpy.org/neps/nep-0057-n= umpy-platform-support.html#tier-3</a>, next to ppc64le and Pyodide. That me= ans we have CI support and contributors who have stuck up their hand and ca= n be pinged in case of platform-specific issues that need addressing.=C2=A0= </div><div><br></div><div>We also have SIMD and CPU detection code specific= to RISC-V, so having native runners in CI will be quite helpful either way= . And hopefully we can disable the slow QEMU-based job once we're happy= with the self-hosted runners.</div><div><br></div><div>Thoughts or concern= s?</div><div><br></div><div>Cheers,<br></div><div>Ralf</div><div><br></div>= </div> --000000000000da7bf806519ebb8b-- --===============5731384013196958861== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ NumPy-Discussion mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3//lists/numpy-discussion.python.org Member address: [email protected] --===============5731384013196958861==--