Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

API Issue for Renderer #545

Open
DasLixou opened this issue Apr 6, 2024 · 0 comments
Open

API Issue for Renderer #545

DasLixou opened this issue Apr 6, 2024 · 0 comments

Comments

@DasLixou
Copy link
Collaborator

DasLixou commented Apr 6, 2024

See original discussion on zulip here

The current API which can be seen in the examples suggests that there should be one Renderer per wgpu::Device.
This can be a problem when you have one gpu which supports and must handle multiple surface formats, which can happen when having multiple windows on multiple monitors of different formats (i think).
Because I don't have multiple monitors, I helped a bit in code with this patch on the with_winit example:
force_different_surface_format.patch
I saw that my window expects Rgba8Unorm and forced it to use Bgra8Unorm.
After running, the program crashes with the following error:

Rgba8Unorm
Initialising in parallel using 6 threads
Parsed svg Ghostscript_Tiger in 18.0366ms
Encoded svg Ghostscript_Tiger in 3.6642ms
[2024-04-06T11:03:40.934Z ERROR wgpu::backend::wgpu_core] Handling wgpu errors as fatal by default
thread 'main' panicked at C:\Users\lixou\.cargo\registry\src\index.crates.io-6f17d22bba15001f\wgpu-0.19.3\src\backend\wgpu_core.rs:3006:5:
wgpu error: Validation Error

Caused by:
    In a RenderPass
      note: encoder = `<CommandBuffer-(0, 2, Vulkan)>`
    In a set_pipeline command
      note: render pipeline = `<RenderPipeline-(0, 1, Vulkan)>`
    Render pipeline targets are incompatible with render pass
    Incompatible color attachments at indices [0]: the RenderPass uses textures with formats [Some(Rgba8Unorm)] but the RenderPipeline uses attachments with formats [Some(Bgra8Unorm)]


note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
error: process didn't exit successfully: `target\debug\with_winit_bin.exe` (exit code: 101)

From conversation on zulip linked at the top, the idea of removing the manual Vec<Option<Renderer>> list and moving it into the RenderContext to hide the selection of a renderer to the end user came up.
It is open to debate whether we want multiple renderers over one device, which needs us to change the basic Vec<Option<_>> solution, or supplying the surface format on render command (Daniel thinks that the surface format is only needed for the blit pipeline), or something not mentioned here.

Another interesting think is what happens when a window gets created with one surface_format and then gets moved to another monitor which is HDR (I am not sure what the OS does there and if we need to dynamically change the surface_format, what is when it is split up between two monitors? Would be great to know if there are any OS Resources documenting that).

@waywardmonkeys waywardmonkeys added this to the Vello 0.2 release milestone May 3, 2024
@waywardmonkeys waywardmonkeys removed this from the Vello 0.2 release milestone May 14, 2024
@DJMcNab DJMcNab added this to the Vello 0.4 Release milestone Oct 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants