Re: [GSoC] Question about continuing a 2025 project in GSoC 2026

Hi Arijit!

On 2026-03-28T15:17:53+0530, Arijit Kumar Das <[email protected]> wrote:
> I have updated the proposal according to your suggestions. Please take
> a look and let me know what you think.

Thanks, good improvements in there!

If you've still got time until the end of the proposal submission period:

Do we actually need a separate thread in nvptx-tools 'run', with all the
complexity that multithreading brings with it?

You've correctly identified that we, approximately, need one kind of RPC
"message" per POSIX I/O function, and the general structuring of the
"unstructured blob of memory".

For your 'struct RPC_Message', a cleaner approach is possible, that makes
it obvious which data fields are relevant for which kind of 'func_id',
and also maximizes, for example, the 'buf' size usable for
'ID_READ'/'ID_WRITE': in those two case we don't need the 'path',
'flags', 'mode' that we need for 'ID_OPEN' -- and vice versa.  Which C
language construct(s) could we use?  (Which feature of C++ does this
correspond to, roughly?)

What could we do instead of having a separate 'struct RPC_Return' in its
separate shared memory space?

How to make sure that host doesn't already start acting, while the GPU is
still populating the 'struct RPC_Message', and vice versa: how to make
sure that GPU doesn't already resume acting, while the host is still
populating the 'struct RPC_Message'/'struct RPC_Return'?

I don't follow the motivation for needing a timeout mechanism on the GPU;
I don't think we need that complexity.

You've correctly identified that simple synchronous communication is
sufficient for POSIX I/O, for purpuses of this project, and that no
multiple RPCs can be happening, concurrently.  Let's assume (to begin
with, at least) that there's only a single GPU thread making RPC
requests.

How do we (simply) implement 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 'char buf[MAX_DATA_BUFFER_SIZE];' of 1 KiB, for
example?  Consider POSIX 'write' semantincs.


Grüße
 Thomas


> 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