577: Fixes#575 - vulkan-portability feature on MacOS r=kvark a=rybertm
See #575.
This PR fixes the issue with enabling `vulkan-portability` on MacOS.
Co-authored-by: Robert Broketa <robertbroketa@gmail.com>
574: Implement AsRef for BufferView r=kvark a=de-vri-es
This PR implements `AsRef` and `AsMut` in addition to `Deref` and `DerefMut` for `BufferView` and `BufferViewMut`.
This allows the buffer views to be used directly by generic code that wants an `AsRef<[u8]>`.
It's also subjectively a small win when you want to pass the views to non-generic code. I find `buffer.as_ref()` clearer than `&*buffer`. That also goes for `buffer.deref()`, but `Deref` is not in the prelude.
Co-authored-by: Maarten de Vries <maarten@de-vri.es>
576: Convert swapchain.get_current_frame to a immutable reference r=kvark a=cwfitzgerald
Per our discussion on matrix, converts swapchain.get_current_frame to an immutable reference as it's internally synchronized.
Rationale: will allow me to take a non-pretty RW mutex as read instead of write in my application
Co-authored-by: Connor Fitzgerald <connorwadefitzgerald@gmail.com>
570: web: temporarily polyfill `create_buffer_init` r=kvark a=grovesNL
Temporarily polyfill `create_buffer_init` on the web backend by using the old buffer mapping API. This is just a temporary fix until the new buffer mapping API is available in Nightly.
This polyfill allows us to run `cube` from `master` on Nightly (there's still lots missing from other examples). But at least some simple use cases (e.g. projects only using `create_buffer_init`/`write_buffer` and no other buffer mapping functions) can run with `master`.
Co-authored-by: Joshua Groves <josh@joshgroves.com>
569: Reorder framework canvas setup for web r=kvark a=grovesNL
winit only appends the canvas element once the window is built, and we need the canvas to exist before `create_surface` can use it. So we can just reorder the calls to build the window before using `create_surface` on the web backend in framework.
Also temporarily no-op debug markers for the web until we have them in gecko. Even though they're technically unimplemented, we can still proceed without them.
Co-authored-by: Joshua Groves <josh@joshgroves.com>
567: Notes on LoadOp r=kvark a=PENGUINLIONG
If the swapchain image was drawn with a pipeline that loads a render target that has not been cleared before, the validation layer gives a triplet of confusing feedbacks:
```log
[2020-09-15T06:42:23Z ERROR gfx_backend_vulkan]
VALIDATION [UNASSIGNED-CoreValidation-DrawState-InvalidImageLayout (1303270965)] : Validation Error: [ UNASSIGNED-CoreValidation-DrawState-InvalidImageLayout ] Object 0: handle = 0x1d80787bfe8, type = VK_OBJECT_TYPE_COMMAND_BUFFER; | MessageID = 0x4dae5635 | Submitted command buffer expects VkImage 0x6dc7200000000005[] (subresource: aspectMask 0x1 array layer 0, mip level 0) to be in layout VK_IMAGE_LAYOUT_PRESENT_SRC_KHR--instead, current layout is VK_IMAGE_LAYOUT_UNDEFINED.
object info: (type: COMMAND_BUFFER, hndl: 2027350900712)
[2020-09-15T06:42:23Z ERROR gfx_backend_vulkan]
VALIDATION [UNASSIGNED-CoreValidation-DrawState-InvalidImageLayout (1303270965)] : Validation Error: [ UNASSIGNED-CoreValidation-DrawState-InvalidImageLayout ] Object 0: handle = 0x1d8078586a8, type = VK_OBJECT_TYPE_COMMAND_BUFFER; | MessageID = 0x4dae5635 | Submitted command buffer expects VkImage 0x3ba5830000000006[] (subresource: aspectMask 0x1 array layer 0, mip level 0) to be in layout VK_IMAGE_LAYOUT_PRESENT_SRC_KHR--instead, current layout is VK_IMAGE_LAYOUT_UNDEFINED.
object info: (type: COMMAND_BUFFER, hndl: 2027350754984)
[2020-09-15T06:42:23Z ERROR gfx_backend_vulkan]
VALIDATION [UNASSIGNED-CoreValidation-DrawState-InvalidImageLayout (1303270965)] : Validation Error: [ UNASSIGNED-CoreValidation-DrawState-InvalidImageLayout ] Object 0: handle = 0x1d8078614f8, type = VK_OBJECT_TYPE_COMMAND_BUFFER; | MessageID = 0x4dae5635 | Submitted command buffer expects VkImage 0x4c5b620000000007[] (subresource: aspectMask 0x1 array layer 0, mip level 0) to be in layout VK_IMAGE_LAYOUT_PRESENT_SRC_KHR--instead, current layout is VK_IMAGE_LAYOUT_UNDEFINED.
object info: (type: COMMAND_BUFFER, hndl: 2027350791416)
```
And it turns out they come from the triple-buffering swapchain images. It seems `wgpu` would only re-layout the swapchain image if it's been loaded by a clear op. I would be great to warn the users beforehand. (I know it's not something I should ever do tho)
Co-authored-by: PENGUINLIONG <admin@penguinliong.moe>
565: Add context to errors r=kvark a=scoopr
ContextError is just a simple wrapper that contains a string and the original error, and it is used to decorate the error to give it more context.
Co-authored-by: Mikko Lehtonen <scoopr@iki.fi>
562: More errorsinkifying r=kvark a=scoopr
Continuing on with errorsinkifying more places, these wrap Buffer, Texture and CommandEncoder with a struct that includes the `error_sink`, and uses it for the error handling.
I think most of the apis are errorsinkified with this. The remaining ones may need some more thinking.
Queue would be wrapped mostly for the submit, the write_ stuff could in theory piggyback on the texture/buffer error-sink.
Others like swapchain, some mapping stuff, etc. needs some discussion or other implementation work.
Co-authored-by: Mikko Lehtonen <scoopr@iki.fi>
563: Document bind buffer alignment r=kvark a=kvark
Fixes #561
Also updates wgpu dependency to latest, and our exampels are now fully validated for the shader interface 🎉 .
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
557: Pin web-sys version r=grovesNL a=rukai
As mentioned in https://github.com/gfx-rs/wgpu-rs/pull/553 this will prevent the wasm build from breaking.
@grovesNL Is pinning just web-sys and wasm-bindgen sufficient?
Co-authored-by: Rukai <rubickent@gmail.com>
555: Update to latest web-sys r=kvark a=grovesNL
Cherry-pick #497 into `master` now that new versions of web-sys/wasm-bindgen/js-sys/wasm-bindgen-futures are published.
We could also do this for `v0.6` too if we want CI to succeed there, or alternatively consider disabling CI for wasm builds on `v0.6`.
Co-authored-by: Joshua Groves <josh@joshgroves.com>
