Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WG application draft #15

Open
wants to merge 4 commits into
base: master
Choose a base branch
from
Open

WG application draft #15

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
1b52123
Prepare a WG application draft
denzp Jun 1, 2019
ba685d4
Update documents/wg-application.md
denzp Jun 3, 2019
bbaff9c
More suggestions from @gnzlbg
denzp Jun 3, 2019
fc552b9
Several WG applications edits
denzp Jun 5, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
91 changes: 91 additions & 0 deletions documents/wg-application.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,91 @@
# CUDA WG - draft

## What value do you want to bring to the project?

The Working Group's goal is to deliver first-class CUDA support to Rust users - see our [Roadmap].

[Roadmap]: https://github.com/rust-cuda/wg/blob/master/documents/roadmap.md

## Why should it be put into place?

The WG is already in place as an unofficial WG, see our [Github], [Roadmap], [Zulip], and some PRs by WG members: [rust@denzp], [rust@peterhj], [stdsimd], [libc], etc.

Being an official WG would allow us to use the official communication channels like the rust-lang zulip, which would give us more visibility and allow us to attract more contributors.

[Github]: https://github.com/rust-cuda
[Zulip]: https://rust-cuda.zulipchat.com/
[libc]: https://github.com/rust-lang/libc/pull/1126
[stdsimd]: https://github.com/rust-lang-nursery/stdsimd/pulls?q=is%3Apr+nvptx+is%3Aclosed
[rust@denzp]: https://github.com/rust-lang/rust/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aclosed+author%3Adenzp
[rust@peterhj]: https://github.com/rust-lang/rust/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aclosed+author%3Apeterhj

## What is the working group about?

Right now, this WG is about making the already-existing Rust CUDA support minimally reliable.
Getting a safe and production-ready development experience on Stable Rust is our primary goal!

Also, currently a major obstacle for developing GPGPU applications and algorithms in Rust is a lack of learning resources.
We plan to solve the "documentation debt" with a broad range of tutorials, examples and references.

## What is the working group not about?

The WG is not focused on promoting or developing "standard" frameworks.
Instead, we want to provide basic and reliable support of the feature and inspire the community to start using it.

This WG is only about CUDA support - other GPGPU targets are out-of-scope.
Our focus is on making the current CUDA target more reliable.
Everything that goes beyond that (e.g. higher-level CUDA libraries, CUDA frameworks, etc.) is also out-of-scope.

## Is your WG long-running or temporary?

The CUDA WG is long-running. We have a [Roadmap] for an MVP, but there are many issues worth solving once that MVP is achieved (e.g. foundational libraries).

In the end, we hope the WG will evolve into another one to cover similar topics:
to support other GPGPU platforms or to create higher-level frameworks to improve end-to-end experience based on community feedback.

## What is your long-term vision?

Having a reliable and safe CUDA development experience is our ultimate goal.
To get there, first of all, we will need to achieve all milestones in our [Roadmap].

denzp marked this conversation as resolved.
Show resolved Hide resolved
## How do you expect the relationship to the project be?

The Working Group is mainly going to create various RFCs and send PRs to Rust components.

An important aspect of the WG is active participation in discussions related to the NVPTX target and involved tools.
This also includes [already reported issues](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3AO-NVPTX) and those that will be opened due to the work made by the WG.

### How do you want to establish accountability?

Currently, as an unofficial WG, we work completely in the open and we intend to go on in the same way.
Most of discussions happen either in out github issues, or in our public [Zulip], so that they be read by anyone.

Once we will start having regular meetings, we would publish agenda and summary.

## Which other WGs do you expect to have close contact with?

We would like to cooperate with *Language Team* (or perhaps, additionally with *Unsafe Code Guidelines WG*) in discussions about safety in SIMT code.
Additionally, it would be very important to discuss with *Infra team* a strategy of reliable deployment of `rust-ptx-linker` (likely as a `rustup` component).

On the other hand, proposed [Machine Learning WG](https://internals.rust-lang.org/t/enabling-the-formation-of-new-working-groups/10218/11) could leverage CUDA accelerated computing capabilities, so we can collaborate on their use cases.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd say here that we expect to have most contact with Alex Crichton, which could inform the Core Team about our work if they deem it necessary.

There are some open questions about the soundness of CUDA kernels and Rust's type system, which we will raise to the Language team when we deem appropriate (maybe link here to some of the open issues?).

We have also secured access to a Power9+Volta GPGPU cluster from OSI for CI (I think @peterhj requested the access?) and we'd like to work with the infra team to enable rust-lang/rust to use it at some point, but initially we'd like to experiment with using it on a smaller component like stdsimd to gain experience with it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the prolonged absence (due to a combo of work + travel). We got moved around a couple times but what we actually have access to now is a POWER8 + 2x Pascal (Tesla P100) machine via usual HPC batch scheduler setup (torque/PBS) via another POWER8 head node. They did install nvidia-docker on the compute node though, so the docker-based stdsimd tests should run on it fine. I had a custom CI-like setup that was working for single GPU nodes, though the torque/PBS stuff was the last blocker I was dealing with.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@peterhj wonderful, thanks for an update!

They did install nvidia-docker on the compute node though, so the docker-based stdsimd tests should run on it fine.

So, let's say, we theoretically can run CUDA-adjusted and resource-restricted Rust Playground there? I feel it will be extremely helpful for quick experiments.

Perhaps, could you please provide basic documentation about these things when you'll have time? It will be useful for people who never worked with HPC job schedulers (me at least 😉).

Copy link
Contributor

@gnzlbg gnzlbg Jun 7, 2019 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suppose that you get ssh access to some front-end nodes, and the only way to access the nodes with the GPGPUs is to schedule jobs with Torque.

I don't think they allow Playground like services for people to execute arbitrary code there, but even if they do, we would need to host the playground somewhere else, and each command (e.g. run), would need to ssh into the system, schedule a job with Torque, wait for the job to be scheduled, fetch the job logs, and report back.

So you would probably be waiting a while for the results of a playground run there.

EDIT: I suppose we could schedule a 24/7 interactive job using Torque there but... if I were the admin and I'd see that I'd just kick us out and revoke our credentials.

## What are your short-term goals?

Mainly, short-term goals are defined in our [Roadmap] for an MVP.
Additionally, we plan to make a poll about use cases, expectations, and community awareness that it is already possible to experiment with CUDA on Nightly Rust today.

## Who is the initial leadership?

> TBD...

## How do you intend to make your work accessible to outsiders?

Blog posts, announcements and retrospective about made decisions should help to get more people involved in either discussions or further experimenting.

## Everything that is already decided upon

We work in the open, see our [Github].

## Preferred way of contact/discussion

[Github] issues or [Zulip].