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

WIP - Transition graphics backend from vulkano to wgpu #452

Merged
merged 56 commits into from
Mar 3, 2020

Conversation

mitchmindtree
Copy link
Member

@mitchmindtree mitchmindtree commented Feb 16, 2020

This PR is a WIP overhaul of the graphics backend used throughout nannou! 🎂 🎉 🎈

See #446, #374, #408 for related issues and motivation.

Progress:

  • Create a wgpu branch.
  • Update nannou's winit dependency to version 0.21.
  • Add wgpu.rs module. Re-export wgpu and extend with helper items as we go.
  • Remove vk related state from App. Comment out loop functions for now.
  • Add draw::backend::wgpu with placeholder types.
  • Update window.rs swapchain and surface code to switch from vk to wgpu items.
  • Update the frame.rs module.
  • Remove vk.rs module.
  • Re-write the run_loop for changes to winit::EventLoop. We should no longer use poll_events, but instead use MainEventsCleared and RedrawRequested. This will likely require a full re-write. May be easiest to introduce one LoopMode at a time.
  • Update ui.rs module to use conrod_wgpu rather than conrod_vulkano.
  • Update draw.rs module. Update draw.rs module #440.
  • Check for DPI correctness in event conversion logic in event.rs. Some winit events have changed from emitting logical to physical positions/sizes.
  • Reconstruct swap chain and render data on resize.
  • Check dpi handling on hidpi display.
  • Add a wgpu::SamplerBuilder.
  • Add a wgpu::TextureBuilder.
  • Add map of wgpu::Devices to App. Allows for use of a single device across multiple windows. This is necessary to support sharing resources between windows.
  • Re-add depth buffer to Draw Renderer and test with 3D vertices.
  • Enable logging (this is how wgpu emits validation layer info). wgpu uses log, so users can add a logger like env_logger if they want to receive output for now.
  • Check that window and builder APIs are on par with latest winit.
  • Test moving window between different displays with different DPI scale factors.
  • Change vk examples directory to wgpu and update all examples.
    • wgpu_compute_shader
    • wgpu_image
    • wgpu_image_sequence
    • wgpu_teapot
    • wgpu_teapot_camera
    • wgpu_triangle
    • wgpu_triangle_raw_frame
    • wgpu_images
    • wgpu_compute_fractal (vk_compute_shader_rendering)
    • wgpu_hotload (vk_hotload)
    • wgpu_quad_warp (vk_quad_warp)
    • wgpu_debug (vk_debug - could probably just show how to enable logging here).
    • wgpu_shader_include (vk_shader_include)
  • Create screenshot.rs example.
  • Create screenshot_hi_res.rs example - drawing to a larger image independent of window size.
  • Module level docs for wgpu module.
  • Search for references to "vulkan"/"vulkano" throughout codebase.
  • Ensure CHANGELOG is up-to-date.
  • Test behaviour on all platforms. Take note of any build dependency changes since removal of shaderc/macos-vk and addition of spirv-cross.
  • Open a PR to update the guide with some info on wgpu. Refer to the existing wgpu tutorial and describe how the wgpu API is exposed through nannou, what nannou takes care of for you, etc.
  • Publish new version of nannou.
  • Improve application loop update timing. Find more info on get_next_texture() delays and wgpu swap chain behaviour. Consider semantic differences between RefreshSync and Rate now that PresentMode toggle is exposed in window builder. Will address this in a follow-up PR - see Improve loop timing and revisit LoopModes #456.
  • Add GL support feature to match wgpu examples. Test GL backend. This can wait - should keep track of Wgpu gl support gfx-rs/wgpu-rs#182.

Closes #187
Closes #197
Closes #261
Closes #293
Closes #306
Closes #307
Closes #312
Closes #314
Closes #319
Closes #336
Closes #348
Closes #350
Closes #352
Closes #354
Closes #356
Closes #357
Closes #365
Closes #372
Closes #373
Closes #374
Closes #392
Closes #408
Closes #412
Closes #422
Closes #433
Closes #438
Closes #440
Closes #446


Currently nannou compiles! That said, only a handful of the examples are working. The frame, app, window, event and vk (now wgpu) modules have been updated for wgpu and the latest version of winit. The draw and ui modules are yet to be updated, but shouldn't be too tricky considering we have the conrod_wgpu implementation as a reference.

cc @DavidPartouche @freesig


Update: ui and draw modules now updated!

Screenshot from 2020-02-18 07-28-10

This PR is an overhaul of the graphics backend used throughout nannou.

See nannou-org#446, nannou-org#374, nannou-org#408 for related issues and motivation.
The `simple_ui.rs` and `named_color_reference.rs` examples have been
tweaked slightly to allow for testing. They will be changed to their
original state once wgpu support for draw is implemented.
Fixes drawing behaviour when the window is resized.
Still need to enable the depth buffer and test with 3D.
Also re-exports the `wgpu` crate's `Texture` type as `TextureHandle`.

The new `Texture` type acts as a much more convenient handle around the
`wgpu::Texture`, providing access to the descriptor from which it was
created along with all the info it provides.

The new `TextureBuilder` type wraps the `TextureDescriptor` with a set
of reasonable defaults, allowing for more convenient texture
construction.
@mitchmindtree mitchmindtree changed the title WIP - Transition graphics backend from vulkano to winit WIP - Transition graphics backend from vulkano to wgpu Feb 22, 2020
This restructures management of wgpu adapters, devices and queues so
that devices and their queues can be automatically shared between
windows. This allows for easy sharing of GPU resources like textures and
buffers between multiple windows - very useful for multi-display
installations, projection mapping, etc.
Currently I'm getting some "GPU got stuck" errors which cause the window
to lock-up for a few seconds before causing the process to crash. Going
to enable logging to see if validation layers show any issues before
going further with this.
This fixes a crash I was running into in on Linux with Intel HD620.
Also adds methods for accessing the primary and available monitors to
the **App**.
This is useful for copying the swap chain texture for example.
This allows the user to ensure that the command buffer responsible for
drawing to the swap chain texture is submitted prior to the end of their
`view` function. This is necessary to allow the user to read back
buffers and textures involved in drawing to the texture at the end of
the `view` function. Without this change, it is not possible to do so in
nannou's current API.

The most significant user-impacting change is that the `view` functions
now take the `Frame` by value, rather than by reference.
This adds a suite of functionality for efficiently mapping texture data
and reading it from the CPU.

Highlights include:

- `TextureCapturer` to simplify the reading of textures into image file
  compatible formats. A `capture_hi_res.rs` example has been added to
  demonstrate.
- `window.capture_frame(path)` for writing the next frame to a file at
  the given path. A `simple_capture.rs` example has been added
  demonstrating this.

`TextureFormatConverter` has been renamed to `TextureReshaper` and
support has been added for converting both texture size and sample
count.
Also removes the remaining vulkan examples. We can always refer to these
from previous commits when we are ready to port them to the new wgpu
graphics backend.
This should avoid some confusion where users might wonder why their aync
reads/writes aren't happening when unaware that `device.poll` must be
called.
Previously a validation error was occurring due to passing a sampled
texture to the bind group without declaring that the texture was
multisampled in the fragment shader.

This adds some new multisampled shaders that correctly declare the
texture and do the multisampling resolve manually.

Dedicated shaders have been added for common sample counts with unrolled
loops to avoid having the shader deal with conditions based on uniform
data. A fallback shader is provided for all other sample counts.

Closes nannou-org#462.
This allows for specifying the window size of a sketch without having to
set the size within the `view` function every frame. Closes nannou-org#461.

Note that as a result of `nannou::sketch(view)` producing a builder
type, you now must call `.run()` to make the sketch do anything.

The `app::Builder` now also supports a `.size(w, h)` builder method for
specifying the default window width and height in points.
This makes the capture examples synchronous with the main thread in
order to avoid users' machines running out of RAM as was reported during
testing. Both examples now display a comment on how to get a speed up
via threading and mentions the potential memory usage caveats.

Specifically, this adds a `capture_frame_threaded` method to accompany
the `capture_frame` method.

This also changes the `TextureCapturer` to use all available CPUs by
default when `read_threaded` is called, rather than just 1.
mitchmindtree added a commit to mitchmindtree/guide that referenced this pull request Mar 3, 2020
The main change is the removal of a lot of vulkan related build
instructions on macOS and windows. Hopefully these platforms have been
simplified a lot now, though I imagine we might have to add a thing or
two following this big overhaul.

Code example updates are minor - mostly just changing `view` functions
to take `Frame` by value rather than by reference.

This commit requires nannou-org/nannou#452 is merged into main before
the book tests will pass for travis.
@mitchmindtree mitchmindtree merged commit 95c8dbd into nannou-org:master Mar 3, 2020
@mitchmindtree
Copy link
Member Author

Okydoky I think we're ready!

@JoshuaBatty
Copy link
Member

Epic work @mitchmindtree

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment