A low-overhead Vulkan-like GPU API for Rust.


Matrix room gfx-hal on crates.io Build Status
Getting Started | Documentation | Blog


gfx-rs is a low-level, cross-platform graphics and compute abstraction library in Rust. It consists of the following components:

  • gfx-hal which is gfx's hardware abstraction layer: a Vulkan-ic mostly unsafe API which translates to native graphics backends.
  • gfx-backend-* which contains graphics backends for various platforms:
  • gfx-warden which is a data-driven reference test framework, used to verify consistency across all graphics backends.

gfx-rs is hard to use, it's recommended for performance-sensitive libraries and engines. If that's not your domain, take a look at wgpu-rs for a safe and simple alternative.

The gfx crate

This repository was originally home to the gfx crate, which is now deprecated. You can find the latest versions of the code for that crate in the pre-ll branch of this repository.

The master branch of this repository is now focused on developing gfx-hal and its associated backend and helper libraries, as described above. gfx-hal is a complete rewrite of gfx, but it is not necessarily the direct successor to gfx. Instead, it serves a different purpose than the original gfx crate, by being "lower level" than the original. Hence, the name of gfx-hal was originally ll, which stands for "lower level", and the original gfx is now referred to as pre-ll.

The spiritual successor to the original gfx is actually wgpu, which stands on a similar level of abstraction to the old gfx crate, but with a modernized API that is more fit for being used over Vulkan/DX12/Metal. If you want something similar to the old gfx crate that is being actively developed, wgpu is probably what you're looking for, rather than gfx-hal.


To run an example, simply cd to the examples directory, then use cargo run with --features {backend} to specify the backend (where {backend} is either vulkan, dx12, dx11, metal, or gl). For example:

# Clone the gfx repository
git clone https://github.com/gfx-rs/gfx
# Change directory to `examples`
cd gfx/examples
# Vulkan
cargo run --bin quad --features vulkan
# Metal (macOS/iOS)
cargo run --bin quad --features metal
# DirectX12 (Windows)
cargo run --bin compute --features dx12 1 2 3 4

This runs the quad example using the Vulkan backend, and then the compute example using the DirectX 12 backend.

These examples assume that necessary dependencies for the graphics backend are already installed. For more information about installation and usage, refer to the Getting Started guide.

Hardware Abstraction Layer

The Hardware Abstraction Layer (HAL), is a thin, low-level graphics and compute layer which translates API calls to various backends, which allows for cross-platform support. The API of this layer is based on the Vulkan API, adapted to be more Rust-friendly.

Hardware Abstraction Layer (HAL)

Currently HAL has backends for Vulkan, DirectX 12/11, Metal, and OpenGL/OpenGL ES/WebGL.

The HAL layer is consumed directly by user applications or libraries. HAL is also used in efforts such as gfx-portability.

Previously Released Crates and API (pre-LL)

The code in master is a complete low-level rewrite of gfx based on HAL as described above.

The previously released crates (gfx_core, gfx, gfx_device_*, gfx_window_) are still being developed and published from the pre-ll (pre-low level rewrite) branch.


We are actively looking for new contributors and aim to be welcoming and helpful to anyone that is interested! We know the code base can be a bit intimidating in size and depth at first, and to this end we have a label on the issue tracker which marks issues that are new contributor friendly and have some basic direction for completion in the issue comments. If you have any questions about any of these issues (or any other issues) you may want to work on, please comment on GitHub and/or drop a message in our Matrix chat!


This repository is licensed under either of

at your option.

Contribution Licensing

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.

  • Relicense under dual MIT/Apache-2.0

    Relicense under dual MIT/Apache-2.0

    This issue was automatically generated. Feel free to close without ceremony if you do not agree with re-licensing or if it is not possible for other reasons. Respond to @cmr with any questions or concerns, or pop over to #rust-offtopic on IRC to discuss.

    You're receiving this because someone (perhaps the project maintainer) published a crates.io package with the license as "MIT" xor "Apache-2.0" and the repository field pointing here.

    TL;DR the Rust ecosystem is largely Apache-2.0. Being available under that license is good for interoperation. The MIT license as an add-on can be nice for GPLv2 projects to use your code.


    The MIT license requires reproducing countless copies of the same copyright header with different names in the copyright field, for every MIT library in use. The Apache license does not have this drawback. However, this is not the primary motivation for me creating these issues. The Apache license also has protections from patent trolls and an explicit contribution licensing clause. However, the Apache license is incompatible with GPLv2. This is why Rust is dual-licensed as MIT/Apache (the "primary" license being Apache, MIT only for GPLv2 compat), and doing so would be wise for this project. This also makes this crate suitable for inclusion and unrestricted sharing in the Rust standard distribution and other projects using dual MIT/Apache, such as my personal ulterior motive, the Robigalia project.

    Some ask, "Does this really apply to binary redistributions? Does MIT really require reproducing the whole thing?" I'm not a lawyer, and I can't give legal advice, but some Google Android apps include open source attributions using this interpretation. Others also agree with it. But, again, the copyright notice redistribution is not the primary motivation for the dual-licensing. It's stronger protections to licensees and better interoperation with the wider Rust ecosystem.


    To do this, get explicit approval from each contributor of copyrightable work (as not all contributions qualify for copyright, due to not being a "creative work", e.g. a typo fix) and then add the following to your README:

    ## License
    Licensed under either of
     * Apache License, Version 2.0, ([LICENSE-APACHE](LICENSE-APACHE) or http://www.apache.org/licenses/LICENSE-2.0)
     * MIT license ([LICENSE-MIT](LICENSE-MIT) or http://opensource.org/licenses/MIT)
    at your option.
    ### Contribution
    Unless you explicitly state otherwise, any contribution intentionally submitted
    for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any
    additional terms or conditions.

    and in your license headers, if you have them, use the following boilerplate (based on that used in Rust):

    // Copyright 2016 gfx Developers
    // Licensed under the Apache License, Version 2.0, <LICENSE-APACHE or
    // http://apache.org/licenses/LICENSE-2.0> or the MIT license <LICENSE-MIT or
    // http://opensource.org/licenses/MIT>, at your option. This file may not be
    // copied, modified, or distributed except according to those terms.

    It's commonly asked whether license headers are required. I'm not comfortable making an official recommendation either way, but the Apache license recommends it in their appendix on how to use the license.

    Be sure to add the relevant LICENSE-{MIT,APACHE} files. You can copy these from the Rust repo for a plain-text version.

    And don't forget to update the license metadata in your Cargo.toml to:

    license = "MIT OR Apache-2.0"

    I'll be going through projects which agree to be relicensed and have approval by the necessary contributors and doing this changes, so feel free to leave the heavy lifting to me!

    Contributor checkoff

    To agree to relicensing, comment with :

    I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to chose either at their option.

    Or, if you're a contributor, you can check the box in this repo next to your name. My scripts will pick this exact phrase up and check your checkbox, but I'll come through and manually review this issue later as well.

    • [x] @kvark
    • [x] @bjz
    • [x] @cmr
    • [x] @csherratt
    • [x] @bvssvni
    • [x] @sectopod
    • [x] @homu
    • [x] @Kimundi
    • [x] @hannobraun
    • [x] @fkaa
    • [x] @lucidd
    • [x] @serpis
    • [x] @vickenty
    • [x] @tomaka
    • [ ] @mitchmindtree
    • [x] @jeremija
    • [x] @nicholasbishop
    • [x] @mttr
    • [x] @aepsil0n
    • [x] @KokaKiwi
    • [ ] @Potpourri
    • [x] @photex
    • [x] @red75prime
    • [x] @Bastacyclop
    • [x] @olsonjeffery
    • [x] @mtsr
    • [x] @MaikKlein
    • [x] @thehydroimpulse
    • [ ] @burtonageo
    • [ ] @lynks--
    • [x] @mike-marcacci
    • [x] @stjahns
    • [x] @amaranth
    • [x] @petevine
    • [x] @nulldatamap
    • [x] @asheb
    • [x] @andrew-d
    • [x] @cybergeek94
    • [ ] @axelmagn
    • [x] @bfops
    • [x] @toqueteos
    • [x] @cl91
    • [ ] @Chase-C
    • [x] @munshkr
    • [x] @fungos
    • [x] @freebroccolo
    • [ ] @escalant3
    • [x] @dylanede
    • [x] @farism
    • [x] @flodiebold
    • [x] @jahfer
    • [x] @leonkunert
    • [x] @mzmonsour
    • [x] @ReadmeCritic
    • [ ] @AnthIste
    • [ ] @sbward
    • [x] @alexcrichton
    • [ ] @tomjakubowski
    • [x] @yuriks
    • [x] @gaudecker
    • [x] @ahtn
    • [x] @qres
    • [x] @tioover
    opened by emberian 107
  • OpenGL surface via surfman

    OpenGL surface via surfman

    Fixes/Discussion: https://github.com/gfx-rs/wgpu/issues/450

    PR checklist:

    • [x] make succeeds (on *nix)
    • [ ] make reftests succeeds
    • [x] tested examples with the following backends:
      • GL ( excluding compute because it isn't supported )
    • [x] rustfmt run on changed code
    opened by zicklag 94
  • Move examples to explicit gfx_support crate/module. Also move to virtual cargo workspace.

    Move examples to explicit gfx_support crate/module. Also move to virtual cargo workspace.

    I noticed this issue about gfx_app has pretty much stopped, when I was just looking, and realized the exact same thing had been confusing me trying to learn gfx. In the thread, it was brought up maybe it was a good idea to move gfx_app to it's own module, to help users with learning the API (whom are reading the example code).

    Since progress has slowed down in the PR for cargo workspaces I thought I would submit this as some progress. I thought it was good timing since the last commit to the gfx repository just accepted a pull-request doing a similar rename, it seems smart to do another rename pull-request like this (since others maintaining branches will already need to rebase). I could be wrong about this, but the alternative would for me to sit back and wait until another point in the future to do this.

    I think renaming gfx_app to gfx_support, and more importantly moving the code out of gfx's root (and under examples/) will help users understand what is "gfx library code" vs "gfx support library code". The distinction is subtle but important, I believe. It certainty wasn't clear to me until quite a while of digging by myself.

    I have a few things I'd like to discuss moving forward, this pull request certainly isn't ready as is.

    1. I'd like to gather consensus that this is the right direction to move gfx. Are there any objections to the direction of this pull-request?
    2. Is gfx_project a good name for the "root project"?
    3. I'm not sure that duplicating the Cargo.toml file is the right way to express what I'm intending. Right now I'm duplicating the dependencies section in both Cargo.toml files. Apart from going through each dependency one-by-one, and seeing whether examples/ or gfx/ requires the dependency, is there a way to not duplicate the dependencies your aware of? Is duplicating them a problem?
    4. In the other thread glium was brought up as an example, in glium's example code, the helper code lives in the examples/support/ directory, causing all examples to have to add explicitly mod support it. I tried emulating the same setup, but I wasn't able to get it to compile. I would need to spend more time comparing with the glium project to emulate that setup.
    5. I need to try using the support code from another package, to make sure it's visible the way I think it should be. This is a TODO.

    Anyways, I stole this list from the other thread. Here is what is working:

    cargo build cargo run --example (they all seem to work)

    What is not working:

    cargo test -- this isn't working for me on master/, not completely sure abouit this one. cargo build --all (error: native frameworks are only available on macOS targets) cargo test --all (error: Could not compile core-foundation-sys)

    Pretty tired now when writing this up, so posting this looking to get some direction/guidance to move forward with this change.

    edit: Resolves:

    • #1248
    • #1424
    opened by bjadamson 94
  • DX11 Backend

    DX11 Backend

    Fixes #89, Fixes #849, Fixes #878, Fixes #882, Fixes #897, Fixes #902, Fixes #906

    Breaking changes

    • TriangleFan is removed
    • R8_G8_B8 and R3_G3_B2 surface types are removed, and with them the old Srgb8 shortcut
    • scaled channel formats (integers that are seen as floats) are removed
    • explicit mipmap generation is removed. You can tell gfx to generate mipmaps on texture data initialization instead.
    • Factory::update_*() methods are removed in favor of CommandBuffer-based updates and providing the initial data for resource creation, which now supports multiple slices and mips.
    • device capabilities are reduced by cutting out GL-specific stuff.
    • there is a new Bind flag set that you'll need to pass for some of the object construction methods
    • Usage enum has undergone a rewrite
    • there is a new ShaderSet type that may need for the PSO (or shader program) construction
    • new structures for SRV/RTV/DSV creation: ResourceDesc, RenderDesc, and DepthStencilDesc
    • CommandBuffer interface has minor changes in the scissor and indexed draw semantics, and a major change in the clearing semantics.
    • SubmitInfo is gone. Encoder has a single flush method instead of as_buffer and reset.
    • Phantom is renamed to Typed
    • gfx_constant_struct requires the shader-visible names now, the same as gfx_vertex_struct
    • shader version selection has been moved to gfx_app crate. Both core and render crates are now completely API-unaware.

    Notable non-breaking changes

    • there are new gfx_device_dx11 and gfx_window_dxgi crates. We also set up windows CI, which has GLFW stuff excluded.
    • most, if not all, examples are rewritten to use the new gfx_app crate. It is now the only place that knows about all the windowing and API backends in this repository.
    • Border mode for samplers
    • new convenience type your_pso::Bundle and the constructor your_pso::bundle() are generated for you to contain the slice, PSO itself, and PSO run-time data objects.

    Examples update

    • most examples simply call launch_default, which selects the default backends for the current platform
    • no longer using cast_slice - instead calling create_texture_const_u8
    • passing in an array of input slices for texture creation - this saves "skybox" example half a page of code
    • parameters are converted to be using the constant buffers for DX11 compatibility. Some are still being mirrored in globals to be compatible with GL2.
    • shader versions for different models/backends are now properly specified and selected
    • "Target0" name for the final PSO outputs at the moment. DX11 doesn't provide us the name, but it has the type to match on, and GL doesn't care. "Target0" is what we translate built-in DX11 semantic into.

    Why DX11?

    It's the most established API for high-performance games and graphics application to date. It has the best all-around driver support, variety of powerful tools, and is not cluttered by the legacy (looking at you, OpenGL).

    Implementation details

    The backend supports both native deferred contexts and emulated (in the same way we do with OpenGL). Once you obtained a device instance with gfx_window_dxgi::init, you can transform it into gfx_device_dx11::Deferred with a simple into() call. The application launcher uses native DX11 contexts by default.

    Future work

    • Integrate winit when it's ready (#907)
    • Implement state caching for the DX11 command buffers
    opened by sectopod 85
  • Pipeline State Objects revolution

    Pipeline State Objects revolution

    Requires https://github.com/gfx-rs/draw_state/pull/34 Fixes #815, fixes #842, fixes #823, fixes #761, ~~fixes #722~~, fixes #703, fixes #694, fixes #463 Closes #817, closes #640, closes #630, closes #575, closes #571, closes #322, closes #121 Touches #698, #331, #311, #284, #161

    Breaking changes:

    • Batch, Mesh, Stream concepts are gone, as well as the old shader parameters interface. PSO is the new paradigm, with it's own macro and interfaces.
    • VAO, FBO, Surface, Plane, Output are gone, they are now hidden GL implementation details. Command enum and state caching have also been moved into GL backend.
    • Texture semantic has changed - now it is just an allocation of some pixel data. For actual rendering, users are required to operate on the strongly-typed target/resource views. The new format specification supports textures, views, and vertex buffers in the uniform way.

    See a better overview of the change in this comment. The best source of knowledge to this moment is the example code. We realize such this needs to be well documented and are working on it.

    TODO (note: this is a vastly incomplete list of what's actually done):

    • [x] PSO resource - low level
      • [x] resource
      • [x] binding
      • [x] creation
    • [x] High level
      • [x] RenderTargetView and DepthStencilView
        • [x] low-level bindings
        • [x] raw creation
        • [x] typed creation
        • [x] hook up to PSO
      • [x] ShaderResourceView and UnorderedAccessView
        • [x] low-level bindings
        • [x] raw creation
        • [x] typed creation
        • [x] hook up to PSO
      • [x] move core into a separate lib (#703)
      • [x] remove the Copy constraint from the resources
      • [x] layout matching
        • [x] vertex attributes
        • [x] shader data
        • [x] pixel targets
      • [x] strongly-typed initialization
      • [x] hook to the Renderer for drawing
    • [x] helper macros
      • [x] structure definition
      • [x] PSO
      • [x] PSO with static init
      • [x] texture format
      • [x] macros tests
    • [x] Universal data format spec
      • [x] serialized form
      • [x] strongly-typed form
      • [x] replace tex::Format
      • [x] replace attrib::Format
    • [x] GL backend
      • [x] rewrite init() function for windowing backends
      • [x] rewrite CommandBuffer implementation to do the heavy lifting
      • [ ] ~~support for structured buffers~~ (can be postponed)
      • [x] Glutin window
      • [x] GLFW window
    • [x] Switch the examples to use PSO
      • [x] blend
      • [x] cube
      • [x] deferred
      • [x] flowmap
      • [x] instancing
      • [x] mipmap
      • [x] performance
      • [x] shadow
      • [x] terrain
      • [x] triangle
      • [x] ubo_tilemap
    • [x] Clean up
      • [x] remove old Resources subtypes
      • [ ] ~~remove shader programs~~
      • [x] remove old meshes and attribute formats
      • [x] remove old shader parameters
      • [x] remove old texture format
      • [x] remove batches
      • [x] remove VAO and FBO
      • [x] remove Plane, Output, and Frame
    • [x] Post-clean
      • [x] rename NewTexture to Texture
      • [x] remove primitive from mesh::Slice
    • [x] Documentation
      • [x] typed PSO
      • [x] universal format

    Or, basically, rewrite the whole damn thing ;)

    opened by sectopod 52
  • thread '<main>' panicked at 'Error after executing command BindProgram(0): InvalidOperation'

    thread '
    ' panicked at 'Error after executing command BindProgram(0): InvalidOperation'

    I'm getting an error when running the following code:

    extern crate piston_window;
    use piston_window::*;
    fn main() {
        let mut window: PistonWindow = PistonWindow::new(OpenGL::V2_1, 0,
        WindowSettings::new("Hello", (800,600))
          .build() // hack around default srgb(true) (builds GlutinWindow instead of PistonWindow)
        while let Some(e) = window.next() {
            window.draw_2d(&e, |_c, g| {
                clear([0.5, 1.0, 0.5, 1.0], g);

    here is the stack backtrace:

    `thread '<main>' panicked at 'Error after executing command BindProgram(0): InvalidOperation', /home/harrison/.multirust/toolchains/beta/cargo/registry/src/github.com-88ac128001ac3a9a/gfx_device_gl-0.10.0/src/lib.rs:283
    stack backtrace:
       1:     0x562aec0d2c90 - std::sys::backtrace::tracing::imp::write::h25f26530b3b48a54
       2:     0x562aec0d57bb - std::panicking::default_hook::_$u7b$$u7b$closure$u7d$$u7d$::hb497e646e4148afc
       3:     0x562aec0d5443 - std::panicking::default_hook::hd57825f8b5247927
       4:     0x562aec0cbf1f - std::sys_common::unwind::begin_unwind_inner::hf40013815c474ad4
       5:     0x562aec0ccbc8 - std::sys_common::unwind::begin_unwind_fmt::h42a3b0f6333a2a21
       6:     0x562aebf76c8f - gfx_device_gl::Device::check::h4290e3674196ac1e
                            at /home/harrison/Projects/rust/testing_piston/src/<std macros>:8
       7:     0x562aebf7e69d - gfx_device_gl::Device::process::ha9e4c244f4e4d126
                            at /home/harrison/.multirust/toolchains/beta/cargo/registry/src/github.com-88ac128001ac3a9a/gfx_device_gl-0.10.0/src/lib.rs:665
       8:     0x562aebf7a04e - gfx_device_gl::Device::reset_state::hd0590a45498c77d8
                            at /home/harrison/.multirust/toolchains/beta/cargo/registry/src/github.com-88ac128001ac3a9a/gfx_device_gl-0.10.0/src/lib.rs:378
       9:     0x562aebf88b02 - _<Device as gfx_core..Device>::submit::hd22aed74b4a07f91
                            at /home/harrison/.multirust/toolchains/beta/cargo/registry/src/github.com-88ac128001ac3a9a/gfx_device_gl-0.10.0/src/lib.rs:689
      10:     0x562aebef9db0 - _<gfx..encoder..Encoder<R, C>>::flush::hbf7cc6ecb9eefa5b
                            at /home/harrison/.multirust/toolchains/beta/cargo/registry/src/github.com-88ac128001ac3a9a/gfx-0.11.0/src/encoder.rs:85
      11:     0x562aebef2bff - _<piston_window..PistonWindow<W>>::draw_2d::hf03a024ce1bc4da9
                            at /home/harrison/.multirust/toolchains/beta/cargo/registry/src/github.com-88ac128001ac3a9a/piston_window-0.47.0/src/lib.rs:221
      12:     0x562aebebff80 - testing_piston::main::h55362581195f04b1
                            at /home/harrison/Projects/rust/testing_piston/src/main.rs:12
      13:     0x562aec0d5084 - std::sys_common::unwind::try::try_fn::hf5d123c03b60f222
      14:     0x562aec0d20fb - __rust_try
      15:     0x562aec0d4acb - std::rt::lang_start::hb87e98f24ba5d300
      16:     0x562aebefaab9 - main
      17:     0x7fe7c4171ec4 - __libc_start_main
      18:     0x562aebebfd18 - <unknown>
      19:                0x0 - <unknown>
    error: Process didn't exit successfully: `/home/harrison/Projects/rust/testing_piston/target/debug/testing_piston` (exit code: 101)`

    How do I go about fixing this? I was thinking maybe I'm missing a dependency or something, but I really have no idea!

    type: bug value: high backend: OpenGL 
    opened by bluecereal 34
  • Quad example doesn't work on OS X

    Quad example doesn't work on OS X

    $ cargo run --bin quad --features=metal

    Produces a grey window and nothing else

    Short info header:

    • OS: OS X Sierra 10.12.6 (16G29)
    • GPU: Intel Iris Graphics 6100 1536 MB

    $git log commit 6c3c1d335778fba3333d395f486a8a032805cec6 Merge: f8b74e2 86c5d35 Author: bors[bot] <bors[bot]@users.noreply.github.com> Date: Wed Jan 9 17:45:47 2019 +0000

    examples$ cargo run --bin quad --features=metal Finished dev [unoptimized + debuginfo] target(s) in 0.20s
    Running /Users/andrewl/rust/gfx/target/debug/quad AdapterInfo { name: "Intel(R) Iris(TM) Graphics 6100", vendor: 0, device: 0, device_type: DiscreteGpu } Memory types: [MemoryType { properties: DEVICE_LOCAL, heap_index: 0 }, MemoryType { properties: COHERENT | CPU_VISIBLE, heap_index: 1 }, MemoryType { properties: DEVICE_LOCAL | CPU_VISIBLE, heap_index: 1 }, MemoryType { properties: DEVICE_LOCAL | CPU_VISIBLE | CPU_CACHED, heap_index: 1 }] formats: Some([Bgra8Unorm, Bgra8Srgb, Rgba16Float]) SwapchainConfig { present_mode: Fifo, composite_alpha: Inherit, format: Bgra8Srgb, extent: Extent2D { width: 1024, height: 768 }, image_count: 2, image_layers: 1, image_usage: COLOR_ATTACHMENT } SwapchainConfig { present_mode: Fifo, composite_alpha: Inherit, format: Bgra8Srgb, extent: Extent2D { width: 1024, height: 768 }, image_count: 2, image_layers: 1, image_usage: COLOR_ATTACHMENT } SwapchainConfig { present_mode: Fifo, composite_alpha: Inherit, format: Bgra8Srgb, extent: Extent2D { width: 1024, height: 768 }, image_count: 2, image_layers: 1, image_usage: COLOR_ATTACHMENT } SwapchainConfig { present_mode: Fifo, composite_alpha: Inherit, format: Bgra8Srgb, extent: Extent2D { width: 1024, height: 768 }, image_count: 2, image_layers: 1, image_usage: COLOR_ATTACHMENT } SwapchainConfig { present_mode: Fifo, composite_alpha: Inherit, format: Bgra8Srgb, extent: Extent2D { width: 1024, height: 768 }, image_count: 2, image_layers: 1, image_usage: COLOR_ATTACHMENT }

    [lines keep repeating infinitely]

    type: bug platform: OSX value: high backend: Metal client: blocker 
    opened by buzmeg 33
  • [mtl] Fix A2BGR10 format mapping

    [mtl] Fix A2BGR10 format mapping

    Fixes Dota2 after #2116 PR checklist:

    • [ ] make succeeds (on *nix)
    • [ ] make reftests succeeds
    • [ ] tested examples with the following backends:
    • [ ] rustfmt run on changed code
    opened by kvark 33
  • Enable GL backend via Surfman

    Enable GL backend via Surfman

    ( Will, hopefully ) fix issue #3353

    PR checklist:

    • [ ] make succeeds (on *nix)
    • [ ] make reftests succeeds
    • [ ] tested examples with the following backends:
    opened by zicklag 31
  • Mark most functions as unsafe

    Mark most functions as unsafe

    Because we follow Vulkan closely for the HAL API, we don't have many safety guarantees for most of the API usage. A few users have asked to have the explicit unsafe annotation to make it more obvious that no guarantees are provided here.

    difficulty: average module: hal type: discussion type: api client: request 
    opened by grovesNL 30
  • Are Users Supposed to Use gfx_app::Application?

    Are Users Supposed to Use gfx_app::Application?

    I'm trying to figure out if I'm supposed to use gfx_app::Application since that's what all the examples use, but don't see a way to take user input. Looking at the implementation it hard codes the keys it will accept. Is there a way to handle user input with this struct or is this boilerplate I'm supposed to copy and modify?

    let mut harness = Harness::new();
    main: loop {
        // quit when Esc is pressed.
        for event in window.poll_events() {
            match event {
                glutin::Event::KeyboardInput(_, _, Some(glutin::VirtualKeyCode::Escape)) |
                glutin::Event::Closed => break 'main,
                _ => {},
        // draw a frame
        app.render(&mut device);
    type: discussion type: api api: pre-ll 
    opened by kruffin 30
Rust Graphics Mages
Portable Graphics and Compute in Rust
Rust Graphics Mages
Level up your shader game with the GPU + Rust advantage!

Gravy (WIP) Ya know, my momma always said everything's better with Gravy... Gravy is a shader programming framework and toolkit built on the union of

Dr. Rubisco 8 Nov 7, 2023
A higher dimensional raytracing prototype with non-euclidean-like features

euclider A higher-dimensional "non-euclidean" ray tracing prototype written in Rust. Dual-licensed under MIT or the UNLICENSE. Installation Install th

Jakub Hlusička 190 Dec 11, 2022
A vector graphics renderer using OpenGL with a Rust & C API.

bufro A vector graphics renderer using OpenGL with a Rust & C API. A Rust example can be found in examples/quickstart.rs (using glutin). A C example c

Aspect 9 Dec 15, 2022
Rust bindings to bgfx, a cross-platform, graphics API agnostic

Rust bindings to bgfx, a cross-platform, graphics API agnostic, "Bring Your Own Engine/Framework" style rendering library.

Daniel Collin 65 Dec 24, 2022
Graph API client writen in Rust

graph-rs Now available on stable Rust at crates.io graph-rs-sdk = "0.1.0" 0.1.0 and above use stable Rust. Anything before 0.1.0 uses nightly Rust. M

Sean Reeise 56 Jan 3, 2023
A toy ray tracer in Rust

tray_rust - A Toy Ray Tracer in Rust tray_rust is a toy physically based ray tracer built off of the techniques discussed in Physically Based Renderin

Will Usher 492 Dec 19, 2022
A complete harfbuzz's shaping algorithm port to Rust

rustybuzz rustybuzz is a complete harfbuzz's shaping algorithm port to Rust. Matches harfbuzz v2.7.0 Why? Because you can add rustybuzz = "*" to your

Evgeniy Reizner 310 Dec 22, 2022
An OpenGL function pointer loader for Rust

gl-rs Overview This repository contains the necessary building blocks for OpenGL wrapper libraries. For more information on each crate, see their resp

Brendan Zabarauskas 621 Dec 17, 2022
Safe OpenGL wrapper for the Rust language.

glium Note to current and future Glium users: Glium is no longer actively developed by its original author. That said, PRs are still welcome and maint

null 3.1k Jan 1, 2023
GLFW3 bindings and idiomatic wrapper for Rust.

glfw-rs GLFW bindings and wrapper for The Rust Programming Language. Example extern crate glfw; use glfw::{Action, Context, Key}; fn main() { le

PistonDevelopers 546 Jan 3, 2023
Graph data structure library for Rust.

petgraph Graph data structure library. Supports Rust 1.41 and later. Please read the API documentation here Crate feature flags: graphmap (default) en

null 2k Jan 9, 2023
A graph library for Rust.

Gamma A graph library for Rust. Gamma provides primitives and traversals for working with graphs. It is based on ideas presented in A Minimal Graph AP

Metamolecular, LLC 122 Dec 29, 2022
Simple but powerful graph library for Rust

Graphlib Graphlib is a simple and powerful Rust graph library. This library attempts to provide a generic api for building, mutating and iterating ove

Purple Protocol 177 Nov 22, 2022
Kiss3d - Keep it simple, stupid 3d graphics engine for Rust.

Kiss3d - Keep it simple, stupid 3d graphics engine for Rust.

Sébastien Crozet 1.2k Dec 26, 2022
A cool, fast maze generator and solver written in Rust

MazeCruncher Welcome to maze cruncher! Download Standalone Here Usage To get started, just run the standalone .exe in target/release or compile and ru

null 69 Sep 20, 2022
ASCII 3D-renderer using Ray Marching technique written in Rust with NCurses

pistol ASCII renderer using Ray Marching technique written in Rust ?? with NCurses. This project is a giga-chad compared to my previous attempt to wri

Eugene Sokolov 5 Dec 10, 2022
A high-performance SVG renderer, powered by Rust based resvg and napi-rs.

resvg-js resvg-js is a high-performance SVG renderer, powered by Rust based resvg and napi-rs. Fast, safe and zero dependencies! No need for node-gyp

一丝 744 Jan 7, 2023
A little cross-platform graphics engine written in rust.

Bismuth This is a version of my C++ graphics engine named Bismuth re-written with Rust. My goal is to learn more about the Rust language and make my g

Admiral サイタマ 1 Nov 1, 2021
The library provides basic functions to work with Graphviz dot lang from rust code.

Description The library provides the basic access to the graphs in graphviz format with ability to import into or export from it. Base examples: Parse

Boris 28 Dec 16, 2022