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

Overview

🐉 rust-gpu

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

Embark Discord Documentation dependency status Build status

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

Sky shader

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.
  • 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

Contributor Covenant

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

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

    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]

    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

    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

    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

    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.

    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

    1. Create a new blanket rust project with cargo new
    2. Copy the rust tool-chain file from git onto the root of the project
    3. Add [build-dependencies] spirv-builder = { git = "https://github.com/EmbarkStudios/rust-gpu" } to the toml file.
    4. 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

    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

    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

    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

    image

    opened by fu5ha 14
  • Add `debug_printf!` and `debug_printfln!` macros that uses the DebugPrintf extension

    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

    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.

    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`

    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`

    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.

    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

    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)

    image 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)

    A high res Sci-Fi helmet by @msiglreith

    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

    spirv-std

    spirv-builder

    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)

    image

    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

    spirv-std

    Misc

    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):

    Sky shader

    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.
    • 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?

    Source code(tar.gz)
    Source code(zip)
Owner
Embark
The future belongs to the curious
Embark
Ecosystem of libraries and tools for writing and executing fast GPU code fully in Rust.

The Rust CUDA Project An ecosystem of libraries and tools for writing and executing extremely fast GPU code fully in Rust Guide | Getting Started | Fe

Rust GPU 2.1k Dec 30, 2022
Toy library for neural networks in Rust using Vulkan compute shaders

descent Toy library for neural networks in Rust using Vulkan compute shaders. Features Multi-dimensional arrays backed by Vulkan device memory Use Rus

Simon Brown 71 Dec 16, 2022
Compile your WebAssembly programs into SPIR-V shaders

wasm2spirv - Compile your WebAssembly programs into SPIR-V shaders Warning wasm2spirv is still in early development, and not production ready. This re

Alex Andreba 18 Jul 25, 2023
A real-time implementation of "Ray Tracing in One Weekend" using nannou and rust-gpu.

Real-time Ray Tracing with nannou & rust-gpu An attempt at a real-time implementation of "Ray Tracing in One Weekend" by Peter Shirley. This was a per

null 89 Dec 23, 2022
Open deep learning compiler stack for cpu, gpu and specialized accelerators

Open Deep Learning Compiler Stack Documentation | Contributors | Community | Release Notes Apache TVM is a compiler stack for deep learning systems. I

The Apache Software Foundation 8.9k Jan 4, 2023
Rust based Cross-GPU Machine Learning

HAL : Hyper Adaptive Learning Rust based Cross-GPU Machine Learning. Why Rust? This project is for those that miss strongly typed compiled languages.

Jason Ramapuram 83 Dec 20, 2022
How to: Run Rust code on your NVIDIA GPU

Status This documentation about an unstable feature is UNMAINTAINED and was written over a year ago. Things may have drastically changed since then; r

null 343 Dec 22, 2022
A Demo server serving Bert through ONNX with GPU written in Rust with <3

Demo BERT ONNX server written in rust This demo showcase the use of onnxruntime-rs on BERT with a GPU on CUDA 11 served by actix-web and tokenized wit

Xavier Tao 28 Jan 1, 2023
Wonnx - a GPU-accelerated ONNX inference run-time written 100% in Rust, ready for the web

Wonnx is a GPU-accelerated ONNX inference run-time written 100% in Rust, ready for the web. Supported Platforms (enabled by wgpu) API Windows Linux &

WebONNX 354 Jan 6, 2023
A gpu accelerated (optional) neural network Rust crate.

Intricate A GPU accelerated library that creates/trains/runs neural networks in pure safe Rust code. Architechture overview Intricate has a layout ver

Gabriel Miranda 11 Dec 26, 2022
A repo for learning how to parallelize computations in the GPU using Apple's Metal, in Rust.

Metal playground in rust Made for learning how to parallelize computations in the GPU using Apple's Metal, in Rust, via the metal crate. Overview The

Lambdaclass 5 Feb 20, 2023
LLaMa 7b with CUDA acceleration implemented in rust. Minimal GPU memory needed!

LLaMa 7b in rust This repo contains the popular LLaMa 7b language model, fully implemented in the rust programming language! Uses dfdx tensors and CUD

Corey Lowman 16 May 8, 2023
A fun, hackable, GPU-accelerated, neural network library in Rust, written by an idiot

Tensorken: A Fun, Hackable, GPU-Accelerated, Neural Network library in Rust, Written by an Idiot (work in progress) Understanding deep learning from t

Kurt Schelfthout 44 May 6, 2023
Signed distance functions + Rust (CPU & GPU) = ❤️❤️

sdf-playground Signed distance functions + Rust (CPU & GPU) = ❤️❤️ Platforms: Windows, Mac & Linux. About sdf-playground is a demo showcasing how you

Patryk Wychowaniec 5 Nov 16, 2023
rust-gpu CLI driver

rust-gpu-driver Experiment to make rust-gpu more accessible as a GPU shading language in various projects. DISCLAIMER: This is an unstable experiment

Fredrik Fornwall 9 Feb 16, 2024
Open Machine Intelligence Framework for Hackers. (GPU/CPU)

Leaf • Introduction Leaf is a open Machine Learning Framework for hackers to build classical, deep or hybrid machine learning applications. It was ins

Autumn 5.5k Jan 1, 2023
Damavand is a quantum circuit simulator. It can run on laptops or High Performance Computing architectures, such CPU distributed architectures or multi GPU distributed architectures.

Damavand is a code that simulates quantum circuits. In order to learn more about damavand, refer to the documentation. Development status Core feature

prevision.io 6 Mar 29, 2022
A library implementing GPU-accelerated cryptographic functionality for the zkSync prover.

zkSync Era: A ZK Rollup For Scaling Ethereum zkSync Era is a layer 2 rollup that uses zero-knowledge proofs to scale Ethereum without compromising on

Matter Labs 3 Sep 24, 2023
An NVIDIA SMI'esk GPU Monitoring tool for your terminal.

NVTOP An NVIDIA SMI'esk GPU Monitoring tool for your terminal. art by stable-diffusion + Maz Contents: usage prerequisites installation why troublesho

Jer 17 Oct 14, 2023