public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Martin Jambor <mjambor@suse.cz>
To: Soumya Ranjan <sranjan1@uci.edu>,
	gcc@gcc.gnu.org, tschwinge@baylibre.com
Subject: Re: Initial draft of GSOC proposal - Offloading to a separate process on the same host.
Date: Sat, 30 Mar 2024 21:48:53 +0100	[thread overview]
Message-ID: <ri6r0frphsa.fsf@virgil.suse.cz> (raw)
In-Reply-To: <CAOXUgdGdoS7HUSUiHX-M9JhgcPCb-MQ8ZDn3Nhz0fr=fcgj25w@mail.gmail.com>

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-03-30 20:48 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 [this message]
2024-04-01 17:45   ` Soumya Ranjan

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=ri6r0frphsa.fsf@virgil.suse.cz \
    --to=mjambor@suse.cz \
    --cc=gcc@gcc.gnu.org \
    --cc=sranjan1@uci.edu \
    --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).