librashader

Mega Bezel SMOOTH-ADV

Mega Bezel SMOOTH-ADV on DirectX 11

librashader (/ˈli:brəʃeɪdɚ/) is a preprocessor, compiler, and runtime for RetroArch 'slang' shaders, rewritten in pure Rust.

Latest Version Docs License Nightly rust

Supported Render APIs

librashader supports OpenGL 3, OpenGL 4.6, Vulkan, Direct3D 11, and Direct3D 12. Metal and WebGPU are not currently supported (but pull-requests are welcome). librashader does not support legacy render APIs such as older versions of OpenGL, or legacy versions of Direct3D.

| API | Status | librashader feature | |-------------|------------|--------------------------| | OpenGL 3.3+ | ✔ | gl | | OpenGL 4.6 | ✔ | gl | | Vulkan | ✔ | vk | | Direct3D 11 | ✔ | d3d11 | | Direct3D 12 | ✔ | d3d12 | | Metal | ❌ | | | WebGPU | ❌ | |

✔ = Render API is supported — ❌ Render API is not supported

Usage

librashader provides both a Rust API under the librashader crate, and a C API. Both APIs are first-class and fully supported. The C API is geared more towards integration with existing projects. The Rust librashader crate exposes more of the internals if you wish to use parts of librashader piecemeal.

The librashader C API is best used by including librashader_ld.h in your project, which implements a loader that dynamically loads the librashader (librashader.so or librashader.dll) implementation in the search path.

Building

librashader requires the following build time dependencies


For Rust projects, simply add the crate to your Cargo.toml.

cargo add librashader

To build the C compatible dynamic library, run the build script.

cargo run -p librashader-build-script -- --profile optimized

This will output a librashader.dll or librashader.so in the target folder. Profile can be debug, release, or optimized for full LTO.

C ABI Compatibility

As the recommended way of integrating librashader is by the librashader_ld single header library, ABI stability is important to ensure that updates to librashader do not break existing consumers.

As of 0.1.0-rc.4, the C ABI should be mostly stable. We reserve the right to make breaking changes before a numbered release without following semantic versioning.

Linking statically against librashader.h is possible, but is not officially supported. You will need to ensure linkage parameters are correct in order to successfully link with librashader.lib or librashader.a. The corrosion CMake package is highly recommended.

Examples

The following Rust examples show how to use each librashader runtime. * Vulkan * OpenGL * Direct3D 11 * Direct3D 12

Some basic examples on using the C API are also provided in the librashader-capi-tests directory.

Compatibility

librashader implements the entire RetroArch shader pipeline and is highly compatible with existing shaders.

Please report an issue if you run into a shader that works in RetroArch, but not under librashader.

Runtime specific differences

Most, if not all shader presets should work fine on librashader. The runtime specific differences should not affect the output, and are more a heads-up for integrating librashader into your project.

Quad vertices and rotations

All runtimes except OpenGL render with an identity matrix MVP and a VBO for with range [-1, 1]. The final pass uses a Quad VBO with range [0, 1] and the following projection matrix by default.

rust static DEFAULT_MVP: &[f32; 16] = &[ 2.0, 0.0, 0.0, 0.0, 0.0, 2.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, -1.0, -1.0, 0.0, 1.0, ];

As with RetroArch, a rotation on this MVP will be applied only on the final pass for these runtimes. This is the only way to pass orientation information to shaders.

The OpenGL runtime uses a VBO for range [0, 1] for all passes and the following MVP for all passes.

rust static GL_DEFAULT_MVP: &[f32; 16] = &[ 2.0, 0.0, 0.0, 0.0, 0.0, 2.0, 0.0, 0.0, 0.0, 0.0, 2.0, 0.0, -1.0, -1.0, 0.0, 1.0, ];

Thread safety

In general, it is safe to create a filter chain instance from a different thread, but drawing frames requires external synchronization of the filter chain object.

Filter chains can be created from any thread, but requires external synchronization of the graphics device queue where applicable (in Direct3D 11, the immediate context is considered the graphics device queue), as loading LUTs requires command submission to the GPU. Initialization of GPU resources may be deferred asynchronously using the filter_chain_create_deferred functions, but the caller is responsible for submitting the recorded commands to the graphics device queue, and ensuring that the work is complete before drawing shader pass frames.

OpenGL has an additional restriction where creating the filter chain instance in a different thread is safe if and only if the thread local OpenGL context is initialized to the same context as the drawing thread. Support for deferral of GPU resource initialization is not available to OpenGL.

Writing a librashader Runtime

If you wish to contribute a runtime implementation not already available, see the librashader-runtime crate for helpers and shared logic used across all librashader runtime implementations. Using these helpers and traits will ensure that your runtime has consistent behaviour for uniform and texture semantics bindings with the existing librashader runtimes.

These types should not be exposed to the end user in the runtime's public API, and should be kept internal to the implementation of the runtime.

License

The core parts of librashader such as the preprocessor, the preset parser, the reflection library, and the runtimes, are all licensed under the Mozilla Public License version 2.0.

The librashader C API, i.e. its headers and definitions, not its implementation in librashader-capi, are more permissively licensed, and may allow you to use librashader in your permissively licensed or proprietary project.

To facilitate easier use of librashader in projects incompatible with MPL-2.0, librashader_ld implements a loader which thunks its calls to any librashader.so or librashader.dll library found in the load path. A non-MPL-2.0 compatible project may link against librashader_ld to use the librashader runtime, provided that librashader.so or librashader.dll are distributed under the restrictions of MPLv2.

Note that this means that if your project is unable to comply with the requirements of MPL-2.0, you can not distribute librashader.so or librashader.dll alongside your project. The end user must obtain the implementation of librashader themselves. For more information, see the MPL 2.0 FAQ.

At your discretion, you may instead choose to distribute librashader under the terms of GPLv3 rather than MPL-2.0.