Initial draft of GSOC proposal - Offloading to a separate process on the same host.

Initial draft of GSOC proposal - Offloading to a separate process on the same host.

[Soumya Ranjan]

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

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.

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

Re: Initial draft of GSOC proposal - Offloading to a separate process on the same host.

[Martin Jambor]

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

Re: Initial draft of GSOC proposal - Offloading to a separate process on the same host.

[Soumya Ranjan]

[-- 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
>