Hi, > Let us know if you need further help; we understand it's not trivial to get this set up at first.
Sure! To be honest, I haven't had time to completely set up the toolchain yet (due to classes and ongoing mid-semester examinations). I plan to finish it as soon as I get some time. I have set up the development environment though. I have installed Debian 12 (multiboot) onto my laptop and installed all necessary packages. Newlib and GCC sources are at my hand. > Do you have access to a system with an AMD GPU supported by GCC, or any Nvidia GPU? Yes, my laptop has an Nvidia RTX 4050 GPU, which I believe should work for nvptx. The only thing that concerns me here, though, is that I was unable to get the nvidia drivers to work. Installed and reinstalled them a couple of times, still they won't load. I currently do not have them installed, but I suppose I'll do something about it soon. Or will the preinstalled nouveau driver work just fine? > (I assume, by now you've found the newlib source code?) Yes! I have browsed through the newlib sources. The sources that we may be concerned with are apparently at newlib/libc/machine/nvptx. Since, I do not own an AMD GPU, I guess I should probably focus on nvptx. Right? > Actually, only for GCN: 'gcc/config/gcn/gcn-run.cc'. For nvptx, it's > part of <https://github.com/SourceryTools/nvptx-tools>: 'nvptx-run.cc'. Fine, I'll check this out! Just also wanted to ask that currently I'm preparing a draft proposal, would it be alright if I send it here in this thread for your review? Best regards, Arijit On Wed, 2 Apr, 2025, 8:01 pm Thomas Schwinge, <tschwi...@baylibre.com> wrote: > Hi Arijit, Andrew! > > Arijit, welcome to GCC! > > On 2025-03-11T03:26:44+0530, Arijit Kumar Das via Gcc <gcc@gcc.gnu.org> > wrote: > > Thank you for the detailed response! This gives me a much clearer picture > > of how things work. > > > > Regarding the two possible approaches: > > > > - I personally find *Option A (self-contained in-memory FS)* more > > interesting, and I'd like to work on it first. > > Sure, that's fine. ..., and we could then still put Option B on top, in > case that just Option A should turn out to be too easy for you. ;-) > > > - However, if *Option B (RPC-based host FS access)* is the preferred > > approach for GSoC, I’d be happy to work on that as well. > > > For now, I’ll begin setting up the toolchain and running simple OpenMP > > target kernels as suggested. Thanks again for your guidance! > > Let us know if you need further help; we understand it's not trivial to > get this set up at first. > > Do you have access to a system with an AMD GPU supported by GCC, or any > Nvidia GPU? > > Just a few more comments in addition to Andrew's very useful remarks. > (Thank you, Andrew!) > > > On Mon, 10 Mar, 2025, 10:55 pm Andrew Stubbs, <a...@baylibre.com> wrote: > >> On 10/03/2025 15:37, Arijit Kumar Das via Gcc wrote: > >> > I have carefully read the project description and understand that the > goal > >> > is to modify *newlib* and the *run tools* to redirect system calls > for file > >> > I/O operations to a virtual, volatile filesystem in host memory, as > the GPU > > Instead of "in host memory", it should be "in GPU memory" (for Option A). > > >> > lacks its own filesystem. Please correct me if I’ve misunderstood any > >> > aspect. > > >> > I have set up the GCC source tree and am currently browsing relevant > files > >> > in the *gcc/testsuite* directory. However, I am unsure *where the run > tools > >> > source files are located and how they interact with newlib system > calls.* > > >> Newlib isn't part of the GCC repo, so if you > >> can't find the files then that's probably why! > > (I assume, by now you've found the newlib source code?) > > >> The "run" tools are installed as part of the offload toolchain, albeit > >> hidden under the "libexec" directory because they're really only used > >> for testing. You can find the sources with the config/nvptx or > >> config/gcn backend files. > > Actually, only for GCN: 'gcc/config/gcn/gcn-run.cc'. For nvptx, it's > part of <https://github.com/SourceryTools/nvptx-tools>: 'nvptx-run.cc'. > > >> Currently, system calls such as "open" simply return EACCESS > >> ("permission denied") so the stub implementations are fairly easy to > >> understand (e.g. newlib/libc/sys/amdgcn/open.c). > > (I assume, by now you've found the corresponding nvptx code in newlib?) > > >> The task would be to > >> insert new code there that actually does something. You do not need to > >> modify the compiler itself. > > > Grüße > Thomas >
