From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out1.suse.de (smtp-out1.suse.de [IPv6:2001:67c:2178:6::1c]) by sourceware.org (Postfix) with ESMTPS id 64E303858D39 for ; Mon, 3 Apr 2023 17:05:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 64E303858D39 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=suse.cz Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 09F6321F49; Mon, 3 Apr 2023 17:04:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1680541499; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=rdYG+O7zNtorMs1JEDXN2AIivUhlsyKw1s53D77EVYY=; b=mHgXjCNYMBbBcibv4aSiX4W3sq/JIPac4EdveDjSXhCnnPjsf0+8nIUirvHwP1iM1E/r3x vfJA+WjZXa2SyNxhkISOewIKG6AGGrD/6vXpzlE9aW0FfudOikaMK0jCw6/m5J+Y9e6Rsh /cqDr5v38QE5cc61RELntpWR43SQ29c= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1680541499; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=rdYG+O7zNtorMs1JEDXN2AIivUhlsyKw1s53D77EVYY=; b=Nw7yC98bPWsIoRAS4rIIu/Cl1CSZS41BWsDavuh8XXnlA71faW8MkcUSpAi0A3dAtNijkg QS0FfdTyBEZNwDBg== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id F37641331A; Mon, 3 Apr 2023 17:04:58 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id AYJdOzoHK2R6cgAAMHmgww (envelope-from ); Mon, 03 Apr 2023 17:04:58 +0000 From: Martin Jambor To: "Prasad, Adi" , Tobias Burnus , Thomas Schwinge Cc: "gcc@gcc.gnu.org" Subject: RE: GSoC Separate Host Process Offloading In-Reply-To: References: <87cz4rthqx.fsf@euler.schwinge.homeip.net> User-Agent: Notmuch/0.37 (https://notmuchmail.org) Emacs/28.2 (x86_64-suse-linux-gnu) Date: Mon, 03 Apr 2023 19:04:58 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_SOFTFAIL,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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' ; Thomas Schwinge >> >> Cc: gcc@gcc.gnu.org >> Subject: RE: GSoC Separate Host Process Offloading >>=20 >> Hi Tobias, >> Thanks for the reply! >>=20 >> > >> > Note that multiple offload targets are possible. For instance, on >> > Debian/Ubuntu, 'gcc -v' shows: >> > 'OFFLOAD_TARGET_NAMES=3Dnvptx-none:amdgcn-amdhsa' and lto-wrapper >> then >> > cycles through those, finding the offloading compiler in >> > $PATH/accel//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=3Dhost instead of having to >> > specify -foffload=3Dx86_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 "h= ost" to >> OFFLOAD_TARGET_NAMES rather than have the specific host e.g. "x86_64-non= e- >> linux-gnu"? This would 1) enable the use of "-foffload=3Dhost" automatic= ally 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=E2=80=99t happen in practice, since comp= iling for a >> separate host process would target CPUs while compiling for a separate d= evice >> would target GPUs, but it might be nicer to keep them conceptually separ= ate all >> the same. These are details which can be tweaked later but yeah, some simplification will be necessary. >>=20 >> > I think it would be useful to start posting patches early =E2=80=93 su= ch 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 miles= tone >> target for each week. >> Additionally, what do you think about me doing some other small tasks be= sides >> the proposed scope? What I was thinking about specifically was that it m= ight 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