* [glsl-in] Implement swizzle for r-values
Related to #210
* [glsl-in] Just return Result from field_selection
Removed unneccessary Otion in return type
* [glsl-in] Always match on type in field_selection
* [glsl.in] Borrow by value in field_selection
940: Fixed typo in texture size check r=kvark a=Fruup
**Connections**
https://github.com/gfx-rs/wgpu/issues/937
**Description**
The texture's depth was omitted in the check.
**Testing**
No tests needed.
Co-authored-by: Leon Scherer <scherer-leon@web.de>
938: Remove erroneous extra feature check r=kvark a=cwfitzgerald
**Connections**
None, found during investigation of DI issue.
**Description**
This line of code just shows up twice in a row, checking the same feature and setting the same feature.
**Testing**
Untested, but shouldn't affect anything.
Co-authored-by: Connor Fitzgerald <connorwadefitzgerald@gmail.com>
935: Properly implement compute pass usage scopes r=cwfitzgerald a=kvark
**Connections**
Fixes#934Closes#933
**Description**
The old barriers in a compute pass were totally wrong. They didn't combine usages across the bind groups, or with indirect buffer.
This change implements the *actual* semantics as seen by the spec. At dispatch time we gather the usages across bind groups needed by the active pipeline, possibly add the indirect buffer into the mix, and that combined used is what we transition into.
I think we can find a few interesting ideas on how to make this faster. In particular - how to avoid a separate `TrackerSet` per pass. But for now correctness is more important.
**Testing**
Tested on wgpu-rs examples
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
There's no legend explaining what symbols mean for supported end-points, but it seems to be following the same format at wgpu. This PR copies wgpu's legend.
936: Prevent an invalid texture from being registered in device_create_texture r=kvark a=kunalmohan
**Connections**
_Link to the issues addressed by this PR, or dependent PRs in other repositories_
**Description**
_Describe what problem this is solving, and how it's solved._
Since we checked the usage of a `Feature` in `device_create_texture()` after registering the new `Id`, there could be a case where it returns an error after registering the texture as a valid one, which further panics when the client tries to register it as an `error_id`.
To solve this, the check for the usage of a `Feature` is now done before registering the new `Id`.
**Testing**
_Explain how this change is tested._
Tested with wgpu-rs examples and CTS in Servo.
<!--
Non-trivial functional changes would need to be tested through:
- [wgpu-rs](https://github.com/gfx-rs/wgpu-rs) - test the examples.
- [wgpu-native](https://github.com/gfx-rs/wgpu-native/) - check the generated C header for sanity.
Ideally, a PR needs to link to the draft PRs in these projects with relevant modifications.
See https://github.com/gfx-rs/wgpu/pull/666 for an example.
If you can add a unit/integration test here in `wgpu`, that would be best.
-->
Co-authored-by: Kunal Mohan <kunalmohan99@gmail.com>
* [glsl-in] consolidate tests
- remove simple lex test as was covered by others
- combine related tests to single function
- remove redundant prefix in test names
* [glsl-in] Consolidtae lex tests further
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>
* Added support for glsl core version up to 400
* Added 330 to the list supported versions
* Added links to all extensions and fixed a extension being wrongfully activated
* Cleanup and check for image formats
* Removed useless extension and location on layout
* Added support for external functions and fixed global names
* Typefier allow Scalars in distance and length
* Addressed comments
* Fixed extension appearing after body
* Fixed entry point not being generated
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>
