🐉 Making Rust a first-class language and ecosystem for GPU shaders 🚧

Embark

Last update: Jan 9, 2023

Related tags

Overview

`🐉 rust-gpu`

Rust as a first-class language and ecosystem for GPU graphics & compute shaders

Current Status 🚧

Note: This project is still heavily in development and is at an early stage.

Compiling and running simple shaders works, and a significant portion of the core library also compiles.

However, many things aren't implemented yet. That means that while being technically usable, this project is far from being production-ready. Support for specific features in Rust and SPIR-V are tracked on GitHub.

Example

use glam::{Vec3, Vec4, vec2, vec3};

#[spirv(fragment)]
pub fn main(
    #[spirv(frag_coord)] in_frag_coord: &Vec4,
    #[spirv(push_constant)] constants: &ShaderConstants,
    output: &mut Vec4,
) {
    let frag_coord = vec2(in_frag_coord.x, in_frag_coord.y);
    let mut uv = (frag_coord - 0.5 * vec2(constants.width as f32, constants.height as f32))
        / constants.height as f32;
    uv.y = -uv.y;

    let eye_pos = vec3(0.0, 0.0997, 0.2);
    let sun_pos = vec3(0.0, 75.0, -1000.0);
    let dir = get_ray_dir(uv, eye_pos, sun_pos);

    // evaluate Preetham sky model
    let color = sky(dir, sun_pos);

    *output = tonemap(color).extend(1.0)
}

See source for full details.

Our Vision & Community Contributions

rust-gpu is a project that we at Embark think has the potential to change the way GPU programming works in multiple ways. One of the primary things we think it can change is opening the door to leverage the open source culture of sharing and improving each others' code, and our end goal and vision for rust-gpu is to develop it very much in tandem with the community. However, the project is still in quite early stages and has a very small team working on it, so in order to be productive and guide the project to where we ultimately want it to go, as of right now, we need to focus on our own primary use cases for our projects at Embark.

What this means practically is that it is unlikely that we'll be able to accept major changes from community members at this time. If you have a large change you would like to make, please file an issue and/or ask on our Discord in the #rust-gpu channel to see if it is something we'll be able to accept before working on it, as it is not great to have to turn down stuff that community members have poured their time and effort into. As the project matures, we'll in theory be able to accept more input from the community and move closer and closer to the goals outlined above. Thank you so much for your understanding!

Getting started

Check out The rust-gpu Dev Guide for information on how to get started with using it in your projects.

Experiment with rust-gpu shaders in-browser at SHADERed.

Background

Historically in games GPU programming has been done through writing either HLSL, or to a lesser extent GLSL. These are simple programming languages that have evolved along with rendering APIs over the years. However, as game engines have evolved, these languages have failed to provide mechanisms for dealing with large codebases, and have generally stayed behind the curve compared to other programming languages.

In part this is because it's a niche language for a niche market, and in part this has been because the industry as a whole has sunk quite a lot of time and effort into the status quo. While over-all better alternatives to both languages exist, none of them are in a place to replace HLSL or GLSL. Either because they are vendor locked, or because they don't support the traditional graphics pipeline. Examples of this include CUDA and OpenCL. And while attempts have been made to create language in this space, none of them have gained any notable traction in the gamedev community.

Our hope with this project is that we push the industry forward by bringing an existing, low-level, safe, and high performance language to the GPU; namely Rust. And with it come some additional benefits that can't be overlooked: a package/module system that's one of the industry's best, built in safety against race-conditions or out of bounds memory access, a wide range of tools and utilities to improve programmer workflows, and many others!

Why Embark?

At Embark, we've been building our own new game engine from the ground up in Rust. We have previous experience in-house developing the RLSL prototype, and we have a team of excellent rendering engineers that are familiar with the problems in current shading languages both from games, game engines and other industries. So, we believe we are uniquely positioned to attempt solving this problem.

We want to streamline our own internal development with a single great language, build an open source graphics ecosystem and community, facilitate code-sharing between GPU and CPU, and most importantly: to enable our (future) users, and fellow developers, to more rapidly build great looking and engaging experiences.

If we do this project right, one wouldn't necessarily need an entire team of rendering engineers to build a good looking game, instead one would simply use a few of the existing open-source crates that provide the graphical effects needed to create the experience you're after. Instead of sharing and copy'n'pasting snippets of TAA code on forum posts, one could simply find and use the right crates from crates.io.

Project scope

The scope of this overall project is quite broad, but is in multiple stages

rustc compiler backend to generate SPIR-V, plugging in via -Z codegen-backend.
- This is the same mechanism that rustc_codegen_cranelift and rustc_codegen_gcc use.
- Currently only SPIR-V support is planned, Vulkan's open compiler target
- Possible a future version could support DXIL (the target for DirectX) or WGSL (the WebGPU shading language that's bijective with SPIR-V)
Focus on Vulkan graphics shaders first, then after Vulkan compute shaders
Cargo and crates.io support to develop and publish SPIR-V crates
High-level render graph to take advantage of this, make it easy for users to develop and use rendering effects.

Process

We use this repo as a monorepo for everything related to the project: crates, tools, shaders, examples, tests, and design documents. This way, we can use issues and PRs covering everything in the same place, cross-reference stuff within the repo, as well as with other GitHub repos such as rspirv and Rust itself.

We meet weekly over a Discord call to discuss design and triage issues. Each meeting has an issue with agenda, links and minutes.

We have a #rust-gpu Discord channel for fast discussion and collaboration.

Backwards compatibility, breaking changes and deprecation

Right now because the project is in an early state of development, we might introduce temporary changes as stop-gap measures, or implement features or APIs that might not work exactly in a way we end up liking. Therefore it is expected that some (if not most) of the user facing code will change and evolve over time. At the moment this means that we make no guarantees about backwards compatibility and have no formal deprecation model in place. Effectively meaning that currently we only support building from source with the latest main branch in our repository. We appreciate our early adopters and would ask them to evolve their code along with ours.

Structure

There are a few different components to this repo:

rfcs for in-depth discussion and specs.
rustc_codegen_spirv for the compiler itself.
spirv-std for GPU intrinsics, types, and other library items used by GPU crates.
spirv-builder for a convenient way of building a GPU crate in a CPU build.rs file.

Related Projects

Historical and other related projects for compiling Rust code to GPUs.

2016: glassful Compiles a subset of Rust to GLSL.
2017: inspirv-rust Experimental Rust to SPIR-V compiler.
2018: nvptx Rust to PTX compiler.
2020: accel GPGPU library for Rust.
2020: rlsl Predeccesor to rust_gpu, Rust to SPIR-V compiler.
2021: Rust CUDA Rust to PTX compiler, similar mechanism to rustc_codegen_spirv.

Contributing

We welcome community contributions to this project.

Please read our Contributor Guide for more information on how to get started.

License

Licensed under either of

Apache License, Version 2.0, (LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0)
MIT license (LICENSE-MIT or http://opensource.org/licenses/MIT)

at your option.

Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.

Comments

Convert to use `glam` for math types
Removes the temporary math types in spirv-std and uses our experimental spirv fork of glam (https://github.com/bitshifter/glam-rs/pull/85) for our example shader! 🎉

Todo:

[x] Proper copysign

[x] Fix constant assert_uninit

[x] Compile on CPU

[x] Compile on GPU

[x] CUT: Solve clippy error: constant runtime array value - CI clippy on shader disabled for now, tracked in #186

Fix #134
s: waiting on review
opened by repi 26

Example spawns only non-responding black window [Ubuntu 20.10]

When I follow the tutorial on setting up the example, I successfully compile the project and when I run it, it just spawns a black window, doing literally nothing (even if I wait really long enough).

Ubuntu takes notice and asks me if I want to kill the not responding process, but I patiently wait, without any luck.
No logs are written as there is no exception, can I turn on debug logging somehow?

Maybe it's correlated to the dmesg error message of NVIDIA I'm having after upgrade to Ubuntu 20.10? (I'm using 450.80.02)

[    5.288932] nvidia-gpu 0000:01:00.3: i2c timeout error e0000000
[    5.290984] ucsi_ccg 0-0008: i2c_transfer failed -110
[    5.293078] ucsi_ccg 0-0008: ucsi_ccg_init failed - -110
[    5.295171] ucsi_ccg: probe of 0-0008 failed with error -110

thus I assume the integrated GPU chip is currently in use (Intel(R) UHD Graphics 630):

$ lshw -C display

sudo lshw -C display
  *-display                 
       description: VGA compatible controller
       product: TU106M [GeForce RTX 2070 Mobile]
       vendor: NVIDIA Corporation
       physical id: 0
       bus info: pci@0000:01:00.0
       version: a1
       width: 64 bits
       clock: 33MHz
       capabilities: pm msi pciexpress vga_controller bus_master cap_list rom
       configuration: driver=nvidia latency=0
       resources: irq:166 memory:ac000000-acffffff memory:80000000-8fffffff memory:90000000-91ffffff ioport:4000(size=128) memory:ad000000-ad07ffff
  *-display
       description: VGA compatible controller
       product: UHD Graphics 630 (Mobile)
       vendor: Intel Corporation
       physical id: 2
       bus info: pci@0000:00:02.0
       version: 00
       width: 64 bits
       clock: 33MHz
       capabilities: pciexpress msi pm vga_controller bus_master cap_list rom
       configuration: driver=i915 latency=0
       resources: irq:165 memory:ab000000-abffffff memory:40000000-4fffffff ioport:5000(size=64) memory:c0000-dffff

Just a side note: I had to solve these issues during installation first:

SPIR-V installation (Ubuntu 20.10 -> apt install spirv-tools :+1: )
https://github.com/EmbarkStudios/rust-gpu/issues/73#issuecomment-712800002 (forcing cargo clean)
https://github.com/rust-lang/rls/issues/1587 (toolchain reinstall)
https://github.com/EmbarkStudios/rust-gpu/issues/110 (avoiding resize))

System Info

Rustc version: rustc 1.43.0
SPIR-V version:

SPIRV-Tools v2020.3 unknown hash, 2020-06-17T19:41:32
Targets:
  SPIR-V 1.0
  SPIR-V 1.1
  SPIR-V 1.2
  SPIR-V 1.3
  SPIR-V 1.4
  SPIR-V 1.5
  SPIR-V 1.2 (under OpenCL 2.2 Full Profile semantics)
  SPIR-V 1.0 (under Vulkan 1.0 semantics)
  SPIR-V 1.3 (under Vulkan 1.1 semantics)
  SPIR-V 1.4 (under Vulkan 1.1 semantics)
  SPIR-V 1.3 (under WIP WebGPU semantics)

Rust: 1.43.0+dfsg1+llvm-1~exp1ubuntu2
OS: Ubuntu 20.10
GPU: GeForce RTX 2070 Mobile | Intel(R) UHD Graphics 630
SPIR-V: SPIRV-Tools v2020.3 unknown hash, 2020-06-17T19:41:32

t: bug p: linux g: nvidia g: intel

opened by jirislav 24

Replace usage of spirv-* binaries with spirv-tools rust crate
Making this a draft so that others can leave comments, I think I need to add a wrapper around the Validator as otherwise we will still require having spirv-tools installed which is kind of lame when we are already paying the compile time cost for building spirv-tools

Additions

Adds spirv-headers and spirv-tools as git submodules (will add docs about retrieiving/updating them for contributors)

Adds spirv-tools-sys which builds spirv-tools, including a small generator script that generates some includes based on spirv-headers

Adds a spirv-tools-sys/src/c/opt.cpp which is just a thin (and incomplete) C wrapper around Optimizer because C++

Adds a spirv-tools crate which provides a slighly nicer API on top of spirv-tools-sys

Changes

Replaces the usage of the spirv-opt binary in link.rs with spirv_tools::opt::Optimizer

Replaces the usage of spirv-val for validating resulting binaries in link.rs with spirv_tools::val::Validator

Replaces the usage of spirv-as in the linker tests with spirv_tools::as::Assembler

All of the crates that use rustc_codegen_spirv now have a use-installed-tools and use-compiled-tools feature flags, where use-compiled-tools is the default feature for optimal user experience.

Missing

There is one change I had to do in our spirv-tools fork due some incredible strangeness with libstdc++ streams, so right now the Assembler will choke on hexadecimal floats, but we only use the Assembler in tests and none of them currently use hexadecimal floats, so figured this would be ok for now, the issue is fixable but doing C++ code was making me sad so I punted until it became an actual issue.

Resolves: #31
opened by Jake-Shadle 20
Implement OpTypeMatrix
Fixes https://github.com/EmbarkStudios/rust-gpu/issues/82.

This PR adds #[spirv(matrix(ty, m, n))] attribute. A type with #[spirv(matrix(..))] is expressed as OpTypeMatrix in SPIR-V. An example usage is tests/ui/spirv-attr/matrix-type.rs.

~~While OpTypeVector is implemented by utilizing #[repr(simd)], this PR implements OpTypeMatrix by introducing the new trait Matrix because I couldn't find a usable attribute.~~

~~When converting Ty to SPIRV type, it uses OpTypeMatrix if the Ty implements Matrix.~~

TODO

Make glam matrices OpMatrix Since many operations in glam's matrices cast self to inner type, we need to add attributes to glam matrices and its inner types. ``~~Currently, we can't add the attribute to glam::core::storage::Column*<V> because we can't know its vector length at definition. We may handle it by adding #[spirv(matrix(m, param(n)))] syntax and refer nth generics type (e.g. glam::Vec3) and infer vector length from it...~~
opened by hatoo 18
Add Const Generic Image Type
This PR refactors Image in the backend to not use attributes to determine things like dimensionality and depth, and to instead accept them as const generics as parameters. This has the advantage of only needing a single Image type as opposed previously to requiring a new type for each combination, and also allows us to have enums to represent all of the possibilities rather than using u32s directly.

Additions

macros::Image a new procedural macro for defining Image types.

image::SampleType a trait that allows us to be generic of the underlying sampled type of the image.

image::ImageCoordinate a trait built on top of Vector for parameterising image coordinate vectors based on the sampled type, dimensionality, and arrayed-ness of the Image.

A new spirv_types crate for holding types that are useful in both spirv-std and spirv-std-macros.

Re-works

crate/spirv-std-macros has been moved into the spirv-std folder as macros beside the shared crate, this keeps the folder structure cleaner.
opened by XAMPPRocky 18

Newer libc versions (0.2.113 or later) don't compile with Rust-GPU's rust-toolchain.

Expected Behaviour

Following the steps described in the docs should work without errors in the supported platforms.

Example & Steps To Reproduce

Create a new blanket rust project with cargo new
Copy the rust tool-chain file from git onto the root of the project
Add [build-dependencies] spirv-builder = { git = "https://github.com/EmbarkStudios/rust-gpu" } to the toml file.
Create a build.rs file, copy the snippet from the docs and replace the path to the shader and the target with the relevant strings.

System Info

Rust: rust version rustc 1.62.0-nightly (1f7fb6413 2022-04-10)
OS: Ubuntu 22.04
GPU: Nvidia GTX 1070
SPIR-V: vulkan

Backtrace

error[E0658]: `const extern fn` definitions are unstable
    --> /home/makogan/.cargo/registry/src/github.com-1ecc6299db9ec823/libc-0.2.131/src/macros.rs:188:17
     |
188  | /                 pub $($constness)* unsafe extern fn $i($($arg: $argty),*
189  | |                 ) -> $ret {
190  | |                     $($body);*
191  | |                 }
     | |_________________^
     |
    ::: /home/makogan/.cargo/registry/src/github.com-1ecc6299db9ec823/libc-0.2.131/src/unix/linux_like/mod.rs:1499:1
     |
1499 | / f! {
1500 | |     pub fn CMSG_FIRSTHDR(mhdr: *const msghdr) -> *mut cmsghdr {
1501 | |         if (*mhdr).msg_controllen as usize >= ::mem::size_of::<cmsghdr>() {
1502 | |             (*mhdr).msg_control as *mut cmsghdr
...    |
1545 | |     }
1546 | | }
     | |_- in this macro invocation
     |
     = note: see issue #64926 <https://github.com/rust-lang/rust/issues/64926> for more information
     = help: add `#![feature(const_extern_fn)]` to the crate attributes to enable
     = note: this error originates in the macro `f` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0658]: `const extern fn` definitions are unstable
    --> /home/makogan/.cargo/registry/src/github.com-1ecc6299db9ec823/libc-0.2.131/src/macros.rs:203:17
     |
203  | /                 pub $($constness)* extern fn $i($($arg: $argty),*
204  | |                 ) -> $ret {
205  | |                     $($body);*
206  | |                 }
     | |_________________^
     |
    ::: /home/makogan/.cargo/registry/src/github.com-1ecc6299db9ec823/libc-0.2.131/src/unix/linux_like/mod.rs:1548:1
     |
1548 | / safe_f! {
1549 | |     pub fn SIGRTMAX() -> ::c_int {
1550 | |         unsafe { __libc_current_sigrtmax() }
1551 | |     }
...    |
1615 | |     }
1616 | | }
     | |_- in this macro invocation
     |
     = note: see issue #64926 <https://github.com/rust-lang/rust/issues/64926> for more information
     = help: add `#![feature(const_extern_fn)]` to the crate attributes to enable
     = note: this error originates in the macro `safe_f` (in Nightly builds, run with -Z macro-backtrace for more info)

t: bug

opened by Makogan 17

Build fails on Ubuntu 2020

Error: linking with `cc` failed: exit code: 1
  |
  = note: "cc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-m64" "-Wl,--eh-frame-hdr" "-L" "/home/arong/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "/home/arong/projects/embark/rust-gpu/target/debug/build/miniz-sys-c89d19c1b27f3851/build_script_build-c89d19c1b27f3851.build_script_build.79bpo45v-cgu.0.rcgu.o" "/home/arong/projects/embark/rust-gpu/target/debug/build/miniz-sys-c89d19c1b27f3851/build_script_build-c89d19c1b27f3851.build_script_build.79bpo45v-cgu.1.rcgu.o" "/home/arong/projects/embark/rust-gpu/target/debug/build/miniz-sys-c89d19c1b27f3851/build_script_build-c89d19c1b27f3851.build_script_build.79bpo45v-cgu.10.rcgu.o" "/home/arong/projects/embark/rust-gpu/target/debug/build/miniz-sys-c89d19c1b27f3851/build_script_build-c89d19c1b27f3851.build_script_build.79bpo45v-cgu.11.rcgu.o" "/home/arong/projects/embark/rust-gpu/target/debug/build/miniz-sys-c89d19c1b27f3851/build_script_build-c89d19c1b27f3851.build_script_build.79bpo45v-cgu.12.rcgu.o" "/home/arong/projects/embark/rust-gpu/target/debug/build/miniz-sys-c89d19c1b27f3851/build_script_build-c89d19c1b27f3851.build_script_build.79bpo45v-cgu.13.rcgu.o" "/home/arong/projects/embark/rust-gpu/target/debug/build/miniz-sys-c89d19c1b27f3851/build_script_build-c89d19c1b27f3851.build_script_build.79bpo45v-cgu.14.rcgu.o" "/home/arong/projects/embark/rust-gpu/target/debug/build/miniz-sys-c89d19c1b27f3851/build_script_build-c89d19c1b27f3851.build_script_build.79bpo45v-cgu.15.rcgu.o" "/home/arong/projects/embark/rust-gpu/target/debug/build/miniz-sys-c89d19c1b27f3851/build_script_build-c89d19c1b27f3851.build_script_build.79bpo45v-cgu.2.rcgu.o" "/home/arong/projects/embark/rust-gpu/target/debug/build/miniz-sys-c89d19c1b27f3851/build_script_build-c89d19c1b27f3851.build_script_build.79bpo45v-cgu.3.rcgu.o" "/home/arong/projects/embark/rust-gpu/target/debug/build/miniz-sys-c89d19c1b27f3851/build_script_build-c89d19c1b27f3851.build_script_build.79bpo45v-cgu.4.rcgu.o" "/home/arong/projects/embark/rust-gpu/target/debug/build/miniz-sys-c89d19c1b27f3851/build_script_build-c89d19c1b27f3851.build_script_build.79bpo45v-cgu.5.rcgu.o" "/home/arong/projects/embark/rust-gpu/target/debug/build/miniz-sys-c89d19c1b27f3851/build_script_build-c89d19c1b27f3851.build_script_build.79bpo45v-cgu.6.rcgu.o" "/home/arong/projects/embark/rust-gpu/target/debug/build/miniz-sys-c89d19c1b27f3851/build_script_build-c89d19c1b27f3851.build_script_build.79bpo45v-cgu.7.rcgu.o" "/home/arong/projects/embark/rust-gpu/target/debug/build/miniz-sys-c89d19c1b27f3851/build_script_build-c89d19c1b27f3851.build_script_build.79bpo45v-cgu.8.rcgu.o" "/home/arong/projects/embark/rust-gpu/target/debug/build/miniz-sys-c89d19c1b27f3851/build_script_build-c89d19c1b27f3851.build_script_build.79bpo45v-cgu.9.rcgu.o" "-o" "/home/arong/projects/embark/rust-gpu/target/debug/build/miniz-sys-c89d19c1b27f3851/build_script_build-c89d19c1b27f3851" "/home/arong/projects/embark/rust-gpu/target/debug/build/miniz-sys-c89d19c1b27f3851/build_script_build-c89d19c1b27f3851.35mmgpf51618asqk.rcgu.o" "-Wl,--gc-sections" "-pie" "-Wl,-zrelro" "-Wl,-znow" "-nodefaultlibs" "-L" "/home/arong/projects/embark/rust-gpu/target/debug/deps" "-L" "/home/arong/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-Wl,-Bstatic" "/home/arong/projects/embark/rust-gpu/target/debug/deps/libcc-d952d81c0b7fad63.rlib" "-Wl,--start-group" "/home/arong/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-6e0e72ef3f331f94.rlib" "/home/arong/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libpanic_unwind-eed7c8ea6eea20e8.rlib" "/home/arong/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libminiz_oxide-637cb1b53c807e95.rlib" "/home/arong/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libadler-099cf0af4375543b.rlib" "/home/arong/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libobject-b5f18e83369ef257.rlib" "/home/arong/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libaddr2line-3bb19daa4485d5fe.rlib" "/home/arong/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libgimli-5298ab0591e7fb29.rlib" "/home/arong/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_demangle-2e4947d254d0b599.rlib" "/home/arong/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libhashbrown-1532436f783b0405.rlib" "/home/arong/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_std_workspace_alloc-3d12d76f5782439f.rlib" "/home/arong/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libunwind-87f8d20d4e058c86.rlib" "/home/arong/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcfg_if-d41f1ff31e4e0f27.rlib" "/home/arong/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-0d5ea4f2d39b8e27.rlib" "/home/arong/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-31288459e6a43502.rlib" "/home/arong/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_std_workspace_core-c52e5d6301e1bd59.rlib" "/home/arong/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-2675a9a46b5cec89.rlib" "-Wl,--end-group" "/home/arong/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins-f51baad7bbcb81c4.rlib" "-Wl,-Bdynamic" "-lgcc_s" "-lutil" "-lrt" "-lpthread" "-lm" "-ldl" "-lc"
  = note: /usr/bin/ld: /home/arong/projects/embark/rust-gpu/target/debug/deps/libcc-d952d81c0b7fad63.rlib(cc-d952d81c0b7fad63.cc.6a6gwtiq-cgu.10.rcgu.o)(.debug_info+0x1001fef): reloc against `.text._ZN68_$LT$alloc..sync..Weak$LT$T$GT$$u20$as$u20$core..ops..drop..Drop$GT$4drop17h98f236610afb21f5E': error 4
          collect2: error: ld returned 1 exit status


error: aborting due to previous error

error: could not compile `miniz-sys`

I think I've installed all prerequisites.

t: bug p: linux g: nvidia

opened by aron-granberg 17

Add changes to compile rust-gpu on the latest nightly

This PR along with allows rustc to be able to pull in and compile rust-gpu as a codegen backend. There's also some changes that are needed on rustc side, for which I'll create a follow up PR that contains a way to checkout and patch rust-lang/rust.
s: waiting on review

opened by XAMPPRocky 15
Cleanup pass on example shader and vk example-runner
Removes vertex and index buffers; instead, generates position data based on vertex index in the shader

Removes depth buffer as it's not being used anyway

Removes the unused vertex_color input from vertex shader

Renames the wrongly-names out_color output in the vertex shader to out_pos with corresponding in_pos in the frag shader, which is what it's being used for (that's the data that gets wired to the fragment shader input at location 0, because the builtin "position" output is separate). We could also just scrap this output and use #[spirv(builtin = "frag_coord")] in the fragment shader but I think it's helpful to have there in the example.

Renames a couple of variables in the fragment shader for better clarity

Uses negative viewport height (flips viewport) which brings clip space to parity with wgpu's (and DirectX's) clip space, useful if we want to directly use the same shader in #92 because otherwise, it will be flipped

Uses sRGB-encoded surface rather than doing odd sorta-gamma correction in shader

Replaces the weird tone mapping step and uncharted 2 tone mapping operator with a new (better ;) ) one https://www.desmos.com/calculator/igytv8ck36
opened by fu5ha 14
Add `debug_printf!` and `debug_printfln!` macros that uses the DebugPrintf extension

See https://github.com/EmbarkStudios/rust-gpu/issues/151.

This will probably require some work before being merged. These macros and different from the core rust print and println macros as the type of variables needs to be specified in the format string. There's probably a way to change this as mentioned here: https://github.com/EmbarkStudios/rust-gpu/issues/151#issuecomment-717584254 but for now I'm doing the simpler thing.

I have a branch here: https://github.com/EmbarkStudios/rust-gpu/compare/main...expenses:printf-working that modifies the sky shader and ash runner for testing. It requires 'Debug Printf' to be checked in the Vulkan Configuration app.

One important caveat is that using DebugPrintf seems to SEGFAULT (on Windows I get a (exit code: 0xc0000005, STATUS_ACCESS_VIOLATION)) the Vulkan program if you build a single module with multiple entry points. This is truely bizarre, no clue what's going on here. The only difference between working code and segfaulting code is this: https://github.com/expenses/rust-gpu/compare/expenses:printf-not-working...printf-working.

At first I thought this was a driver issue but I'm getting this on both an integrated intel gpu and an external amd gpu.

opened by expenses 13
Use installed SPIR-V tools for compiletest

This PR changes the default to require installed tools and to disable compiling examples for tests, both of which help reduce compile times. We don't currently have any tests for these examples but they are always compiled when changes in the compiler happen which makes tests run longer.

opened by XAMPPRocky 13
We should consider using `#[rustc_on_unimplemented]` on `spirv-std` helper traits.
I was reviewing this nightly bump PR:

https://github.com/EmbarkStudios/rust-gpu/pull/982

And its diff shows some nightly diagnostic improvements of the form:

12 | *output = image.query_levels(); - | ^^^^^ ------------ required by a bound introduced by this call - | | - | the trait `HasQueryLevels` is not implemented for `Image<f32, 4, 2, 0, 0, 1, 0>` + | ^^^^^^^^^^^^ the trait `HasQueryLevels` is not implemented for `Image<f32, 4, 2, 0, 0, 1, 0>` | = help: the following other types implement trait `HasQueryLevels`: Image<SampledType, 0, DEPTH, ARRAYED, MULTISAMPLED, SAMPLED, FORMAT>

That's definitely better, but the trait can't really explain itself and its connection to the types (i.e. "Image types support query_levels only if such and such parameters have these values" etc.).

Except, in core/std, traits can and very much do do this, using #[rustc_on_unimplemented]!

It's perma-unstable, and there might be efforts to stabilize a subset of it, but even ignoring that, we can still use it under #[cfg_attr(target_arch = "spirv", ...)], just like all the other rustc internals we rely on.
t: enhancement
opened by eddyb 0
Allow using `MaybeUninit`

When using MaybeUninit to initialize variables one gets this issue: error: Cannot cast between pointer types. From: [u8; 256]. To: *struct core::mem::ManuallyDrop<[Vec4; 16]> { value: [f32x4; 16] }.

Would be nice to allow, if possible, as it's often unnecessary to initialize variables in shaders and adds additional overhead.
t: enhancement

opened by NiklasNummelin 1
Make sure the docs.rs build of `spirv-builder` doesn't build `rustc_codegen_spirv`

Currently, the docs.rs build for spirv-builder fails: https://docs.rs/crate/spirv-builder/0.4.0-alpha.17/builds/667359. This is because docs.rs builds using their nightly version, which is incompatible with rustc_codegen_spirv.

We can't do much for rustc_codegen_spirv (besides stripping code for doc builds), but we can remove spirv-builder's dependency on rustc_codegen_spirv specifically for doc.rs builds to make it succeed.
a: documentation

opened by oisyn 0
We should replace `rustc_codegen_spirv::linker::test` unit tests with compiletest ones.
The main unique aspect of these tests is they take SPIR-V assembly as an input, not Rust code, e.g.: https://github.com/EmbarkStudios/rust-gpu/blob/acb05d379982f35e6d4fbd85ff28af3e9876cf4c/crates/rustc_codegen_spirv/src/linker/test.rs#L185-L202

However, we might be able to use module_asm! to feed SPIR-V assembly into the compilation, and compiletest does have the ability to introduce dependencies to link against. The main weirdness we might need to deal with is all the definitions from e.g. core that we don't use, but DCE might be able to clean that up.

(Or we could even use e.g. extern "C" FFI in Rust code to describe such situations without module_asm! at all!)

If we can do this transition, we wouldn't have to deal with weird artificial compiler sessions and e.g.:

#956

t: enhancement a: test
opened by eddyb 0
Minor Bug: Misleading error message when compile succeeds but no *.spv was found
If you compile a crate with rust-gpu but forget to add

[lib] crate-type = ["lib", "dylib"]

in it's cargo.toml rust-gpu will error out with: Artifact created when compilation succeeded. This Error is outright wrong: What actually happened is that compilation succeeded but NO *.spv artifact was found.

The error is thrown in crates/spirv-builder/src/lib.rs line 538, at the end of the invoke_rustc() method. I'd like to suggest replacing this message with Compilation succeeded but no .spv Artifact was created! Make sure the crate-type includes \"dylib\".
t: enhancement
opened by Firestar99 1

Releases(v0.4.0)

v0.4.0(Dec 21, 2022)
^{Screenshot from Embark's Creative Playground, which uses rust-gpu and raytracing.}

Hi there! It's been long overdue, but it's finally here: the fourth release of rust-gpu! Our project aimed at making Rust a first class language and ecosystem for GPU programming. You can read more about why we at Embark started this project in the original announcement.

With this release, all relevant crates have been published to crates.io. In fact, this has been the case since 0.4.0-alpha.13, released last August. So you no longer have to refer to our github to pull in rust-gpu, and can instead directly refer to spirv-std and spirv-builder by version! What hasn't changed, though, is that you still need to build your shaders using a specific nightly toolchain of Rust. For rust-gpu 0.4.0, this will be nightly-2022-10-29. We do produce a user friendly error message when the toolchain you're building with does not exactly match the version required for rust-gpu.

It has been a while since we published a proper release, and going forward we'd like to do better. We intend to keep rust-gpu on the same schedule as the stable Rust release, so you can use your favorite new language features as new stable versions of Rust are being released, by just updating your rust-gpu version. As of right now, rust-gpu uses a Rust nightly that is equivalent to Rust 1.66, and you can expect a new release on or around the 26th of January, 2023, when Rust 1.67 is planned to be released.

A lot has changed since v0.3, too much to summarize in these release notes. However, we have started to track our changes in a changelog and have even retroactively listing all changes since the first release :slightly_smiling_face:. We'll try our best to feature some of the hightlights here, but please refer to the changelog for a more detailed accounting.

There is one thing we want to highlight in particular: rust-gpu now supports ray-tracing. Using #[spirv(..)] attributes, you can define entry points for various raytracing events: intersection, any_hit, closest_hit, and miss. The #[spirv(ray_generation)] can be used to define a ray generation shader. We still lack proper examples in our codebase, but for now we can refer you to the spirv_std::ray_tracing documentation. The code example below shows a somewhat stripped down shader that is used to generate the shadows in above screenshot.

Show ray-tracing code example

pub struct ShadowPayload { shadowed: u32, } pub fn trace_shadow_ray( acceleration_structure: &AccelerationStructure, mut ray_desc: RayDesc, payload: &mut ShadowPayload, ) -> bool { payload.shadowed = 1; unsafe { // see documentation of `spirv_std::ray_tracing::AccelerationStructure` on what these values mean acceleration_structure.trace_ray( RayFlags::SKIP_CLOSEST_HIT_SHADER, // ray flags !0, // cull mask 0, // shader binding table offset 0, // shader binding table stride 0, // miss index origin, // ray origin 0.0, // tmin direction, // ray direction f32::MAX, // tmax payload, // payload ); } payload.shadowed != 0 } #[spirv(miss)] pub fn miss(#[spirv(incoming_ray_payload)] payload: &mut ShadowPayload) { payload.shadowed = 0; } #[spirv(ray_generation)] pub fn raygen( #[spirv(descriptor_set = 0, binding = 0)] output_tex: &Image!(2D, format=rgba16f, sampled=false), #[spirv(descriptor_set = 1, binding = 0)] acceleration_structure: &AccelerationStructure, #[spirv(ray_payload)] payload: &mut ShadowPayload, ) { let ray_origin = /* calculate ray origin */; let ray_dir = /* calculate ray dir */; let shadowed = trace_shadow_ray( acceleration_structure, ray_origin, ray_dir, payload, ); unsafe { output_tex.write(px, if shadowed { Vec3::ZERO } else { Vec3::ONE }); } }

Language and code generation changes

Updated toolchain to nightly-2022-10-29.

Changed the way the #[spirv(..)] attribute works, because of the removal of register_attr support in Rust. You now need the spirv macro attribute to be globally visible by doing:
use spirv_std::spirv;

See also this migration guide for more information. PR#926

Replaced spirv_std::storage_class "named pointer types" with #[spirv(...)] &T entry-point parameters. (PR#443). This means you can now use the following code:
#[spirv(fragment)] pub fn main( #[spirv(frag_coord)] in_frag_coord: &Vec4, // instead of: #[spirv(frag_coord)] in_frag_coord: Input<Vec4>, output: &mut Vec4, // instead of: mut output: Output<Vec4>, ) { // ... }

Added basic support for unsized structs (e.g. ending with a [T] field). PR#504

Removed the need to manually specify the storage class for Image/Sampler/ImageSampler entry-point parameters. PR#567

Added support for constant memory (&'static _ references), within the limits of SPIR-V. PR#586

Added #[spirv(subgroup_local_invocation_id)]. PR#848

Removed the fn/closure #[spirv(unroll_loops)] attribute. You can use #[spirv(unroll)] on individual code blocks instead. PR#946

This release includes an experimental new shader IR framework called SPIR-🇹, which will ultimately help us in generating better SPIR-V code. This library is opt-in, see here how to enable it. Again, experimental, use at own risk. PR#940

API changes

spirv-std

Added a const-generic Image type, and Image! macro wrapping it. PR#359.
#[spirv(fragment)] pub fn main( #[spirv(descriptor_set = 0, binding = 0)] image: &Image!(2D, type=f32, sampled), #[spirv(descriptor_set = 1, binding = 1)] image_array: &Image!(2D, type=f32, arrayed, sampled), #[spirv(descriptor_set = 2, binding = 2)] cubemap: &Image!(cube, type=f32, sampled), #[spirv(descriptor_set = 3, binding = 3)] sampler: &Sampler, output: &mut f32, ) { let v2 = glam::Vec2::new(0.0, 1.0); let v3 = glam::Vec3A::new(0.0, 0.0, 1.0); *output = image.sample_depth_reference(*sampler, v2, 1.0); *output += image_array.sample_depth_reference(*sampler, v3, 1.0); *output += cubemap.sample_depth_reference(*sampler, v3, 1.0); }

As you might have noticed from above example, cubemaps are now supported as well. PR#521

Float packing/unpacking operations. PR#709

Lots of other new APIs Image: Image::gather/Image::sample_bias^#704, Image::query_*^#608, Image::read_subpass^#643, Image::sample_by_lod/Image::sample_by_gradient^#498, Image::fetch^#480 arch: arch::read_clock_khr^#757, arch::{signed,unsigned}_{min,max}^#763, arch::*memory_barrier*^#769, arch::IndexUnchecked^#805, arch::atomic_i_increment^#839, arch::atomic^#877 Misc: ByteAddressableBuffer^#735, SampledImage::sample_by_lod^#755, debug_printf!^#768, RayQuery::confirm_intersection^#822, is_helper_invocation^#612, memory_barrier/control_barrier^#519

spirv-builder

You can now have multiple SPIR-V modules, one per entry point. PR#551

SpirvBuilder now supports the ability to set a Rust "target triple" (e.g. "spirv-unknown-vulkan1.1" for Vulkan 1.1). PR#559

Added the ability to query entry-point names. PR#622

We now verify the build toolchain with the expected toolchain for rust-gpu, by checking the commit hash of rustc. It needs to match exactly. PR#919. Can be overridden by defining the environment variable RUSTGPU_SKIP_TOOLCHAIN_CHECK. PR#935.

You can now customize rustc invocation parameters using the environment variables RUSTGPU_RUSTFLAGS="..." and RUSTGPU_CODEGEN_ARGS="...". See documentation for more information. PR#959

Contributors

Thank you to all the contributors who helped make this release possible! :tada:

@8picoz, @andrusha, @anirudh24seven, @BeastLe9enD, @bjorn3, @bnjbvr, @Cactice, @ColeSeverson, @DeanBDean, @DJMcNab, @dvc94ch, @eddyb, @ElectronicRU, @emilk, @evopen, @expenses, @follower, @fu5ha, @hannes-vernooij, @haraldreingruber-dedalus, @hatoo, @Hentropy, @hrydgard, @Jake-Shadle, @Jasper-Bekkers, @khyperia, @MarijnS95, @molikto, @msiglreith, @oisyn, @PrototypeNM1, @RDambrosio016, @repi, @TrueDoctor, @urholaukkarinen, @vladinator1000, @XAMPPRocky
Source code(tar.gz)
Source code(zip)
v0.3.0(Mar 4, 2021)
The Khronos Sci-Fi helmet model. glTF model viewer created by @msiglreith using rust-gpu (Source)

Hello everyone, and welcome to the third release of rust-gpu! Our project aimed at making Rust a first class language and ecosystem for GPU programming. You can read more about why we at Embark started this project in the original announcement.

We're still not publishing releases to crates.io or distributing artefacts for rust-gpu, but we still wanted to highlight some of the changes that have been happening over the past couple of months. For more information on how to get started with using rust-gpu in your projects, be sure to check out the Rust-GPU Dev Guide! You can always add a git dependency in cargo to access spirv-builder.

[build-dependencies] spirv-builder = { git = "https://github.com/EmbarkStudios/rust-gpu.git", branch = "main" }

While not a user facing feature, we are also proud to announce that we've also reached an important internal milestone in rust-gpu. We've now completely rewritten our GLSL shaders in our internal Ark project with Rust thanks to the improvements in this release! 🎉

rustc_codegen_spirv

The biggest change to rust-gpu is the added ability to infer storage class types. This removes the need to call .load/.store on the storage class types, and allows you to use Deref/DerefMut to manipulate the inner type directly. This a huge improvement rust-gpu ergonomics, as well leading to more efficient code being generated with the removal of unneeded OpLoads and OpStores when using large types.
use spirv_std::{glam::{Vec4, vec2}, storage_class::{Input, Output}}; #[spirv(fragment)] pub fn main_fs( #[spirv(frag_coord)] in_frag_coord: Input<Vec4>, mut output: Output<Vec4>, ) { // Before let frag_coord = frag_coord.load(); output.store(black_box(vec2(frag_coord.x, frag_coord.y))); // Now *output = black_box(vec2(in_frag_coord.x, in_frag_coord.y)); }

Initial support for Algebraic Data Type enums (e.g. Option<T>) has been added. This support is initially only provided for enums which have all scalar values in each variants (integers, floats, booleans). So for example Option<u32> works, but Option<Struct> doesn't work at the moment.

You no longer need add #[allow(unused_attributes)] in front of #[spirv] attributes to remove warnings.

You can now provide const arguments to asm!.

rustc_codegen_spirv will now remove different OpNames that target the same ID. This should reduce the size of the generated SPIR-V binaries.

rustc_codegen_spirv will now try to deduplicate generated OpVariables. This fixes certain issues with compiling rust-gpu SPIR-V on Android platforms.

You can now set entry_point_name in entry point attributes to change the final name of an entry point. E.g. #[spirv(vertex(entry_point_name = "foo_bar"))]

You can now add the #[spirv(unroll_loops)] attribute to functions, which tells rustc_codegen_spirv to annotate all loops inside with Unroll.

spirv-std

Added a new arch module which provides an abstraction some basic SPIR-V instructions as free functions. The first iteration includes two functions.

vector_extract_dynamic (OpVectorExtractDynamic)

vector_insert_dynamic (OpVectorInsertDynamic)

Added textures::StorageImage2d which is an image designed be read/written to without a Sampler.

Added the spirv-std-macros crate for holding the spirv proc macro which acts as dummy macro to allow to use the spirv attribute on CPU code (has no affect on CPU code).

Added the gpu_only proc macro, which allows you to mark a function as only runnable on GPU, it will still generate a callable function on the CPU side, but it will cause a panic when called.

Added discard and demote_to_helper_invocation functions. Which correspond to discard in GLSL and HLSL respectively.

Derivative is now implemented for glam::{Vec2, Vec3, Vec3A, Vec4}.

Added the SampledImage type, which is an image already combined with a sampler.

spirv-builder

You can now build your shaders in release mode with --release or with SpirvBuilder::release

If you're using spirv-builder in your build script, you can add the following to your Cargo.toml to improve build times.
[profile.dev.build-override] opt-level = 3 [profile.release.build-override] opt-level = 3

Contributors

Thank you to all the contributors who helped make this release possible! 🎉

@AidanConnelly

@AnIrishDuck

@adrianisuru

@DGriffin91

@DeanBDean

@eddyb

@Hentropy

@khyperia

@Jake-Shadle

@Jasper-Bekkers

@lcnr

@lpil

@msiglreith

@repi

@VZout

@XAMPPRocky

@zicklag

Source code(tar.gz)
Source code(zip)
v0.2(Dec 4, 2020)
Created by @bcata6 using rust-gpu (Rust source) with shaders originally from https://shadertoy.com/

Hello everyone, and welcome to the second release of rust-gpu! Our project aimed at making Rust a first class language and ecosystem for GPU programming. You can read more about why we at Embark started this project in the original announcement.

First of all we'd like to welcome @eddyb, who will be working as a collaborator with the rust-gpu team on the compiler backend, and has already been contributing a lot of improvements to rust-gpu!

We're still not really cutting releases for rust-gpu, but we wanted to highlight some of the changes that have been happening over the past month. For more information on how to get started with using it in your projects, be sure to check out the new Rust-GPU Dev Guide!

Community

SHADERed, an IDE designed for building shaders have released a plugin and added support for running rust-gpu in SHADERed lite, their in-browser editor. Now you can to write Rust shaders on the web and in an IDE! Check out their blog post for more details on the new features.

SPIR-V Backend

We've added a new structurizer, which means that you can now use match expressions and continues!

Added the #[spirv(flat)] attribute that matches SPIR-V's "Flat" decorator.

Textures are now supported. You can now use the GPU's image memory to sample and manipulate textures.

Panicking code is now supported.

Added support for SPIR-V 1.0.

You can now use procedural macros, such as the unroll crate in your shaders.

We've also made some improvements to error messages about constant pointers.

Thanks to a community contribution we now also have initial support for compute shaders. Though support is still pretty bare bones for now this is an important start towards supporting different shaders in rust-gpu.

Added initial support in Rust and rust-gpu for inline SPIR-V with the asm! nightly feature. You can now write inline SPIR-V in your Rust code (example below). This is an important step towards implementing a lot of functionality around SPIR-V's features, such as the aforementioned new texture support.
asm! { "%typeSampledImage = OpTypeSampledImage typeof*{1}", "%image = OpLoad typeof*{1} {1}", "%sampler = OpLoad typeof*{2} {2}", "%coord = OpLoad typeof*{3} {3}", "%sampledImage = OpSampledImage %typeSampledImage %image %sampler", "%result = OpImageSampleImplicitLod typeof*{0} %sampledImage %coord", "OpStore {0} %result", in(reg) &mut result, in(reg) &image, in(reg) &sampler, in(reg) &coord }

spirv-std

All Storage Classes (e.g. Input/Output) are now defined in spirv_std::storage_class.

Rust's language items such rust_eh_personality and panic_handler are now defined in spirv-std for SPIR-V targets. This reduces the amount of boilerplate code you need in your shader, and helps spirv-std feel a bit more like std. You can still define your own language items by disabling the lang_items feature.

Misc

rust-gpu now has testing support for building on Android. You can now also run the WGPU example on Android devices to test out your shaders.

Contributors

Thank you to all the contributors who helped make this release possible! 🎉

@DJMcNab

@DhruvDh

@Hentropy

@Jake-Shadle

@Jasper-Bekkers

@MarijnS95

@VZout

@XAMPPRocky

@bjorn3

@charles-r-earp

@eddyb

@expenses

@grovesNL

@khyperia

@lpil

@meowjesty

@msiglreith

@nipunG314

@nolanderc

@repi

@soniasingla

@termhn

Source code(tar.gz)
Source code(zip)
v0.1(Oct 22, 2020)
Today, we're releasing a very early version of rust-gpu - a new project to make Rust a first-class language and ecosystem for GPU code!

GPU programming has historically been done with HLSL or GLSL, simple programming languages that have evolved along with rendering APIs over the years. However, as game engines have evolved, these languages have failed to provide mechanisms for dealing with large codebases, and have generally stayed behind the curve compared to other programming languages.

Our hope with this project is that we push the industry forward by bringing Rust, an existing low-level, safe, and high performance language, to the GPU. And with it come some additional great benefits: a package/module system that's one of the industry's best, built in safety against race-conditions or out of bounds memory access, a wide range of libraries and tools to improve programmer workflows, and many others!

If we do this project right, developers could use open-source crates that provide the graphical effects needed to create beautiful experiences. Instead of sharing snippets of code on forum posts, they could simply add the right crates.

Why Embark?

At Embark, we've been building our own new game engine from the ground up in Rust. We have previous experience in-house developing the RLSL prototype, and we have a team of excellent rendering engineers that are familiar with the problems in current shading languages both from games, game engines and other industries. So, we believe we are uniquely positioned to attempt solving this problem.

We want to streamline our own internal development with a single great language, build an open source graphics ecosystem and community, facilitate code-sharing between GPU and CPU, and most importantly: to enable our (future) users, and fellow developers, to more rapidly build great looking and engaging experiences.

Who are we?

Leading the project:

@khyperia - compiler engineer with experience from Microsoft & Mozilla

@Jasper-Bekkers - rendering engineer with experience from Frostbite & SEED, and head of Traverse Research

@XAMPPRocky & @arirawr, will be helping to manage the open development of the project.

@VZout, @repi, @MaikKlein, @h3r2tic, @hrydgard, @emilk, @NiklasNummelin - devs that will try to write all their shaders in Rust!

But we can't do this alone. That's why we've decided to develop this project in the open,alongside the rest of the Rust and graphics programming communities. Please connect with us if you are interested in collaborating

Current Status

Compiling and running very simple graphics shaders works, and a significant portion of the core library also compiles.

With this we've been able to create some first real shaders in Rust, such as this sky shader written (source):

However, many things aren't implemented yet: for example, loops and switches aren't supported yet!

That means that while being technically usable, this project is far from being production-ready.

Project Scope

The scope of this overall project is quite broad, but is in multiple stages

rustc compiler backend to generate SPIR-V, plugging in via -Z codegen-backend.

This is the same mechanism that rustc_codegen_cranelift and rustc_codegen_gcc use.

Currently only SPIR-V support is planned, Vulkan's open compiler target

Possible a future version could suppport DXIL (the target for DirectX) or WGSL (the WebGPU shading language that's bijective with SPIR-V)

Focus on Vulkan graphics shaders first, then after Vulkan compute shaders

Cargo and crates.io support to develop and publish SPIR-V crates

High-level render graph to take advantage of this, make it easy for users to develop and use rendering effects.

An in-depth exploration of our roadmap and milestones can be found here.

Open Development

We'll have weekly meetings on Discord, with open agendas shared in GitHub issues. RFCs and other discussions will also be handled in GitHub.

Want to get started?

Join us on Discord to discuss and share your ideas on this project

Check out our Roadmap and Milestones

Read about the project's scope

Get started and run our example shader

See our open issues

Source code(tar.gz)
Source code(zip)