Hello, On Sat, Apr 01 2023, Prasad, Adi via Gcc wrote: > Hi Tobias and Thomas, > > My apologies for the double email; I have an unrelated administrative > ask. Would it be possible to provide any past successful GSoC > proposals? I'm interested in any thnigs GCC specifically is looking > for in proposals (I've seen quite a few generic guides on the web but > none specific to GCC).
Unfortunately no, not without seeking permission of their authors first. But generally speaking, if you can demonstrate that you have the skills and ability to understand the offloading architecture, the current relevant sources (not necessarily in depth but more-or-less correctly) and that you have the C/C++ coding skills to be able to successfully change them, you are likely to be selected (depending on how many slots we get from Google, of course). One way to demonstrate it is to provide good milestones in your proposal and a timeline which will demonstrate that you already have an idea what you would be working on in the first few weeks, beyond setting things up and learning stuff. > > Thanks, > Adi > >> -----Original Message----- >> From: Prasad, Adi >> Sent: Saturday, April 1, 2023 4:16 AM >> To: 'Tobias Burnus' <tob...@codesourcery.com>; Thomas Schwinge >> <tho...@codesourcery.com> >> Cc: gcc@gcc.gnu.org >> Subject: RE: GSoC Separate Host Process Offloading >> >> Hi Tobias, >> Thanks for the reply! >> >> > >> > Note that multiple offload targets are possible. For instance, on >> > Debian/Ubuntu, 'gcc -v' shows: >> > 'OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa' and lto-wrapper >> then >> > cycles through those, finding the offloading compiler in >> > $PATH/accel/<triple>/mkoffload >> > >> > Example: x86_64-none-linux-gnu/12.2.1/accel/amdgcn-amdhsa/mkoffload >> > >> > Thus, if you install it to 'x86_64-none-linux-gnu' and add it to >> > OFFLOAD_TARGET_NAMES,* it will work; albeit, we probably want to have >> > some special handling in gcc.cc to avoid host-process offloading by >> > default and permit something like -foffload=host instead of having to >> > specify -foffload=x86_64-none-linux-gnu >> > >> Understood. Forgive me if I'm misunderstanding this, but I wonder if it >> might be >> better to put the new mkoffload in an "accel/host" directory, and add "host" >> to >> OFFLOAD_TARGET_NAMES rather than have the specific host e.g. "x86_64-none- >> linux-gnu"? This would 1) enable the use of "-foffload=host" automatically >> and 2) >> distinguish between compiling for the same device on a separate process >> versus >> compiling to a separate device with the same architecture and kernel as the >> host. >> I can imagine this clash wouldn’t happen in practice, since compiling for a >> separate host process would target CPUs while compiling for a separate device >> would target GPUs, but it might be nicer to keep them conceptually separate >> all >> the same. These are details which can be tweaked later but yeah, some simplification will be necessary. >> >> > I think it would be useful to start posting patches early – such that >> > they can be reviewed and discussed. Thus, this is not really the 4th >> > and 5th item. >> > >> I can post patches every week instead since my proposal will set a milestone >> target for each week. >> Additionally, what do you think about me doing some other small tasks besides >> the proposed scope? What I was thinking about specifically was that it might >> be >> helpful to get the offloading documentation page up to date and add info on >> OpenACC. Updating documentation would be very welcome but not as part of a GSoC project, the rules forbid that. As far as small tasks are concerned, that is always very difficult in GCC and so we do not really expect all applicants to manage completing any. But it is important to demonstrate understanding of the relevant bits of GCC, for example by asking good questions on this list. Good luck, Martin
