1673: hal/vk: relay semaphore r=Ralith a=kvark
**Connections**
Somewhere on the Matrix, by @pythonesque
**Description**
Vulkan (somewhat confusingly) requires semaphore synchronization between `vkQueueSubmit` and `vkQueuePresent` *even if* it's done on the same queue.
This PR exercises a dumb idea of just keeping one binary semaphore as a "relay" between all queue commands, all concealed within hal/vk backend.
**Testing**
Running Halmark shows that all the things break here. I'm not seeing anything particularly wrong with the code though. My humble guess is that AMD driver (at least) isn't happy about the mix of binary and timeline semaphores used together in the same signal operation.
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
1671: Use EGL_KHR_gl_colorspace for srgb if available r=kvark a=cwfitzgerald
**Connections**
Fixes#1667
**Description**
Uses the extension to provide SRGB if needed relevant.
I also promoted the log message about missing robustness to a warning because it is a safety issue.
**Testing**
Tested on rpi and haswell.
Co-authored-by: Connor Fitzgerald <connorwadefitzgerald@gmail.com>
1664: hal/dx12: reset scissor and viewport r=kvark a=kvark
**Connections**
Follow-up to #1602 that actually makes it render!
**Description**
"hello-triange" and "msaa-line" examples work now.
Everything else is blocked on Naga's HLSL output, starting from https://github.com/gfx-rs/naga/pull/1086
**Testing**
Ran the examples :)
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
1663: hal/dx12: flip the root signature upside down r=kvark a=kvark
**Connections**
Another follow-up to #1602
**Description**
Apparently, Microsoft recommends putting most frequently changed stuff at the bottom of root signature.
**Testing**
Unable to test yet.
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
1661: dx12/hal: invalidate root elements on signature change r=kvark a=kvark
**Connections**
A follow-up to #1602, which I hesitated to implement, but now it doesn't sound like there is any choice we have.
**Description**
D3D12's root signature is internally mapped to device's physical descriptors. But this mapping isn't guaranteed to have any properties. That is, any changes to the root signature mean that all of the bound resources need to be invalidated...
It's a bit unfortunate. gfx-backend-dx12 did a lazy flushing approach at draw call. In wgpu-hal I tried to be more aggressive, and we are rebinding everything as it goes. We can choose to go lazy if we want - this PR introduces the necessary logic and infrastructure to do so.
**Testing**
Untested.
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
1658: Removes nightly from bors r=kvark a=cwfitzgerald
**Connections**
Following up on the trouble #1654 had merging. We actually shouldn't force bors to wait for nightly to work.
Co-authored-by: Connor Fitzgerald <connorwadefitzgerald@gmail.com>
1655: hal/vulkan: Respect swapchain's minImageCount r=kvark a=Bobo1239
**Description**
Respect `minImageCount` from the `VkSwapchainCreateInfoKHR` struct. Previously wgpu caused Vulkan validation errors like this:
```
[2021-07-14T17:15:18Z ERROR wgpu_hal::vulkan::instance] VALIDATION [VUID-VkSwapchainCreateInfoKHR-minImageCount-01271 (0xe18476f3)]
Validation Error: [ VUID-VkSwapchainCreateInfoKHR-minImageCount-01271 ] Object 0: handle = 0x5595501a6190, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0xe18476f3 | vkCreateSwapchainKHR() called with minImageCount = 3, which is outside the bounds returned by vkGetPhysicalDeviceSurfaceCapabilitiesKHR() (i.e. minImageCount = 4, maxImageCount = 0). The Vulkan spec states: minImageCount must be greater than or equal to the value returned in the minImageCount member of the VkSurfaceCapabilitiesKHR structure returned by vkGetPhysicalDeviceSurfaceCapabilitiesKHR for the surface (https://github.com/KhronosGroup/Vulkan-Docs/search?q=)VUID-VkSwapchainCreateInfoKHR-minImageCount-01271)
```
(Wayland with AMD RADV POLARIS10 (ACO))
**Testing**
Validation error doesn't get emitted anymore.
Co-authored-by: Boris-Chengbiao Zhou <bobo1239@web.de>
1652: Switch read-only storage textures to be exclusive and behind a feature r=cwfitzgerald a=kvark
**Connections**
See https://github.com/gpuweb/gpuweb/pull/1864 and https://github.com/gpuweb/gpuweb/pull/1794
**Description**
WebGPU API doesn't have RO storage textures right now. However, since `wgpu` already had a way to expose read-write storage textures, I figured we can just use it to gate read-only storage.
**Testing**
No examples currently exercise this path.
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
1651: Fix Vulkan Backend Texture Format Mapping r=cwfitzgerald a=zicklag
Fixes the Bgra8UnormSrgb texture format.
**Connections**
Resolves#1646.
**Description**
Fixes the mappings between the `Bgra8UnormSrgb` and `Bgra8Unorm` texture formats and their Vulkan equivalents.
**Testing**
Tested on my Ubuntu 20.04 machine on:
- Intel(R) UHD Graphics (CML GT2) (Vulkan)
- GeForce GTX 1650 (Vulkan)
Co-authored-by: Zicklag <zicklag@katharostech.com>
1602: New DX12 backend (unfinished) r=kvark a=kvark
**Connections**
Continuation of #1471
**Description**
Mostly fresh implementation on DX12 backend for wgpu-hal
Core changes:
- texture usage is filtered before passing to `create_texture_view`, so that wgpu-hal can assume every bit is important.
- all the copies involving textures are limited to one array layer at a time
- remove render pass boundary usages
**Testing**
Examples (not running yet)
Co-authored-by: Dzmitry Malyshau <dmalyshau@mozilla.com>
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
1647: Check for blendable flag in filtering r=cwfitzgerald a=kvark
**Connections**
Discussion on the matrix.
**Description**
The validation is written in a way that considers "filterable" to be responsible for both linear sampling and rendering.
But we didn't take blending into account when determining this filtering flag.
**Testing**
Untested
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
1645: Disable Intel Fastclear in GL Backend r=kvark a=zicklag
This works around a Mesa bug on Intel cards:
- https://gitlab.freedesktop.org/mesa/mesa/-/issues/2565
- https://github.com/gfx-rs/wgpu/issues/1627#issuecomment-877854185
**Connections**
Related to pixelated edges in GL backend brought up in #1627.
**Description**
This just adds the `INTEL_DEBUG=nofc` environment variable setting when creating an `Instance` using the GL backend in `wgpu_hal`. This is just a workaround until the mesa bug is fixed.
I wanted to wait until adapters were enumerated to determine that the user wanted to use an Intel Mesa adapter, but the environment variable has to be set before the x11 display was opened so that wasn't an option.
This may not be the strategy we want to take with this one, but it seems relatively harmless. Because the environment variable prefixed with `INTEL` anyway, it might not effect devices other than the ones we want to, which would be good.
**Testing**
I tested this on Ubuntu 20.04 with Mesa Intel(R) UHD Graphics (CML GT2) on using the GL backend.
Co-authored-by: Zicklag <zicklag@katharostech.com>
1644: Fix Example Resolution Limits r=kvark a=cwfitzgerald
**Connections**
Closes#1616.
**Description**
This change automatically expands resolution to the adapter's limits so examples always work.
**Testing**
Ran locally, but couldn't make it bigger than the screen
Co-authored-by: Connor Fitzgerald <connorwadefitzgerald@gmail.com>
1643: Check docs in CI r=kvark a=cwfitzgerald
**Connections**
Closes#1637.
**Description**
Doc links will now fail. `cargo doc` doesn't let you pass through flags, so you have to use RUSTDOCFLAGS.
**Testing**
It is.
Co-authored-by: Connor Fitzgerald <connorwadefitzgerald@gmail.com>
