public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Soumya Ranjan <sranjan1@uci.edu>
To: Martin Jambor <mjambor@suse.cz>
Cc: gcc@gcc.gnu.org, tschwinge@baylibre.com
Subject: Re: Initial draft of GSOC proposal - Offloading to a separate process on the same host.
Date: Mon, 1 Apr 2024 10:45:17 -0700	[thread overview]
Message-ID: <CAOXUgdGLiooTUeaR1pMyOOa7hwKEGOftOa=g0z8cnv4wt=nR7g@mail.gmail.com> (raw)
In-Reply-To: <ri6r0frphsa.fsf@virgil.suse.cz>

[-- Attachment #1: Type: text/plain, Size: 6188 bytes --]

Thank you Martin!
I've taken your advice into account and I've uploaded my proposal.

On Sat, Mar 30, 2024 at 1:49 PM Martin Jambor <mjambor@suse.cz> wrote:

> Hello,
>
> On Wed, Mar 27 2024, Soumya Ranjan wrote:
> > Hello!
> > Thanks for your response Martin!
> > Sorry for the late response, I've been researching the project, going
> over
> > the source code and preparing the proposal. After a lot of thought, I've
> > decided to go with the "Offloading to a separate process on the same
> host"
> > project, mostly because I feel like I've reasonable background on this
> > project, as I've worked on OpenMP, GPU Programming and have done
> coursework
> > on compilers and operating systems. Yes, I am no longer a student. I
> > recently graduated from the University of California, Irvine with a
> > master's degree in Computer Engineering (About 3 months back) and I've
> > recently joined Qualcomm as a firmware engineer. I realized that I have a
> > lot of free time, that I mostly spend playing video games, and I've
> always
> > wanted to get into open source development, so I thought this would be a
> > good opportunity, given how much I use gcc for everything.
> >
>
> This sounds great.
>
> First, please note that timing of the GSoC contributor application
> deadline (on the upcoming Tuesday) is a bit unfortunate because of
> Easter, many involved mentors have a long weekend (public holiday on
> Friday or Monday or, like me, both).  So please even if you do not
> receive any feedback, make sure to apply - and don't leave it until the
> last day.  IIUC a proposal can be always updated later.
>
> I'll have to admit that I read your proposal only quickly and it makes
> sense.  I'd just like to point out that the VGPU part is really a second
> (though perhaps much larger and interesting) part of the project, the
> first part would be to simulate a CPU-like accelerator with a separate
> memory.  But most of this work would be necessary for VGPU part too.
> What is more, the VGPU part is likely to be hard, so if your time
> constraints allow it and doing both is your goal, I'd suggest to apply
> for an 350-hour (large) project.
>
> I'll see if I can cough out any more feedback in time but as I wrote
> above, generally it is good and don't wait - t least not with the
> initial application.
>
> Good luck!
>
> Martin
>
>
> > Why specifically this project -
> > OpenMP's support for offloading to physical GPUs broadens the horizon for
> > high-performance computing applications, the complexity of setting up
> such
> > environments and the lack of adequate tooling for development and
> debugging
> > can hinder productivity. The VGPU project directly addresses these
> > challenges by providing a developer-friendly offloading target that
> > emulates GPU execution on the host CPU, bridging the existing tooling gap
> > and significantly enhancing developer productivity in the realm of
> parallel
> > computing.
> >
> > Anyway, getting into the details of the project, from my understanding,
> the
> > goals are -
> > 1) To implement a virtual GPU (VGPU) environment that mirrors physical
> GPU
> > architecture including support for different levels of parallelism (warp,
> > thread block, etc.).
> > 2) To enable the VGPU to serve as an offload target within the
> LLVM/OpenMP
> > framework. This includes adding a host-ISA offloaded code generation mode
> > that allows the compilation of OpenMP applications using GPU-specific
> paths
> > and runtimes, facilitating a more accurate emulation of GPU environments.
> > 3) To implement a plugin for libgomp that communicates with the libgomp
> > offloading machinery to manage the execution of offloaded code in a new
> > process, simulating the behavior of actual GPU devices.
> > 4) To optimize the VGPU to ensure that OpenMP applications executed on it
> > incur minimal performance overhead compared to native host execution,
> > thereby making it a viable option for development and testing purposes.
> >
> > Here's a rough timeline (Based on the timeline on the gsoc website) -
> > Pre-coding (Until May 27) -
> > 1) Setting up a development environment including LLVM/OpenMP and
> necessary
> > debugging tools.
> > 2) Conducting thorough literature review on existing GPU simulation
> > techniques and OpenMP offloading mechanisms.
> >
> > Week 1-3: Initial Infrastructure
> > 1) Design VGPU architecture (simulate gpu parallel execution models
> (warps,
> > blocks) and memory hierarchy (global, shared, private))
> > 2) Implement the core vgpu infrastructure, like basic memory management.
> >
> > Week 4-6: Integration with LLVM/OpenMP and Host-ISA Offload Mode
> > 1) Develop LLVM IR generation for VGPU target, thereby ensuring openMP
> > directives can be compiled into vgpu-compatible code.
> > 2) Add a new mode in the LLVM/OpenMP framework for generating offloaded
> > code specifically for the VGPU target.
> > 3) Get simple openMP applications to compile and execute on the VGPU.
> >
> > By Midterm evaluation, hopefully should have basic openmp applications
> > offloaded on the VGPU.
> >
> > Week 7-9: Extending functionality and Implementing libgomp Plugin
> > 1) Extend VGPU to support more functionality like loops, sections,
> parallel
> > blocks.
> > 2) Implement a plug-in for libgomp that interfaces with its offloading
> > machinery.
> > 3) Maybe look to integrate with debugging tools, so users can step
> through
> > offloaded regions and profile code.
> >
> > Week 10-12: Evaluation and Final Submission
> > 1) Benchmark against physical GPU's to evaluate the VGPU's performance.
> > 2) Prepare a final project report documenting the development process,
> > challenges, results and future work.
> >
> > I know this is a pretty high-level description, but I will try my best to
> > stick to this. This submission is mainly to go over the content. I would
> > appreciate any feedback I can get, and will make sure to submit a more
> > detailed description on my final submission. Awaiting your feedback.
> > Thanks,
> > Soumya Ranjan
>

      reply	other threads:[~2024-04-01 17:45 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-28  2:40 Soumya Ranjan
2024-03-30 20:48 ` Martin Jambor
2024-04-01 17:45   ` Soumya Ranjan [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAOXUgdGLiooTUeaR1pMyOOa7hwKEGOftOa=g0z8cnv4wt=nR7g@mail.gmail.com' \
    --to=sranjan1@uci.edu \
    --cc=gcc@gcc.gnu.org \
    --cc=mjambor@suse.cz \
    --cc=tschwinge@baylibre.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).