grovesnl/spirv_cross

Safe wrapper around SPIR-V Cross

Safe wrapper around SPIRV-Cross for use with Rust

spirv_cross

Safe wrapper around SPIR-V Cross

Example

spirv_cross provides a safe wrapper around SPIRV-Cross for use with Rust. For example, here is a simple function to parse a SPIR-V module and compile it to HLSL and MSL:

extern crate spirv_cross;
use spirv_cross::{spirv, hlsl, msl, ErrorCode};

fn example(module: spirv::Module) -> Result<(), ErrorCode> {
    // Compile to HLSL
    let ast = spirv::Ast::<hlsl::Target>::parse(&module)?;
    println!("{}", ast.compile()?);

    // Compile to MSL
    let ast = spirv::Ast::<msl::Target>::parse(&module)?;
    println!("{}", ast.compile()?);

    Ok(())
}

License

This project is licensed under either of Apache License, Version 2.0 or MIT license, at your option.

Contribution

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

See CONTRIBUTING.md.

Issues

Collection of the latest Issues

grovesNL

grovesNL

Comment Icon0

In #170 bors failed to merge the PR because I ran out of credits on the new Travis CI plans. Let's remove Travis and AppVeyor and switch to GitHub Actions for everything.

tomaka

tomaka

Comment Icon1

This crate currently seems to use cfg(target_arch = "wasm32") in order to mean "the web". However, wasm32-wasi is meant to be an actual operating-system-like environment. The WASI SDK for example provides a clang toolchain that can compile C/C++ code. Trying to compiling this crate for wasm32-wasi yields errors about JsValue not being found.

I would suggest using target_os = "emscripten" rather than target_arch = "wasm32" for everything Emscripten-related, and treat target_os = "wasi" in a cross-platform manner.

l-x-u

l-x-u

type: bug
Comment Icon6

The spirv_cross build.rs sets the c++ compiler to use the c++14 standard. On POSIX systems this is fine, because those systems will simply implicitly include the POSIX standard as well. This is not the case on Windows while using GCC, however - it uses the strict c++14 standard. This does not include some key functions used by spirv_cross, namely strdup. Attempting to build a crate with spirv-cross as a dependency on x64 Windows 10 with GCC 9.10 results in the following laundry list of errors:

I do not have time at the moment to test, but I believe this can be fixed by telling the compiler to use std=gnu++11. This will include the relevant POSIX standard headers to enable strdup and friends to compile correctly. I will test this when I have time and respond back in this issue if I test a solution that works.

grovesNL

grovesNL

Comment Icon0

Now that clang supports WebAssembly directly, attempt to compile the C++ SPIRV-Cross library to WebAssembly using --target wasm32-unknown-unknown-wasm and avoid Emscripten.

If this is successful, investigate static linking the Rust and C++ portions together so we can remove the temporary workaround (moving data through JavaScript to call into Emscripten-wasm32 C++ from wasm32 Rust).

grovesNL

grovesNL

type: enhancement
Comment Icon0

Some functions (especially simple getter-like functions) could probably avoid returning a Result and simply return the type, because we don't actually expect exceptions to be thrown on the C++ side.

As well, reconsider ErrorCode. Perhaps a String is sufficient for these cases and we can avoid the enum altogether.

kvark

kvark

Comment Icon4

gfx-rs Metal backend stores the shader module in order to compile it with different options for different pipeline layouts (see https://github.com/gfx-rs/gfx/pull/1576). It would be great to store Ast instead of re-parsing it each time, and just provide a reference to CompilerOption at the spot where compilation is needed.

How about we remove set_compiler_options at all and make the Ast::compile(&self, &CompilerOptions) (notice &self)?

Information - Updated Aug 01, 2022

Stars: 70
Forks: 33
Issues: 9

A vector graphics renderer using OpenGL with a Rust &amp; C API

A Rust example can be found in examples/quickstart

A vector graphics renderer using OpenGL with a Rust &amp; C API

OpenGliderNetwork client for Rust based on actix

MIT license (LICENSE-MIT or

OpenGliderNetwork client for Rust based on actix

NET Core / WinForms application hosting an OpenGL triangle renderer written in Rust / Glutin

although it required a lot of TLC to get it to compile against the latest Glutin crate

NET Core / WinForms application hosting an OpenGL triangle renderer written in Rust / Glutin

space-invaders is an OpenGL-based emulator in Rust for the Space Invaders

space-invaders is an OpenGL-based emulator in Rust for the glfw-sys package (via the GLFW library

space-invaders is an OpenGL-based emulator in Rust for the Space Invaders

A game in rust to learn rust and some opengl

Still cargo run to run executable, this main program watches over changes in

A game in rust to learn rust and some opengl

A 3d rust game using OpenGl and Emscripten to build for the wasm32-unknown-emscripten

It can also run standalone, developed and tested on Linux but will

A 3d rust game using OpenGl and Emscripten to build for the wasm32-unknown-emscripten

A Rust adapter for the Khronos OpenCL API

A Rust adapter for the Khronos C API

A Rust adapter for the Khronos OpenCL API

Template: Rust + OpenGL + SDL2

This template should get you started using OpenGL in Rust

Template: Rust + OpenGL + SDL2

Rust OpenGL(RGL)

My first serious attempt at a game engine

Rust OpenGL(RGL)
Facebook Instagram Twitter GitHub Dribbble
Privacy