-
-
Notifications
You must be signed in to change notification settings - Fork 276
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Vulkan renderer #1163
Open
spencercw
wants to merge
38
commits into
gnif:master
Choose a base branch
from
spencercw:vulkan
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Add Vulkan renderer #1163
Conversation
This file contains 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
|
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=1
tocmake
when building the Looking Glass client. You may need to installluajit
if cimgui binding generation fails.Using the Vulkan renderer
Pass
app:renderer=Vulkan
tolooking-glass-client
to use the Vulkan renderer.I also recommend initially passing
vulkan:validate=true
to enable the Vulkan validation layer. If any validation errors are logged to the console, please let me know.Using HDR
Requirements
looking-glass-client
with the environment variableENABLE_HDR_WSI=1
to enable the above Vulkan layerlooking-glass-client
with 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 ↩