gfx-rs/gfx

Getting Started | Documentation | Blog | Funding

Getting Started | Blog | wgpu, which has now switched to its own GPU abstraction called #3768


Getting Started | Documentation | Blog | Funding

gfx-rs

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

gfx-hal deprecation

As of the v0.9 release, gfx-hal is now in maintenance mode. gfx-hal development was mainly driven by wgpu, which has now switched to its own GPU abstraction called wgpu-hal. For this reason, gfx-hal development has switched to maintenance only, until the developers figure out the story for gfx-portability. Read more about the transition in #3768.

hal

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

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.

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.

See the Big Picture blog post for connections.

The old gfx crate (pre-ll)

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.

Contributing

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!

License

This repository is licensed under either of

  • Apache License, Version 2.0, (LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0)
  • MIT license (LICENSE-MIT or #404)

at your option.

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.

Issues

Collection of the latest Issues

schwa423

schwa423

Comment Icon0

Background:

Hello, the Fuchsia project vendors crates from crates.io, and in order to do so we require explicit license files alongside the source code. Here is the policy: https://fuchsia.dev/fuchsia-src/contribute/governance/policy/open-source-licensing-policies?hl=en#licenses_and_tracking . In particular, reading the SPDX package/license field from the crate's Cargo.toml is not good enough.

Request:

Could you please add LICENSE-* files to the package subdirectories, specifically src/auxil/range-alloc (although you might as well do it for all package dirs that are uploaded to crates.io)?

We are currently using range-alloc 0.1.2. Since crates.io doesn't allow re-uploading the same version with a modified crate, it seems the right thing to do is to upload new a new crate with version 0.1.3.

I'd appreciate if you're able to do this, since I have to file similar issues for many other crate dependencies. But if you don't have the bandwidth to address this issue, please let me know and I'll find time to submit a pull request (although of course I won't be able to upload anything to crates.io)

PSteinhaus

PSteinhaus

api: pre-ll
Comment Icon1

Short info header:

  • GFX version:
    • gfx = "0.18"
    • gfx_core = "0.9"
    • gfx_device_gl = "0.16"
  • OS: Windows 10.0.19043 (and maybe others)
  • GPU: Intel(R) UHD Graphics 630 (and also maybe others)

We received two bug reports concerning this issue. Since the function on our side that causes the bug doesn't do much more than calling gfx_device_gl::CommandBuffer::clear_color I just assume it's a dependency bug, so here I am.

I'll not repeat everything said in the linked issue, but put simply, most users call ggez::graphics::clear in their draw loops and it works just fine, but for a few unlucky this call just seems to stop the screen from being rerendered. The shown image stays the same, even though the game runs properly apart from that. If they remove the call to clear they actually get new images, but of course, without clearing the screen everything just looks smeared.

Naively, I'd assume it might even be a driver issue of some kind, since this behaviour is independant from developement environment and only seems to depend on where the program is run. But then again, I didn't look too deep into this and I can just guess that other software runs fine on these machines, so maybe gfx, or one of your dependencies, might be at fault for not speaking to them correctly after all.

dudochkin-victor

dudochkin-victor

type: bug
Comment Icon10

Short info header:

  • GFX version: 0.9.0
  • OS: Linux
  • GPU: GeForce GTX 1050/PCIe/SSE2 with proprietary drivers (NVIDIA 460.67)

I want to thank you for a great job. But i have some warnings when use wgpu. It looks like it is a gfx_backend_vulkan error. I did a little research on this bug and VVL reviews. But I tried to implement some logic with ash and I don't have these warnings in my production application.

So I think this is not a VVL and Nvidia problem. Can you fix this or disable these warnings that appear on every frame?

JCapucho

JCapucho

type: bug
Comment Icon0

Short info header:

  • GFX version: 27a1dae3
  • OS: Windows 10
  • GPU: GTX 1650

The panic happened while using wgpu and the vulkan backend, the error message says that it panicked at /src/backend/vulkan/src/device.rs:1568 which corresponds to line 1543 in master

dudochkin-victor

dudochkin-victor

type: bug
Comment Icon0

Short info header:

  • GFX version: 0.8.0
  • OS: Linux
  • GPU: GeForce GTX 1050/PCIe/SSE2 with proprietary drivers (NVIDIA 460.67)

It works when i start: cargo run --bin quad --features=vulkan I checked that the egl, gles2 is working on C/C++ examples. I checked with es2tri.c with manual x11 window creation and some other examples using glfw and SDL. So system is correct.

But when I start using: RUST_LOG=info cargo run --bin quad --features=gl I got black screen.

Here output:

str0yd

str0yd

Comment Icon3

Short info header:

  • GFX version: hal-0.8 branch
  • OS: Windows
  • GPU: name: "Radeon RX Vega", vendor: 4098, device: 26751, device_type: DiscreteGpu

I just cloed the hal-0.8 branch but i can't compile the project with the gl or metal backend. Vulkan and dx12 work without problems.

expenses

expenses

type: api
Comment Icon5

Goal

It would be neat and useful to have an implementation of get_pipeline_cache_data on all modern platforms (Vulkan, DX12, Metal). Along with the corresponding code in create_pipeline_cache, this would allow for being able to cache the pipelines to disk on all backends, giving a good performance boost when a lot of pipelines are used.

Status

Vulkan

The Vulkan API has this get_pipeline_cache_data function built in.

Metal

Edit: disregard this whole section, see https://github.com/gfx-rs/gfx/issues/3716#issuecomment-813698647.

The Metal backend has a pipeline cache: https://github.com/gfx-rs/gfx/blob/2a93d52661aafcbd6441ea83e739c8ced906cd21/src/backend/metal/src/native.rs#L207-L211

However there is no way to serialize or deserialize it at present.

The key blocker for this is that the ModuleInfo struct stores a metal::Library:

https://github.com/gfx-rs/gfx/blob/2a93d52661aafcbd6441ea83e739c8ced906cd21/src/backend/metal/src/native.rs#L200-L205

While there is no way in the Metal API to serialize a MTLLibrary (the underlying type), there is a serialize function for MTLDynamicLibrary which I believe we could convert into. It serializes directly into a file though, which is pretty gross. Presumably we'd then have to read back from this file.

The other option would be to just store the metal source code for the shader that has been converted from spir-v. This would not give as big a performance improvement though.

MoltenVK

MoltenVK implements a pipeline cache with MVKPipelineCache. Similar to what we do with metal, this stores MVKShaderLibraryCaches which in turn store MVKShaderLibrarys. When implementing getPipelineCacheData, it writes the metal source code, similar to what I suggest as an option above.

As an example of this, here's some of the output of a pipeline cache I generated:

DX12

The DirectX 12 backend doesn't have a pipeline cache. However, there is an issue that lays out how one could be created: https://github.com/gfx-rs/gfx/issues/2877, similar to what the Metal backend does.

jdu

jdu

difficulty: easy
Comment Icon4

Short info header:

  • GFX version: 0.6.0+
  • OS: All
  • GPU: All

Is there way to expose the raw handle for things like the Device in order "shim" libraries into gfx-rs?

For example the skulpin project using rafx, can get a raw handle to instance, device, etc.. to pass into skia-safe to bind to a skia BackendContext. You can see how skulpin does this here https://github.com/aclysma/skulpin/blob/master/skulpin-renderer/src/skia_support.rs#L48 with rafx.

Is there a way to get a passable handle from gfx-rs to perform something similar in order to allow shimming of skia into the gfx-backend-* I've looked through the docs a fair bit and tried a few different things, but i'm coming up empty-handed to see how I could achieve this.

bnb-ashershen

bnb-ashershen

type: bug
Comment Icon1

Hi!

My app doing render stuff in separate thread (not main), and when I try to run it with env var CA_ASSERT_MAIN_THREAD_TRANSACTIONS=1 (Xcode Instruments run it like this), I see crash in this line. If comment out described line application works fine, looks like only setAllowsNextDrawableTimeout message make CA transaction under the hood.

Error happens during creating swapchain through wgpu library.

macOS Big Sur 11.2.3 Crash error: CoreAnimation: CA_ASSERT_MAIN_THREAD_TRANSACTIONS is set and an implicit transaction wasn't created on a main thread.

Thanks.

kvark

kvark

status: ready for work
Comment Icon1

See https://gpuopen.com/vulkan-sync2-support/ and https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_KHR_synchronization2.html

One of the important bits of difference is that both sides of an event/barrier now know about the barrier contents. This matches DX12 split barriers, so there is an obvious benefit here.

I think what we should do is having this extra information optional in set_event. If the user provides it, then the backend can take advantage of a split barrier. Otherwise, it's the same as today. Vulkan Portability would be using the old version for a while.

John-Nagle

John-Nagle

type: bug
Comment Icon1

Short info header:

  • GFX version: 0.7.0
  • OS: Ubuntu 20.04 LTS.
  • GPU: NVidia 3070, driver 460.32.03

Panicked at 'internal error: entered unreachable code: Unexpected result - driver bug? Err(ERROR_INITIALIZATION_FAILED)', /home/john/.cargo/registry/src/github.com-1ecc6299db9ec823/gfx-backend-vulkan-0.7.0/src/device.rs:1953:18

Looking at the code in device.rs, it looks like the Vulkan driver returned ERROR_INITIALIZATION_FAILED and the code in device.rs didn't have a match case for that, so it reached the default case and panicked.

Why the driver returned that status I do not know. There are recent reports on NVidia forums of games crashing with that error:

https://www.nvidia.com/en-us/geforce/forums/game-ready-drivers/13/428627/vulkan-errorinitializationfailed-on-win10-with-gtx/

So NVidia may have changed something that affects this.

This is from a program of mine using "rend3", which uses "gfx". It's happened twice, both times during window resizing. It's just loading a big scene into the GPU, which can then be explored. Visually, everything looks fine. My program, which is 100% safe Rust, is not doing much except refreshing the scene and responding to window events.

Backtraces follow:

00002 frames over 01.15s. Min: 558.37ms; Average: 576.98ms; 95%: 595.59ms; 99%: 595.59ms; Max: 595.59ms; StdDev: 18.61ms 00002 frames over 01.18s. Min: 588.25ms; Average: 589.56ms; 95%: 590.87ms; 99%: 590.87ms; Max: 590.87ms; StdDev: 01.31ms thread '' panicked at 'internal error: entered unreachable code: Unexpected result - driver bug? Err(ERROR_INITIALIZATION_FAILED)', /home/john/.cargo/registry/src/github.com-1ecc6299db9ec823/gfx-backend-vulkan-0.7.0/src/device.rs:1953:18 stack backtrace: 0: rust_begin_unwind at /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/std/src/panicking.rs:495:5 1: std::panicking::begin_panic_fmt at /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/std/src/panicking.rs:437:5 2: gfx_backend_vulkan::device::::create_swapchain at /home/john/.cargo/registry/src/github.com-1ecc6299db9ec823/gfx-backend-vulkan-0.7.0/src/device.rs:1953:18 3: <gfx_backend_vulkan::window::Surface as gfx_hal::window::PresentationSurface<gfx_backend_vulkan::Backend>>::configure_swapchain at /home/john/.cargo/registry/src/github.com-1ecc6299db9ec823/gfx-backend-vulkan-0.7.0/src/window.rs:367:35 4: wgpu_core::device::<impl wgpu_core::hub::Global>::device_create_swap_chain at /home/john/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-core-0.7.0/src/device/mod.rs:4180:13 5: <wgpu::backend::direct::Context as wgpu::Context>::device_create_swap_chain at /home/john/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-0.7.0/src/backend/direct.rs:801:15 6: wgpu::Device::create_swap_chain at /home/john/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-0.7.0/src/lib.rs:1623:17 7: rend3::renderer::util::create_swapchain at /home/john/.cargo/git/checkouts/rend3-e03f89403de3386a/c51c19f/rend3/src/renderer/util.rs:10:5 8: rend3::renderer::resources::RendererGlobalResources::update::{{closure}} at /home/john/.cargo/git/checkouts/rend3-e03f89403de3386a/c51c19f/rend3/src/renderer/resources.rs:81:39 9: core::option::Option::map at /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/core/src/option.rs:453:29 10: rend3::renderer::resources::RendererGlobalResources::update at /home/john/.cargo/git/checkouts/rend3-e03f89403de3386a/c51c19f/rend3/src/renderer/resources.rs:81:17 11: rend3::renderer::render::render_loop::{{closure}} at /home/john/.cargo/git/checkouts/rend3-e03f89403de3386a/c51c19f/rend3/src/renderer/render.rs:390:13 12: <core::future::from_generator::GenFuture as core::future::future::Future>::poll at /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/core/src/future/mod.rs:80:19 13: <tracing_futures::Instrumented as core::future::future::Future>::poll at /home/john/.cargo/registry/src/github.com-1ecc6299db9ec823/tracing-futures-0.2.4/src/lib.rs:258:9 14: <std::panic::AssertUnwindSafe as core::future::future::Future>::poll at /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/std/src/panic.rs:339:9 15: <std::panic::AssertUnwindSafe as core::future::future::Future>::poll at /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/std/src/panic.rs:339:9 16: <switchyard::CatchUnwind as core::future::future::Future>::poll::{{closure}} at /home/john/.cargo/registry/src/github.com-1ecc6299db9ec823/switchyard-0.1.1/src/lib.rs:179:42 17: <std::panic::AssertUnwindSafe as core::ops::function::FnOnce<()>>::call_once at /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/std/src/panic.rs:322:9 18: std::panicking::try::do_call at /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/std/src/panicking.rs:381:40 19: __rust_try 20: std::panicking::try at /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/std/src/panicking.rs:345:19 21: std::panic::catch_unwind at /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/std/src/panic.rs:396:14 22: <switchyard::CatchUnwind as core::future::future::Future>::poll at /home/john/.cargo/registry/src/github.com-1ecc6299db9ec823/switchyard-0.1.1/src/lib.rs:179:9 23: switchyard::Switchyard::spawn_local::{{closure}}::{{closure}} at /home/john/.cargo/registry/src/github.com-1ecc6299db9ec823/switchyard-0.1.1/src/lib.rs:502:32 24: <core::future::from_generator::GenFuture as core::future::future::Future>::poll at /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/core/src/future/mod.rs:80:19 25: <core::pin::Pin

as core::future::future::Future>::poll at /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/core/src/future/future.rs:119:9 26: switchyard::task::ThreadLocalTask

::poll at /home/john/.cargo/registry/src/github.com-1ecc6299db9ec823/switchyard-0.1.1/src/task.rs:270:26 27: switchyard::worker::body::{{closure}} at /home/john/.cargo/registry/src/github.com-1ecc6299db9ec823/switchyard-0.1.1/src/worker.rs:132:34 note: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace. thread 'main' panicked at 'Job panicked!', /home/john/.cargo/registry/src/github.com-1ecc6299db9ec823/switchyard-0.1.1/src/lib.rs:153:78 stack backtrace: 0: std::panicking::begin_panic at /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/std/src/panicking.rs:521:12 1: <switchyard::JoinHandle as core::future::future::Future>::poll::{{closure}} at /home/john/.cargo/registry/src/github.com-1ecc6299db9ec823/switchyard-0.1.1/src/lib.rs:153:78 2: core::result::Result<T,E>::unwrap_or_else at /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/core/src/result.rs:825:23 3: <switchyard::JoinHandle as core::future::future::Future>::poll at /home/john/.cargo/registry/src/github.com-1ecc6299db9ec823/switchyard-0.1.1/src/lib.rs:153:53 4: pollster::block_on at /home/john/.cargo/registry/src/github.com-1ecc6299db9ec823/pollster-0.2.1/src/lib.rs:131:15 5: slscenetester::displaystate::{{closure}} at /home/john/projects/sl/SL-test-viewer/slscenetester/src/main.rs:496:13 6: winit::platform_impl::platform::sticky_exit_callback at /home/john/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.24.0/src/platform_impl/linux/mod.rs:736:5 7: winit::platform_impl::platform::x11::EventLoop::run_return at /home/john/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.24.0/src/platform_impl/linux/x11/mod.rs:320:21 8: winit::platform_impl::platform::x11::EventLoop::run at /home/john/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.24.0/src/platform_impl/linux/x11/mod.rs:398:9 9: winit::platform_impl::platform::EventLoop::run at /home/john/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.24.0/src/platform_impl/linux/mod.rs:652:56 10: winit::event_loop::EventLoop::run at /home/john/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.24.0/src/event_loop.rs:154:9 11: slscenetester::displaystate at /home/john/projects/sl/SL-test-viewer/slscenetester/src/main.rs:342:5 12: slscenetester::main at /home/john/projects/sl/SL-test-viewer/slscenetester/src/main.rs:616:5 13: core::ops::function::FnOnce::call_once at /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/core/src/ops/function.rs:227:5
JOE1994

JOE1994

type: bug
Comment Icon1

Hello :crab: , we (Rust group @sslab-gatech) found a memory-safety/soundness issue in this crate while scanning Rust code on crates.io for potential vulnerabilities.

Issue Description

https://github.com/gfx-rs/gfx/blob/83a437d34b6f3082217c7ac9a476a1429d7f615c/src/auxil/auxil/src/lib.rs#L72-L82

gfx_auxil::read_spirv() method creates an uninitialized buffer (result) and passes it to user-provided Read implementation. This is unsound, because it allows safe Rust code to exhibit an undefined behavior (read from uninitialized memory).

This part from the Read trait documentation explains the issue:

It is your responsibility to make sure that buf is initialized before calling read. Calling read with an uninitialized buf (of the kind one obtains via MaybeUninit<T>) is not safe, and can lead to undefined behavior.

Suggested Fix

It is safe to zero-initialize the newly allocated buffer before read_exact(), in order to prevent user-provided code from accessing old contents of the newly allocated heap memory.

Also, there are two nightly features for handling such cases.

  • #404
  • https://rust-lang.github.io/rfcs/2930-read-buf.html

Thank you for checking out this issue :+1:

cwfitzgerald

cwfitzgerald

type: bug
Comment Icon1

Description

When reporting gfx-rs/wgpu#1129, I noticed that the debug names of most d3d12 objects were totally corrupt, consisting of random characters.

Repro steps

Run any example in the debugger then look at the "Live Object" warnings at the end.

Expected vs observed behavior

Expected: reasonable debug names Observerved: garbage

tangmi

tangmi

type: feature
Comment Icon0

Gfx-rs recently got mesh shader support (#3236) on Vulkan (#3253) and this issue is intended to track adding similar support on DX12.

Mesh shading was added to DX12 as a part of "DirectX 12 Ultimate" (and the mesh shader spec).

Note that mesh shaders were initially supported on:

  • AMD RDNA2 (RX 6000-series)
  • NVidia Turing (GTX 16-series, RTX 20-series)
kvark

kvark

type: feature
Comment Icon1

The main problem with the old DOWNLOAD type, which got removed in #3514, was that invalidating it resulted in a pipeline stall, since we need to submit that to a queue as a command. Perhaps, instead we can do the following:

  • re-enable the type in the same way it existed
  • invalidate() would do nothing
  • the transition from anything to HOST_READ access would be implemented as synchronize_resource

I'm not 100% sure that this is a valid implementation, but it sounds like it could be one, and it wouldn't include any stalls.

kvark

kvark

status: ready for work
Comment Icon0

I think the index_buffer_role_change restriction should still allow transfers (i.e. TRANSFER_XXX). Here are the steps to get there:

First, in add_memory_type function we'd need to have something like:

Secondly, in queue.rs when CopyBufferToBuffer and friends are implemented, they need to respect the bind points of the buffers. Currently, they use COPY_READ_BUFFER and COPY_WRITE_BUFFER unconditionally. Instead, these would need to be passed in.

yzsolt

yzsolt

type: feature
Comment Icon1

(Follow up of https://github.com/gfx-rs/gfx/pull/3499)

Although the DX12 backend sets the debug name of CommandBuffers by calling SetName on the underlying GraphicsCommandList, it doesn't show up in the tested graphics debuggers (RenderDoc, PIX). Baldur Karlsson (RenderDoc author) explained why:

command buffers are inherently transient, and the lifetime of when exactly the name should be applied is a little unclear. They are better annotated using markers rather than names, if you want to have a global name for the command buffer you could insert it as a marker as the first command

Markers are already set by the DX12 backend to mark bound descriptor sets, so the initial pieces are there if we want to take this route.

tuanzijiang

tuanzijiang

api: pre-ll
Comment Icon6

Short info header:

  • GFX version: pre-ll
  • OS: Windows10
  • GPU: Intel UHD 630

Running the cube example which works fine except when I try to resize the window. It gives me the following error: [2020-11-17T14:08:20Z ERROR gfx_window_dxgi] Resize failed with code 887A0001 [2020-11-17T14:08:20Z ERROR gfx_app] Resize failed: The RTV cannot be changed due to the references to it existing image

kvark

kvark

type: optimization
Comment Icon0

Currently, the GL backend is built in such a way that we copy the full frame on present(). This is a waste of fill-rate and performance that we've been trying to eliminate. The plan was to modify surfman in a mystical way that would let us do this - https://github.com/servo/surfman/issues/202. However, digging into EGL as well as asking around on Khronos slack proved this to be impossible. The best we can do is - avoid context sharing in GL. So the problem of copy on present remains unsolved.

I've been thinking that perhaps in most cases where the swapchain is used, there should be no need for a copy at all. Most applications would render to the swapchain image in a single pass, and the depth is discarded after it. So what if we create the EGL surface with all of color, depth, stencil, just in case, and try to use it aggressively? Given the render pass boundaries in this API, it seems like it could cover most cases:

Cases

Case A: rendering to color only. GL backend sees that an application only renders to the color, it binds the main framebuffer, and the copy is avoided.

Case B: rendering to color and depth, the depth is cleared and discarded at the end. We see the clear+discard on the depth, and we figure out that we don't actually need to consider the user-provided depth image. So we just use the default framebuffer again, and the copy is avoided.

Case C: rendering to color and depth, depth is test-only, loaded from a depth pre-pass. We see that the depth is discarded, so we can use the default framebuffer. However, we also see that the depth is loaded, so we issue a copy from the user-provided depth into the main FBO depth, first, before starting a pass.

Case D: rendering to color and depth, and depth is stored (not discarded). We proceed with the logic of B/C, but after the pass we issue a copy from the framebuffer depth to the user-provided depth.

Case X: rendering with other colors alongside the swapchain. I don't see how we can reasonably support that in GL backend. We'll have to document and assert on that.

Case Y: user-provided depth is not a 24-bit depth. I don't think we can deal with that, unfortunately.

Analysis

This requires some logic to be implemented, for tight integration between EGL and rendering. The benefit is avoiding the copy of color in all cases. However, another cost is that some cases would involve a copy of the depth, which roughly have the same size...

kvark

kvark

type: bug
Comment Icon2

It looks like glCopyBufferSubDatais forbidden when either of the buffers is mapped. This conflicts with our CPU-visible memory in GL that's backed by a persistently mapped buffer. It's quite strange that we are allowed to do anything with such a buffer except for copying from/to it?

Information - Updated Sep 11, 2022

Stars: 5.2K
Forks: 570
Issues: 332

Repositories & Extras

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

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

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)

OpenGL test in Rust

Personal to learn OpenGL and graphics programming

OpenGL test in Rust

Morph (Rust Game Development)

I started a game developed completely in Rust with OpenGL

Morph (Rust Game Development)

OpenGL Superbible - Rust Examples

This is my repository for keeping the OpenGL examples as I work through

OpenGL Superbible - Rust Examples
Facebook Instagram Twitter GitHub Dribbble
Privacy