1665388695
Rust Embedded HAL for Apache NuttX RTOS
Rust Embedded HAL for Apache NuttX RTOS
This crate provides Rust Embedded HAL interfaces (GPIO, I2C, SPI and Delay) for Apache NuttX RTOS.
For sample NuttX Rust apps, see rust-i2c-nuttx and rust_test
If you find this crate useful, please support me on GitHub Sponsors
More about NuttX Embedded HAL...
"Rust talks I2C on Apache NuttX RTOS"
GPIO Output
// Import Output Pin Trait
use embedded_hal::digital::v2::OutputPin;
// Open /dev/gpio1 for GPIO Output
let mut gpio = nuttx_embedded_hal::OutputPin
::new("/dev/gpio1")
.expect("open gpio failed");
// Set Chip Select to Low
gpio.set_low()
.expect("set gpio failed");
// Set Chip Select to High
gpio.set_high()
.expect("set gpio failed");
GPIO Input
// Import Input Pin Trait
use embedded_hal::digital::v2::InputPin;
// Open /dev/gpio0 for GPIO Input
let gpio = nuttx_embedded_hal::InputPin
::new("/dev/gpio0")
.expect("open gpio failed");
// True if GPIO is High
let is_high = gpio.is_high()
.expect("read gpio failed");
// True if GPIO is Low
let is_low = gpio.is_low()
.expect("read gpio failed");
GPIO Interrupt
Interrupt callbacks are not supported yet.
// Import Input Pin Trait
use embedded_hal::digital::v2::InputPin;
// Open /dev/gpio2 for GPIO Interrupt
let gpio = nuttx_hal::InterruptPin
::new("/dev/gpio2");
.expect("open gpio failed");
// True if GPIO is High
let is_high = gpio.is_high()
.expect("read gpio failed");
// True if GPIO is Low
let is_low = gpio.is_low()
.expect("read gpio failed");
I2C
// Import I2C Trait
use embedded_hal::blocking::i2c;
// Open I2C Port /dev/i2c0
let mut i2c = nuttx_embedded_hal::I2c::new(
"/dev/i2c0", // I2C Port
400000, // I2C Frequency: 400 kHz
).expect("open failed");
// Buffer for received I2C data
let mut buf = [0 ; 1];
// Read register 0xD0 from I2C Address 0x77
i2c.write_read(
0x77, // I2C Address
&[0xD0], // Register ID
&mut buf // Buffer to be received
).expect("read register failed");
// Print the register value
println!("Register value is 0x{:02x}", buf[0]);
// Write 0xA0 to Register 0xF5
i2c.write(
0x77, // I2C Address
&[0xF5, 0xA0] // Register ID and value
).expect("write register failed");
SPI
The SPI interface requires the SPI Test Driver (/dev/spitest0) to be installed:
SPI settings are configured in the SPI Test Driver.
// Import SPI Trait
use embedded_hal::blocking::spi;
// Open SPI Bus /dev/spitest0
let mut spi = nuttx_embedded_hal::Spi
::new("/dev/spitest0")
.expect("open spi failed");
// Open GPIO Output /dev/gpio1 for Chip Select
let mut cs = nuttx_embedded_hal::OutputPin
::new("/dev/gpio1")
.expect("open gpio failed");
// Set Chip Select to Low
cs.set_low()
.expect("cs failed");
// Transmit and receive SPI data
let mut data: [ u8; 5 ] = [ 0x1d, 0x00, 0x08, 0x00, 0x00 ];
spi.transfer(&mut data)
.expect("spi failed");
// Show the received SPI data
for i in 0..data.len() {
println!("{:02x}", data[i as usize]);
}
// Set Chip Select to High
cs.set_high()
.expect("cs failed");
Delay
// Import Delay Trait (milliseconds)
use embedded_hal::blocking::delay::DelayMs;
// Get a Delay Interface
let mut delay = nuttx_embedded_hal::Delay;
// Wait 500 milliseconds
delay.delay_ms(500_u32);
Download Details:
Author: lupyuen
Source Code: https://github.com/lupyuen/nuttx-embedded-hal
License: Apache-2.0 license
What is GEEK
Buddha Community
1643176207
Serde Rust: Serialization Framework for Rust
Serde
*Serde is a framework for serializing and deserializing Rust data structures efficiently and generically.*
You may be looking for:
- An overview of Serde
- Data formats supported by Serde
- Setting up
#[derive(Serialize, Deserialize)] - Examples
- API documentation
- Release notes
Serde in action
Click to show Cargo.toml. Run this code in the playground.
[dependencies]
# The core APIs, including the Serialize and Deserialize traits. Always
# required when using Serde. The "derive" feature is only required when
# using #[derive(Serialize, Deserialize)] to make Serde work with structs
# and enums defined in your crate.
serde = { version = "1.0", features = ["derive"] }
# Each data format lives in its own crate; the sample code below uses JSON
# but you may be using a different one.
serde_json = "1.0"
use serde::{Serialize, Deserialize};
#[derive(Serialize, Deserialize, Debug)]
struct Point {
x: i32,
y: i32,
}
fn main() {
let point = Point { x: 1, y: 2 };
// Convert the Point to a JSON string.
let serialized = serde_json::to_string(&point).unwrap();
// Prints serialized = {"x":1,"y":2}
println!("serialized = {}", serialized);
// Convert the JSON string back to a Point.
let deserialized: Point = serde_json::from_str(&serialized).unwrap();
// Prints deserialized = Point { x: 1, y: 2 }
println!("deserialized = {:?}", deserialized);
}
Getting help
Serde is one of the most widely used Rust libraries so any place that Rustaceans congregate will be able to help you out. For chat, consider trying the #rust-questions or #rust-beginners channels of the unofficial community Discord (invite: https://discord.gg/rust-lang-community), the #rust-usage or #beginners channels of the official Rust Project Discord (invite: https://discord.gg/rust-lang), or the #general stream in Zulip. For asynchronous, consider the [rust] tag on StackOverflow, the /r/rust subreddit which has a pinned weekly easy questions post, or the Rust Discourse forum. It's acceptable to file a support issue in this repo but they tend not to get as many eyes as any of the above and may get closed without a response after some time.
Download Details:
Author: serde-rs
Source Code: https://github.com/serde-rs/serde
License: View license
1665388695
Rust Embedded HAL for Apache NuttX RTOS
Rust Embedded HAL for Apache NuttX RTOS
This crate provides Rust Embedded HAL interfaces (GPIO, I2C, SPI and Delay) for Apache NuttX RTOS.
For sample NuttX Rust apps, see rust-i2c-nuttx and rust_test
If you find this crate useful, please support me on GitHub Sponsors
More about NuttX Embedded HAL...
"Rust talks I2C on Apache NuttX RTOS"
GPIO Output
// Import Output Pin Trait
use embedded_hal::digital::v2::OutputPin;
// Open /dev/gpio1 for GPIO Output
let mut gpio = nuttx_embedded_hal::OutputPin
::new("/dev/gpio1")
.expect("open gpio failed");
// Set Chip Select to Low
gpio.set_low()
.expect("set gpio failed");
// Set Chip Select to High
gpio.set_high()
.expect("set gpio failed");
GPIO Input
// Import Input Pin Trait
use embedded_hal::digital::v2::InputPin;
// Open /dev/gpio0 for GPIO Input
let gpio = nuttx_embedded_hal::InputPin
::new("/dev/gpio0")
.expect("open gpio failed");
// True if GPIO is High
let is_high = gpio.is_high()
.expect("read gpio failed");
// True if GPIO is Low
let is_low = gpio.is_low()
.expect("read gpio failed");
GPIO Interrupt
Interrupt callbacks are not supported yet.
// Import Input Pin Trait
use embedded_hal::digital::v2::InputPin;
// Open /dev/gpio2 for GPIO Interrupt
let gpio = nuttx_hal::InterruptPin
::new("/dev/gpio2");
.expect("open gpio failed");
// True if GPIO is High
let is_high = gpio.is_high()
.expect("read gpio failed");
// True if GPIO is Low
let is_low = gpio.is_low()
.expect("read gpio failed");
I2C
// Import I2C Trait
use embedded_hal::blocking::i2c;
// Open I2C Port /dev/i2c0
let mut i2c = nuttx_embedded_hal::I2c::new(
"/dev/i2c0", // I2C Port
400000, // I2C Frequency: 400 kHz
).expect("open failed");
// Buffer for received I2C data
let mut buf = [0 ; 1];
// Read register 0xD0 from I2C Address 0x77
i2c.write_read(
0x77, // I2C Address
&[0xD0], // Register ID
&mut buf // Buffer to be received
).expect("read register failed");
// Print the register value
println!("Register value is 0x{:02x}", buf[0]);
// Write 0xA0 to Register 0xF5
i2c.write(
0x77, // I2C Address
&[0xF5, 0xA0] // Register ID and value
).expect("write register failed");
SPI
The SPI interface requires the SPI Test Driver (/dev/spitest0) to be installed:
SPI settings are configured in the SPI Test Driver.
// Import SPI Trait
use embedded_hal::blocking::spi;
// Open SPI Bus /dev/spitest0
let mut spi = nuttx_embedded_hal::Spi
::new("/dev/spitest0")
.expect("open spi failed");
// Open GPIO Output /dev/gpio1 for Chip Select
let mut cs = nuttx_embedded_hal::OutputPin
::new("/dev/gpio1")
.expect("open gpio failed");
// Set Chip Select to Low
cs.set_low()
.expect("cs failed");
// Transmit and receive SPI data
let mut data: [ u8; 5 ] = [ 0x1d, 0x00, 0x08, 0x00, 0x00 ];
spi.transfer(&mut data)
.expect("spi failed");
// Show the received SPI data
for i in 0..data.len() {
println!("{:02x}", data[i as usize]);
}
// Set Chip Select to High
cs.set_high()
.expect("cs failed");
Delay
// Import Delay Trait (milliseconds)
use embedded_hal::blocking::delay::DelayMs;
// Get a Delay Interface
let mut delay = nuttx_embedded_hal::Delay;
// Wait 500 milliseconds
delay.delay_ms(500_u32);
Download Details:
Author: lupyuen
Source Code: https://github.com/lupyuen/nuttx-embedded-hal
License: Apache-2.0 license
1654894080
Serde JSON: JSON Support for Serde Framework
Serde JSON
Serde is a framework for serializing and deserializing Rust data structures efficiently and generically.
[dependencies]
serde_json = "1.0"
You may be looking for:
- JSON API documentation
- Serde API documentation
- Detailed documentation about Serde
- Setting up
#[derive(Serialize, Deserialize)] - Release notes
JSON is a ubiquitous open-standard format that uses human-readable text to transmit data objects consisting of key-value pairs.
{
"name": "John Doe",
"age": 43,
"address": {
"street": "10 Downing Street",
"city": "London"
},
"phones": [
"+44 1234567",
"+44 2345678"
]
}
There are three common ways that you might find yourself needing to work with JSON data in Rust.
- As text data. An unprocessed string of JSON data that you receive on an HTTP endpoint, read from a file, or prepare to send to a remote server.
- As an untyped or loosely typed representation. Maybe you want to check that some JSON data is valid before passing it on, but without knowing the structure of what it contains. Or you want to do very basic manipulations like insert a key in a particular spot.
- As a strongly typed Rust data structure. When you expect all or most of your data to conform to a particular structure and want to get real work done without JSON's loosey-goosey nature tripping you up.
Serde JSON provides efficient, flexible, safe ways of converting data between each of these representations.
Operating on untyped JSON values
Any valid JSON data can be manipulated in the following recursive enum representation. This data structure is serde_json::Value.
enum Value {
Null,
Bool(bool),
Number(Number),
String(String),
Array(Vec<Value>),
Object(Map<String, Value>),
}
A string of JSON data can be parsed into a serde_json::Value by the serde_json::from_str function. There is also from_slice for parsing from a byte slice &[u8] and from_reader for parsing from any io::Read like a File or a TCP stream.
use serde_json::{Result, Value};
fn untyped_example() -> Result<()> {
// Some JSON input data as a &str. Maybe this comes from the user.
let data = r#"
{
"name": "John Doe",
"age": 43,
"phones": [
"+44 1234567",
"+44 2345678"
]
}"#;
// Parse the string of data into serde_json::Value.
let v: Value = serde_json::from_str(data)?;
// Access parts of the data by indexing with square brackets.
println!("Please call {} at the number {}", v["name"], v["phones"][0]);
Ok(())
}
The result of square bracket indexing like v["name"] is a borrow of the data at that index, so the type is &Value. A JSON map can be indexed with string keys, while a JSON array can be indexed with integer keys. If the type of the data is not right for the type with which it is being indexed, or if a map does not contain the key being indexed, or if the index into a vector is out of bounds, the returned element is Value::Null.
When a Value is printed, it is printed as a JSON string. So in the code above, the output looks like Please call "John Doe" at the number "+44 1234567". The quotation marks appear because v["name"] is a &Value containing a JSON string and its JSON representation is "John Doe". Printing as a plain string without quotation marks involves converting from a JSON string to a Rust string with as_str() or avoiding the use of Value as described in the following section.
The Value representation is sufficient for very basic tasks but can be tedious to work with for anything more significant. Error handling is verbose to implement correctly, for example imagine trying to detect the presence of unrecognized fields in the input data. The compiler is powerless to help you when you make a mistake, for example imagine typoing v["name"] as v["nmae"] in one of the dozens of places it is used in your code.
Parsing JSON as strongly typed data structures
Serde provides a powerful way of mapping JSON data into Rust data structures largely automatically.
use serde::{Deserialize, Serialize};
use serde_json::Result;
#[derive(Serialize, Deserialize)]
struct Person {
name: String,
age: u8,
phones: Vec<String>,
}
fn typed_example() -> Result<()> {
// Some JSON input data as a &str. Maybe this comes from the user.
let data = r#"
{
"name": "John Doe",
"age": 43,
"phones": [
"+44 1234567",
"+44 2345678"
]
}"#;
// Parse the string of data into a Person object. This is exactly the
// same function as the one that produced serde_json::Value above, but
// now we are asking it for a Person as output.
let p: Person = serde_json::from_str(data)?;
// Do things just like with any other Rust data structure.
println!("Please call {} at the number {}", p.name, p.phones[0]);
Ok(())
}
This is the same serde_json::from_str function as before, but this time we assign the return value to a variable of type Person so Serde will automatically interpret the input data as a Person and produce informative error messages if the layout does not conform to what a Person is expected to look like.
Any type that implements Serde's Deserialize trait can be deserialized this way. This includes built-in Rust standard library types like Vec<T> and HashMap<K, V>, as well as any structs or enums annotated with #[derive(Deserialize)].
Once we have p of type Person, our IDE and the Rust compiler can help us use it correctly like they do for any other Rust code. The IDE can autocomplete field names to prevent typos, which was impossible in the serde_json::Value representation. And the Rust compiler can check that when we write p.phones[0], then p.phones is guaranteed to be a Vec<String> so indexing into it makes sense and produces a String.
The necessary setup for using Serde's derive macros is explained on the Using derive page of the Serde site.
Constructing JSON values
Serde JSON provides a json! macro to build serde_json::Value objects with very natural JSON syntax.
use serde_json::json;
fn main() {
// The type of `john` is `serde_json::Value`
let john = json!({
"name": "John Doe",
"age": 43,
"phones": [
"+44 1234567",
"+44 2345678"
]
});
println!("first phone number: {}", john["phones"][0]);
// Convert to a string of JSON and print it out
println!("{}", john.to_string());
}
The Value::to_string() function converts a serde_json::Value into a String of JSON text.
One neat thing about the json! macro is that variables and expressions can be interpolated directly into the JSON value as you are building it. Serde will check at compile time that the value you are interpolating is able to be represented as JSON.
let full_name = "John Doe";
let age_last_year = 42;
// The type of `john` is `serde_json::Value`
let john = json!({
"name": full_name,
"age": age_last_year + 1,
"phones": [
format!("+44 {}", random_phone())
]
});
This is amazingly convenient, but we have the problem we had before with Value: the IDE and Rust compiler cannot help us if we get it wrong. Serde JSON provides a better way of serializing strongly-typed data structures into JSON text.
Creating JSON by serializing data structures
A data structure can be converted to a JSON string by serde_json::to_string. There is also serde_json::to_vec which serializes to a Vec<u8> and serde_json::to_writer which serializes to any io::Write such as a File or a TCP stream.
use serde::{Deserialize, Serialize};
use serde_json::Result;
#[derive(Serialize, Deserialize)]
struct Address {
street: String,
city: String,
}
fn print_an_address() -> Result<()> {
// Some data structure.
let address = Address {
street: "10 Downing Street".to_owned(),
city: "London".to_owned(),
};
// Serialize it to a JSON string.
let j = serde_json::to_string(&address)?;
// Print, write to a file, or send to an HTTP server.
println!("{}", j);
Ok(())
}
Any type that implements Serde's Serialize trait can be serialized this way. This includes built-in Rust standard library types like Vec<T> and HashMap<K, V>, as well as any structs or enums annotated with #[derive(Serialize)].
Performance
It is fast. You should expect in the ballpark of 500 to 1000 megabytes per second deserialization and 600 to 900 megabytes per second serialization, depending on the characteristics of your data. This is competitive with the fastest C and C++ JSON libraries or even 30% faster for many use cases. Benchmarks live in the serde-rs/json-benchmark repo.
Getting help
Serde is one of the most widely used Rust libraries, so any place that Rustaceans congregate will be able to help you out. For chat, consider trying the #rust-questions or #rust-beginners channels of the unofficial community Discord (invite: https://discord.gg/rust-lang-community), the #rust-usage or #beginners channels of the official Rust Project Discord (invite: https://discord.gg/rust-lang), or the #general stream in Zulip. For asynchronous, consider the [rust] tag on StackOverflow, the /r/rust subreddit which has a pinned weekly easy questions post, or the Rust Discourse forum. It's acceptable to file a support issue in this repo, but they tend not to get as many eyes as any of the above and may get closed without a response after some time.
No-std support
As long as there is a memory allocator, it is possible to use serde_json without the rest of the Rust standard library. This is supported on Rust 1.36+. Disable the default "std" feature and enable the "alloc" feature:
[dependencies]
serde_json = { version = "1.0", default-features = false, features = ["alloc"] }
For JSON support in Serde without a memory allocator, please see the serde-json-core crate.
1629837300
Rust Lang Course For Beginner In 2021: Guessing Game
What we learn in this chapter:
- Rust number types and their default
- First exposure to #Rust modules and the std::io module to read input from the terminal
- Rust Variable Shadowing
- Rust Loop keyword
- Rust if/else
- First exposure to #Rust match keyword
=== Content:
00:00 - Intro & Setup
02:11 - The Plan
03:04 - Variable Secret
04:03 - Number Types
05:45 - Mutability recap
06:22 - Ask the user
07:45 - First intro to module std::io
08:29 - Rust naming conventions
09:22 - Read user input io:stdin().read_line(&mut guess)
12:46 - Break & Understand
14:20 - Parse string to number
17:10 - Variable Shadowing
18:46 - If / Else - You Win, You Loose
19:28 - Loop
20:38 - Match
23:19 - Random with rand
26:35 - Run it all
27:09 - Conclusion and next episode
1684919280
Making Rust A First-class Language and Ecosystem for GPU Shaders
🐉 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
rustccompiler 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.
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.
Download Details:
Author: EmbarkStudios
Source Code: https://github.com/EmbarkStudios/rust-gpu
License: Apache-2.0, MIT licenses found