Hi Thomas, Some updates here.
After some research, I realized that the nouveau driver may not be sufficient for our workload, so the nvidia drivers are a must, along with the CUDA toolchain. Fortunately, I got the drivers to work under Debian when I disabled Secure Boot in the firmware. So we're good to go in this part! I now have a solid high-level understanding of the tasks to be undertaken, which I have briefly described in my proposal. I aim to get the nuts and bolts as I work on this project. > 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? Since you might be busy and may not have time to review my draft proposal here, so I've directly uploaded it to the GSoC portal. Looking forward to your thoughts! Best regards, Arijit On Thu, 3 Apr, 2025, 11:42 am Arijit Kumar Das, < arijitkdgit.offic...@gmail.com> wrote: > 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 >> >
