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
