Describe the bug
When Vulkan is included in the Windows rendering backend list, Avalonia may select Vulkan even when it is not usable, without successfully falling back to the next configured backend.
I reproduced this with an Avalonia application running in Windows ARM64 under Parallels Desktop.
The configured rendering order is:
RenderingMode =
[
Win32RenderingMode.AngleEgl,
Win32RenderingMode.Vulkan,
Win32RenderingMode.Wgl,
Win32RenderingMode.Software
]
I observed two different failure modes with different Parallels versions:
Older Parallels Desktop
Vulkan initialisation causes a native access violation of 0xc0000005, with the stack including:
Avalonia.Vulkan.Interop.VulkanDevice.Create
Avalonia.Vulkan.VulkanPlatformGraphics.TryCreate
Avalonia.Vulkan.VulkanSupport.TryInitialize
The process terminates before WGL or Software can be tried.
On the latest version of Parallels Desktop 27, the application launches and the window is displayed, but the UI is incomplete: text/content is missing, including on the Settings page. Avalonia appears to continue using the problematic rendering path rather than falling back to WGL. As a control, explicitly removing Vulkan as follows produces a fully functional UI in both environments:
RenderingMode =
[
Win32RenderingMode.AngleEgl,
Win32RenderingMode.Wgl,
Win32RenderingMode.Software
]
To Reproduce
- Run Windows ARM64 in Parallels Desktop.
- Run an Avalonia application with:
RenderingMode =
[
Win32RenderingMode.AngleEgl,
Win32RenderingMode.Vulkan,
Win32RenderingMode.Wgl,
Win32RenderingMode.Software
]
- Start the application.
- Depending on the Parallels version:
- the application may terminate with 0xc0000005 during Vulkan initialisation, or
- the application may launch with incomplete/missing UI rendering.
- Change the rendering modes to:
RenderingMode =
[
Win32RenderingMode.AngleEgl,
Win32RenderingMode.Wgl,
Win32RenderingMode.Software
]
- The complete UI is rendered correctly.
Expected behavior
When a rendering backend is unable to provide usable rendering, Avalonia should gracefully fall back to the next configured backend.
For example, in this case, we have:
ANGLE
↓
Vulkan → unusable
↓
WGL → usable
The application should not either terminate during Vulkan initialisation or remain on a rendering backend that produces an incomplete UI when a subsequent configured backend works correctly.
The tested environment is as follows:
- Windows 11 ARM64 VM running on Parallels Desktop 20 and Parallels Desktop 27
- Avalonia 12.1.1
- .NET 10
- Runtime: win-arm64 and win-x64 (This problem occurs in both arm64 and x64 builds, so it is not merely for arm64.)
- GPU: Parallels Display Adapter (WDDM)
Avalonia version
12.1.1
OS
Windows
Additional context
The underlying incompatibility may be in the Parallels virtual GPU/driver, but the fallback behaviour appears to be the more general issue.
WGL provides a working hardware-accelerated rendering path in both environments, so this can be reproduced without resorting to software rendering. Because software rendering is also working well, falling back to it can also be the last resort even if WGL is not working.
Describe the bug
When Vulkan is included in the Windows rendering backend list, Avalonia may select Vulkan even when it is not usable, without successfully falling back to the next configured backend.
I reproduced this with an Avalonia application running in Windows ARM64 under Parallels Desktop.
The configured rendering order is:
I observed two different failure modes with different Parallels versions:
Older Parallels Desktop
Vulkan initialisation causes a native access violation of 0xc0000005, with the stack including:
The process terminates before WGL or Software can be tried.
On the latest version of Parallels Desktop 27, the application launches and the window is displayed, but the UI is incomplete: text/content is missing, including on the Settings page. Avalonia appears to continue using the problematic rendering path rather than falling back to WGL. As a control, explicitly removing Vulkan as follows produces a fully functional UI in both environments:
To Reproduce
Expected behavior
When a rendering backend is unable to provide usable rendering, Avalonia should gracefully fall back to the next configured backend.
For example, in this case, we have:
ANGLE
↓
Vulkan → unusable
↓
WGL → usable
The application should not either terminate during Vulkan initialisation or remain on a rendering backend that produces an incomplete UI when a subsequent configured backend works correctly.
The tested environment is as follows:
Avalonia version
12.1.1
OS
Windows
Additional context
The underlying incompatibility may be in the Parallels virtual GPU/driver, but the fallback behaviour appears to be the more general issue.
WGL provides a working hardware-accelerated rendering path in both environments, so this can be reproduced without resorting to software rendering. Because software rendering is also working well, falling back to it can also be the last resort even if WGL is not working.