Date: Mon, 5 Feb 2024 18:29:50 -0600 From: "B. E." <estrabd@gmail.com> To: sgk@troutmask.apl.washington.edu Cc: Jan Beich <jbeich@freebsd.org>, Alexander Leidinger <Alexander@leidinger.net>, freebsd-hackers@freebsd.org Subject: Re: GPU programming? Message-ID: <CALSf6fTyg8oDtjBBOGFHFC=1GWFiwW-Q2J%2BwVdddPJHe%2B_CC2g@mail.gmail.com> In-Reply-To: <ZcEWSwgssZ7grGpF@troutmask.apl.washington.edu> References: <Zb_fTkeKTYSxpfKc@troutmask.apl.washington.edu> <CALSf6fRJA861r7XF=fOWOdfc7-AzGePa6r5P=bBA9-x-36LB4Q@mail.gmail.com> <Zb_4z5IKLl5yuXTJ@troutmask.apl.washington.edu> <90ea0dd91b760b0b6f92065d09396545@Leidinger.net> <sf27-qhwa-wny@FreeBSD.org> <ZcEWSwgssZ7grGpF@troutmask.apl.washington.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
--00000000000057ff800610abafce Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Not surprising since most academic HPCs and HPC-enabled clouds (Oracle, Azure) are generally running some version of RHEL. The former is where the largest GPU resources are available to most folks (e.g., TACC), as I am sure you already know. OTOH, someone doing with FreeBSD is likely just wanting it for a workstation or some single node, many-core server they picked up cheap off of eBay or an e-cycler; (basically me, but I focus on OpenMP and standard CPU SMP). If you're doing AI related things, then a lot of sites are starting to spring up that sell GPU heavy single box builds, but those are also assuming some kind of Linux. Brett On Mon, Feb 5, 2024 at 11:10=E2=80=AFAM Steve Kargl < sgk@troutmask.apl.washington.edu> wrote: > On Mon, Feb 05, 2024 at 12:17:57PM +0100, Jan Beich wrote: > > Alexander Leidinger <Alexander@Leidinger.net> writes: > > > > > ROCm: No idea. I have not seen any report about it working or even > > > being tried. But there was at least some discussion about it: > > > https://github.com/ROCm/ROCm/issues/138 > > > https://github.com/ROCm/ROCm/issues/1913 > > > > AFAIU (never owned an AMD GPU): > > - ROCm requires amdkfd.ko which drm-kmod doesn't provide since > > https://github.com/freebsd/drm-kmod/commit/a381f46adf8b > > - ROCm has poor *consumer* GPU support thus unattractive for > > volunteers/community to spend time porting > > > > > Intel: Maybe. We have spirv ports in the tree, and my limited > > > understanding is, that SPIR-V comes into play when someone wants to d= o > > > GPU compute there. CCing Jan as the port maintainer for the two spirv > > > ports. Maybe he can shed some light on this part. > > > > - Vulkan Compute works fine on every modern GPU (used at least by ncnn) > > - OpenCL works fine on Intel + AMD via Rusticl (Mesa), see > > https://cgit.freebsd.org/ports/commit/?id=3Dd8990eff958b > > - OpenCL + oneAPI Level Zero via lang/intel-compute-runtime requires > userptr, see > > https://github.com/FreeBSDDesktop/kms-drm/issues/197 > > > > As a volunteer I've burned out porting Intel stuff, so hopefully Rustic= l > > kills Intel NEO (intel-compute-runtime) while Vulkan Video kills VA-API > > (libva-intel-media-driver) and QuickSyncVideo (intel-media-sdk + onevpl= ) > > > > Related https://www.phoronix.com/news/David-Airlie-oneAPI-Meetup > > Alexander, Jan, > > Thanks for the info. I'll check out the various links. > This somewhat confirms my suspicion that little is being > done with scientific numerical GPU computing in the FreeBSD. > > -- > Steve > > --00000000000057ff800610abafce Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Not surprising since most academic HPCs and HPC-enabled cl= ouds (Oracle, Azure) are generally running some version of RHEL. The former= is where the largest GPU resources are available to most folks (e.g., TACC= ), as I am sure you already know. OTOH, someone doing with FreeBSD is likel= y just wanting it for a workstation or some single node, many-core server t= hey picked up cheap off of eBay or an e-cycler; (basically me, but I focus = on OpenMP and standard CPU SMP). If you're doing AI related things, the= n a lot of sites are starting to spring up that sell GPU heavy single box b= uilds, but those are also assuming some kind of Linux.<div><br></div><div>B= rett</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gm= ail_attr">On Mon, Feb 5, 2024 at 11:10=E2=80=AFAM Steve Kargl <<a href= =3D"mailto:sgk@troutmask.apl.washington.edu" target=3D"_blank">sgk@troutmas= k.apl.washington.edu</a>> wrote:<br></div><blockquote class=3D"gmail_quo= te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204= );padding-left:1ex">On Mon, Feb 05, 2024 at 12:17:57PM +0100, Jan Beich wro= te:<br> > Alexander Leidinger <Alexander@Leidinger.net> writes:<br> > <br> > > ROCm: No idea. I have not seen any report about it working or eve= n<br> > > being tried. But there was at least some discussion about it:<br> > >=C2=A0 =C2=A0 =C2=A0<a href=3D"https://github.com/ROCm/ROCm/issues= /138" rel=3D"noreferrer" target=3D"_blank">https://github.com/ROCm/ROCm/iss= ues/138</a><br> > >=C2=A0 =C2=A0 =C2=A0<a href=3D"https://github.com/ROCm/ROCm/issues= /1913" rel=3D"noreferrer" target=3D"_blank">https://github.com/ROCm/ROCm/is= sues/1913</a><br> > <br> > AFAIU (never owned an AMD GPU):<br> > - ROCm requires amdkfd.ko which drm-kmod doesn't provide since<br> >=C2=A0 =C2=A0<a href=3D"https://github.com/freebsd/drm-kmod/commit/a381= f46adf8b" rel=3D"noreferrer" target=3D"_blank">https://github.com/freebsd/d= rm-kmod/commit/a381f46adf8b</a><br> > - ROCm has poor *consumer* GPU support thus unattractive for<br> >=C2=A0 =C2=A0volunteers/community to spend time porting<br> > <br> > > Intel: Maybe. We have spirv ports in the tree, and my limited<br> > > understanding is, that SPIR-V comes into play when someone wants = to do<br> > > GPU compute there. CCing Jan as the port maintainer for the two s= pirv<br> > > ports. Maybe he can shed some light on this part.<br> > <br> > - Vulkan Compute works fine on every modern GPU (used at least by ncnn= )<br> > - OpenCL works fine on Intel + AMD via Rusticl (Mesa), see<br> >=C2=A0 =C2=A0<a href=3D"https://cgit.freebsd.org/ports/commit/?id=3Dd89= 90eff958b" rel=3D"noreferrer" target=3D"_blank">https://cgit.freebsd.org/po= rts/commit/?id=3Dd8990eff958b</a><br> > - OpenCL + oneAPI Level Zero via lang/intel-compute-runtime requires u= serptr, see<br> >=C2=A0 =C2=A0<a href=3D"https://github.com/FreeBSDDesktop/kms-drm/issue= s/197" rel=3D"noreferrer" target=3D"_blank">https://github.com/FreeBSDDeskt= op/kms-drm/issues/197</a><br> > <br> > As a volunteer I've burned out porting Intel stuff, so hopefully R= usticl<br> > kills Intel NEO (intel-compute-runtime) while Vulkan Video kills VA-AP= I<br> > (libva-intel-media-driver) and QuickSyncVideo (intel-media-sdk + onevp= l)<br> > <br> > Related <a href=3D"https://www.phoronix.com/news/David-Airlie-oneAPI-M= eetup" rel=3D"noreferrer" target=3D"_blank">https://www.phoronix.com/news/D= avid-Airlie-oneAPI-Meetup</a><br> <br> Alexander, Jan,<br> <br> Thanks for the info.=C2=A0 I'll check out the various links.<br> This somewhat confirms my suspicion that little is being<br> done with scientific numerical GPU computing in the FreeBSD.<br> <br> -- <br> Steve<br> <br> </blockquote></div> --00000000000057ff800610abafce--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CALSf6fTyg8oDtjBBOGFHFC=1GWFiwW-Q2J%2BwVdddPJHe%2B_CC2g>