Current copy-prop of swizzle instructions can result in infinite loops,
as with the included test before this commit.
Consider the following sequence of instructions where a load is stored
in the same variable it loads:
1 : A
2 : A = @1
3 : @1.x
In this case @3 would call copy_propagation_get_value() on A.x and
would get @1, without detecting that that is indeed the same node
it is already using as swizzle->value. So it would return true,
keeping copy-prop spinning.
To avoid this, it is check that the replacement instruction is not the
same as the swizzle->load instruction.
---
This was discovered when trying to compile shaders from [Bug 19499](https://www.codeweavers.com/support/bugs/browse?cmd=bug_edit;bug_id=….
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/482
--
v8: vkd3d-shader/dxil: Implement the DXIL LOAD instruction.
vkd3d-shader/dxil: Implement the DXIL GEP instruction.
vkd3d-shader/dxil: Support global variable initialisers.
vkd3d-shader/dxil: Introduce a value type for immediate constant buffers.
vkd3d-shader/dxil: Implement default address space global variables.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/471
--
v3: Revert "vkd3d-shader/hlsl: Do not prioritize an exact match when looking up functions."
vkd3d-shader/hlsl: Discern between signed and unsigned ints when parsing.
tests: Test overloads with signed and unsigned numeric values.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/478
This is the first of (tentatively) 3 MRs that add Vulkan support to the Wayland driver. Here is the proposed breakdown:
* part 10.1 (this one): Basic setup and VkSurfaceKHR integration
* part 10.2: VkSwapchainKHR integration
* part 10.3: Everything else (mostly passthrough implementations of other Vulkan functions)
I chose to go with Vulkan first, instead of OpenGL, since the integration is more straightforward, and allows us to implement required core driver changes (which will also be used for OpenGL later) with fewer distractions.
Please note that all 3 parts need to land before the Vulkan support is actually usable in applications/games. I have uploaded the full (tentative) series for people that want to take a look or try out the final state: https://gitlab.winehq.org/afrantzis/wine/-/tree/wayland-part-10
Finally, part 10 is not based on part 9, so they can land in either order. However, there are interactions and conflicts between the two, so whichever part lands last will need to be (slightly) adapted. Note, though, that without part 9, some things won't work well on scaled outputs (esp. fullscreen).
Thanks!
--
v2: winewayland.drv: Forward all client surface pointer events to parent.
winewayland.drv: Set client area subsurface size.
winewayland.drv: Set client area subsurface position.
winewayland.drv: Use a client area subsurface as the Vulkan target.
winewayland.drv: Implement vkDestroySurfaceKHR.
winewayland.drv: Implement vkCreateWin32SurfaceKHR.
winewayland.drv: Implement vkGetDeviceProcAddr and vkGetInstanceProcAddr.
winewayland.drv: Implement vkDestroyInstance.
winewayland.drv: Implement vkCreateInstance.
winewayland.drv: Implement vkEnumerateInstanceExtensionProperties.
winewayland.drv: Add skeleton Vulkan driver.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4340