Re: [GSoC] Question about continuing a 2025 project in GSoC 2026
Thomas Schwinge <[email protected]>
| Newsgroups | gmane.comp.gcc.devel |
|---|---|
| Message-ID | <[email protected]> |
Hi Arijit! On 2026-03-20T11:31:45+0530, Arijit Kumar Das via Gcc <[email protected]> wrote: > It appears that my mentor Thomas might be busy and is currently unable to > discuss > about the project I proposed. Always busy, this guy... ;'-\ > Meanwhile, I would appreciate some guidance > on this > project from the community so that I might be able to prepare my proposal > for submission. > > The project is about implementing an RPC mechanism in the newlib syscalls > for nvptx. This > is supposed to be a continuation of my last year's GSoC project. I would > appreciate if you > could tell me: > - about relevant resources where I could learn about this RPC mechanism; Obviously, familiarize yourself with principles of RPC generally. What we need here is not to use some existing big RPC framework (NFS, Sun RPC, gRPC, CORBA, etc.), but instead we'll have to come up with our own small implementation, suitable for the project's needs for host <-> GPU communication. Make some thoughts about it, present some ideas, but don't worry right now about getting right all the details of low-level implementation for the actual host <-> GPU communication primitives. We have something in libgomp's nvptx plugin (OpenMP "reverse offload") that we should be able to re-purpose (and extend) for this project. Also, don't focus on GCC/libgomp offloading right now, but again first on a nvptx target toolchain, with the GSoC project implementation to be done in newlib and nvptx-tools' 'run' tool. Based on the high-level idea of what we want to achieve, break it down into what (abstractly) needs to be done in the relevant softwares. Come up with list of RPCs ("messages") that we'll be able to send between host and GPU, and vice version, for the file I/O primitives that we'd like to support. > - what could be the possible project size; The longer, the more features can be implemented. (Can't change during project execution.) Also, depending on the number of hours per week that you roughly have available for this, decide on the project duration. (Can extend during project execution.) (All within the choices that Google Summer of Code offers, obviously.) What size/duration works for you? > - anything else which you think might be useful for me to know regarding > this. Looking forward to a first draft of your project proposal! :-) Grüße Thomas