Hi Thomas,
On Sun, 22 Mar 2026 at 17:26, Thomas Schwinge <[email protected]> wrote:
>
> Always busy, this guy... ;'-\
Better late than never! :-D
>
> 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).
> 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.
Sure. The setup from last year's project is still intact :-)
> 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. I'd be glad if you take a
look at it and let me know what you think.
> 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. 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.
>
> 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?
>
> Looking forward to a first draft of your project proposal! :-)
Done :-)
Regards,
Arijit
