Add Vulkan renderer #1163
Open
Add Vulkan renderer #1163
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Currently, the sRGB cursor image is rendered directly into the framebuffer, resulting in the cursor not matching the host white level when using HDR. The fixed-function blending capabilities are not really adequate for our purposes when using HDR. For standard color cursors it could work if we converted the entire framebuffer from non-linear RGBA10 to linear RGBA16, but that still doesn't help us with the other cursor types which require the ability to invert a pixel with reference to the current SDR white level. To work around this, add a subpass self-dependency and attach the swapchain image to the renderpass as both a color attachment and an input attachment. This allows us to first render the desktop into the color attachment, add a pipeline barrier to make the changes visible, then render the cursor, where we can read the rendered desktop image from the input attachment to manually blend it with the cursor.
The current logic simply adjusts for the SDR white level, so any true HDR content is lost. Use perceptual quantization so HDR content can be correctly rendered on the client.
Currently, the sRGB cursor image is rendered directly into the framebuffer, resulting in the cursor not matching the host white level when using HDR. The fixed-function blending capabilities are not really adequate for our purposes when using HDR. For standard color cursors it could work if we converted the entire framebuffer from non-linear RGBA10 to linear RGBA16, but that still doesn't help us with the other cursor types which require the ability to invert a pixel with reference to the current SDR white level. To work around this, add a subpass self-dependency and attach the swapchain image to the renderpass as both a color attachment and an input attachment. This allows us to first render the desktop into the color attachment, add a pipeline barrier to make the changes visible, then render the cursor, where we can read the rendered desktop image from the input attachment to manually blend it with the cursor.
ImGui is rendered assuming a standard SDR sRGB output, so it looks very bad when rendered into an HDR surface. Instead, render into an SDR surface, then manually blend the result into the output HDR surface while performing the necessary color space conversions.
The Vulkan present operation can currently be interrupted by the Wayland pointer handling code if it issues a commit at the same time, resulting in a protocol error.
This may be useful for diagnosing driver-related issues. For instance, the Wayland HDR Vulkan layer does not work with AMDVLK, but it does work with RADV.
This fixes a crash with the Intel driver when switching swapchain surface formats.
This avoids a potential race with the invocation of onFrameFormat on the frame thread.
|
Getting this if validation layers enabled |
|
Hi, on Ubuntu 24.10 build failed with: |
|
For me, window size cannot be changed, when resizing, it get malformed.
Running without vulkan enabled still works as expected. Also system is detected as Windows 10 but actually is Windows 11. |
|
Forcing full screen with -F parameter open small window which is hidden/minimized and cannot be opened. Moving to another monitor does not help.
This and above is with Below is with Window is small/cannot resize due to missing decorator (expected). When I toggle full screen with keyboard shortcut, window size stay same and Ubuntu toolbars got hidden (toolbar shoud be on left and top side).
When I force full screen by |
It works only with vulkan:validate=no, also log when launching with amd gpu (using validate=yes) Having issues that @Tony763 having with a window, but in my case I can force size of it in the client settings, and it's usable with sway |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds a new Vulkan renderer to complement the existing EGL renderer. It is usable, but incomplete, considered experimental, and disabled by default. Notably, it is currently slower than the EGL renderer owing to unimplemented DMA-BUF and damage rect support.
The primary motivation for this change is to bring true HDR support to Looking Glass, which is not currently possible via EGL.1
Building with Vulkan support
Pass
-DENABLE_VULKAN=1tocmakewhen building the Looking Glass client. You may need to installluajitif cimgui binding generation fails.Using the Vulkan renderer
Pass
app:renderer=Vulkantolooking-glass-clientto use the Vulkan renderer.I also recommend initially passing
vulkan:validate=trueto enable the Vulkan validation layer. If any validation errors are logged to the console, please let me know.Using HDR
Requirements
looking-glass-clientwith the environment variableENABLE_HDR_WSI=1to enable the above Vulkan layerlooking-glass-clientwith the environment variableAMD_VULKAN_ICD=RADV.Other HDR advice
The following advice is specific to KWin 6.3. Other compositors/versions may behave slightly differently.
Set the SDR content brightness to 31 in Windows. This is approximately equal to the reference luminance of 203 nits used by KWin, which should make SDR white content look identical to that of native Linux applications, and the difference between HDR on and off in Windows should be virtually indistinguishable when looking at SDR content.
Be aware that the 'Maximum SDR Brightness' setting within the KDE display configuration also affects HDR content.2 I recommend setting this to whatever brightness feels most comfortable, but it can be set to the reference level of 203 nits to most accurately reproduce the Windows output with minimal interference by KWin.
Footnotes
Theoretically, maybe it could be supported via extensions such as
EGL_EXT_gl_colorspace_bt2020_pq, but Mesa does not currently implement these. ↩https://zamundaaa.github.io/wayland/2024/11/06/hdr-and-color-management-in-kwin-part-5.html ↩