Hi Thomas, I have updated the proposal according to your suggestions. Please take a look and let me know what you think.
Regards, Arijit On Fri, 27 Mar 2026 at 04:36, Thomas Schwinge <[email protected]> wrote: > > Hi Arijit! > > On 2026-03-25T00:53:33+0530, Arijit Kumar Das > <[email protected]> wrote: > > On Sun, 22 Mar 2026 at 17:26, Thomas Schwinge <[email protected]> > > wrote: > >> 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. > > > > Do tell me more about this "reverse offload" so that I might know which part > > of the codebase we should be concerned with (either in newlib, or in gcc, or > > nvptx-tools). > > That's 'libgomp/plugin/plugin-nvptx.c', in 'GOMP_OFFLOAD_run': use of a > separate CUDA Stream ('reverse_offload_aq'), and atomic access of > 'ptx_dev->rev_data', with host/GPU shared memory. In my understanding, > we'd generalize something like that for this project here. > > >> 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. > > > > I have prepared the proposal and made my submission. > > Thanks! > > > I'd be glad if you take a > > look at it and let me know what you think. > > The submission title and summary correctly capture what we'd like to do. > In the "Technical details on implementation" we'll want some more > technical detail added: > > >> 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. > > > > I didn't understand about this "messages" part fully. I have thought > > of it as a client- > > server system where the client code is implemented in newlib and the server > > code > > is implemented elsewhere (maybe in nvptx-tools or in gcc?). The client and > > the > > server share a portion of the host's memory. The client runs on the > > GPU, while the > > server runs as a process that starts when we run the compiled GPU kernel > > using > > nvptx-none-run, and exits as soon as the GPU kernel exits. > > Similarly in the submission, you talk about a "server, which runs as a > standalone process on the host". Actually, we can do simpler: it's not > another (separate) process, but the host-side launcher program > (nvptx-tools' 'run') acts as this server. Please add some details about > how that'd work in terms of nvptx-tools' 'run' current implementation: in > which region (abstractly, and specifically in its source code) would it > serve RPC requests? > > > The server > > executes the > > corresponding system calls that are requested by the client and writes > > the return value > > to the shared host buffer. Roughly, this is what I understand as of > > now. Please correct > > me if I am missing something. > > That's correct, abstractly. > > The server needs to be told what the client would like done, and then > needs to act on that, and return some data, for example. > > Now, consider that we have available a fixed-size shared host/GPU memory > space. This memory space is "unstructured": it's just a "blob" of > memory. The client/server RPC system needs to agree on how to structure > and interpret the underlying bytes of data, so that they mean something > specific (like, "write 123456 bytes of data to open file descriptor 7", > or "open file 'foo/bar', return file descriptor"). This is what I call a > "message" in the RPC system. > > Please provide a number of such "messages" that we need for this project, > how we might give meaning to the unstructured shared memory space. How > to synchronize the client and server? Is communication synchronous or > asynchronous -- what are expectations for POSIX I/O calls? Is there a > need to have several RPCs in flight at one point in time, in case that > would be useful, or is that simply not necessary? How do we structure > things so that a client request to, for example, "write 123456 bytes of > data" is acted on in some meaningful way even if we have just a shared > memory space of 1 KiB, for example. Consider POSIX 'write' etc. > semantincs. > > Regarding your schedule, I'll strongly suggest to not split up the client > vs. server implementation in the way that you currently have it, but > instead do it in lockstep, so that you'll quickly get the whole flow > implemented for one "message". > > For example, per POSIX semantics, can we assume that specific file > descriptors are open already upon program start, and by implemeting just > one RPC "message" we could already achieve something useful? > > >> 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? > > > > I have chosen it to be a large project this time (350 hrs), and > > prepared the tentative > > schedule for 12 + 6 weeks. This will allow some flexibility, and we > > will have more time > > to implement everything properly and get it to upstream (I prioritize > > this a lot!). Let me > > know it it's alright, or should we make some changes? > > Such a schedule works for me, yes. > > > Grüße > Thomas
