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&#39;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&#39;s an up-a=
nd-coming platform so it&#39;s fairly likely that we&#39;ll consider it in =
the future I&#39;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&#39;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==--