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
