From: Richard Biener <richard.guenther@gmail.com>
To: Benson Muite <benson_muite@emailplus.org>
Cc: sgk@troutmask.apl.washington.edu, fortran@gcc.gnu.org
Subject: Re: GPU offloading question
Date: Sat, 3 Feb 2024 20:38:02 +0100 [thread overview]
Message-ID: <87E7C31E-C475-49AB-BAB5-D33CC86A5F21@gmail.com> (raw)
In-Reply-To: <cc56324b-77ee-1eb8-87a6-222c9f786674@emailplus.org>
> Am 03.02.2024 um 19:15 schrieb Benson Muite <benson_muite@emailplus.org>:
>
> On 03/02/2024 19.13, Steve Kargl wrote:
>>> On Sat, Feb 03, 2024 at 02:37:05PM +0100, Richard Biener wrote:
>>>
>>>> Am 03.02.2024 um 01:22 schrieb Steve Kargl <sgk@troutmask.apl.washington.edu>:
>>>>
>>>> All,
>>>>
>>>> Suppose one is working in a funding-constrained environment
>>>> such as an academician with limited grant funding. If one
>>>> wanted to dabble in GPU offloading with gcc/gfortran, what
>>>> recommendations would one have for minimum required hardware?
>>>> In addition, are there any vendor software layers that are
>>>> required (such as AMD ROCm with an AMD GPU)?
>>>
>>> You need the HSA runtime for AMD which comes with ROCm and libcuda
>>> for NvIDIA which comes with CUDA.
>>
>> Thanks. I'll need to check the level of support for the above
>> in FreeBSD. I suspect it's non-existent, so looks like I'll take
>> a plunge down the linux rabbit hole
Support is likely non existent on FreeBSD since there’s a driver component as well. For modern GPUs the driver is open source in Linux for both vendors but the firmware is not. CUDA is proprietary while the HSA runtime part is easily built from source (it’s hosted on GitHub)
>>> I’ve had success getting both a very low end gtx1650 and a high
>>> end rx6900xt running with simple offloading. The officially supported
>>> set of hardware is way bigger with CUDA when it comes to lower end cards.
>>>
>>> I can’t say anything about performance with regard to how GCC handles both.
>>>
>>> Note that double precision math performance is said to be severely
>>> constrained for consumer hardware.
>>
>> Ah, good point. I'll need to find a card I can afford that supports
>> double precision.
>>
>>
> Consider https://allocations.access-ci.org/resources
> for a PI based in the USA. Use the limited funding to support your time
> improving off loading support for GFortran.
Yeah, I would also suggest development resources available as part of SC center access here.
Richard
prev parent reply other threads:[~2024-02-03 19:38 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-03 0:21 Steve Kargl
2024-02-03 13:37 ` Richard Biener
2024-02-03 16:13 ` Steve Kargl
2024-02-03 18:15 ` Benson Muite
2024-02-03 18:37 ` Steve Kargl
2024-02-03 19:38 ` Richard Biener [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87E7C31E-C475-49AB-BAB5-D33CC86A5F21@gmail.com \
--to=richard.guenther@gmail.com \
--cc=benson_muite@emailplus.org \
--cc=fortran@gcc.gnu.org \
--cc=sgk@troutmask.apl.washington.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).