Closed Shootfast closed 10 months ago
Sorry but this appears to be either a fault external to LG, or you do not have enough copy performance to maintain a decent update rate at HDR causing issues with damage rect update information being lost by windows.
In any case, there is no point to using HDR as Linux has no support for it, you are just adding additional load to your system with no benefit.
The only suggestion I have is to update to bleeding edge, changes went in to support generic tone mapping to SDR for HDR content, the issue you are having may have been corrected.
I don't think it's copy performance as I still get the issue even when resizing the window down to 800x600 (where my system works fine in 8bit 3840x2160).
On my system I am able to benefit from HDR. Having the option enabled in Windows triggers applications to render in PQ/ST2084, and I can pass those 10 bit pixels directly through to my monitor where I can tell it to expect PQ encoded images.
What is lacking on Linux is general HDR/SDR window compositing, but this isn't an issue with fullscreen applications (or where I have another solution for compositing).
I don't want to tonemap SDR to HDR or vice versa, but I can perhaps try bleeding edge to see if the issue is still there.
I was not aware such a monitor existed, sounds like we need to make it possible to disable new tone mapping in bleeding edge. Please let me know how you go, you are right that at lower resolutions this should not be occurring. It still doesn't make much sense TBH though, we transfer the frames in horizontal lines as this is how the data is stored, if there was going to be a truncation of data it would happen horizontally, not vertically.
[EDIT: I will also try with bleeding edge soon, forgot I'm using B6-rc1]
I also have this issue too! I assumed it was something on the client side and was waiting for GNOME/mutter/wayland to catch up with correctly handling HDR surfaces... It's stopped me from using HDR on my gaming VM, which is a shame now that Steam Remote Play / Sunshine + Moonlight support HDR on my steamdeck when hooked up to my TV. I can either stream in HDR or interact with the VM via LG but I have to toggle HDR on/off.
Switching on HDR in the windows settings, it appears as though slightly less than half of each window is rendered. You can resize each window and it will predictably update the left 40% of it. The whole window will update every now and then (e.g every X seconds) - it appears more likely to correctly re-render when other windows are interacted with. Switching the video output off and on again gives me a correctly rendered frame too, but subsequent frames aren't rendered correctly. Combined with this, only the left 40% of the whole screen is rendered correctly for most frames. Alt-tabbing between windows or mousing over their start menu preview thumbnails causes a brief period of flickering and then the window contents are updated correctly.
Curiously, I switched on "Show damage overlay", and the regions are being calculated correctly - if I move or resize a window, the yellow EGL damage overlay corresponds to the regions of the screen that should be getting updated.
Performance is fine, and enabling/disabling HDR makes no appreciable difference to my overall framerate or the timing graphs.
My shmem size is 256M.
On the client, opengl renderer and egl renderer behave the same. egl:doubleBuffer
, egl:noBufferAge
and egl:noSwapDamage
make no difference.
I tried a game with HDR enabled in fullscreen (not borderless) mode (Cyberpunk 2077) which has options for both HDR10scRGB and HDR10PQ - the effect is the same; 40% of the game is rendered. Benchmark inside the game renders at the same stable FPS it was without HDR on.
Host startup log (Windows 11 virtual machine, RTX 3070, Philips TV, 1440p @ 60Hz, supports HDR10):
[I] 4488806181 app.c:385 | captureStop | ==== [ Capture Stop ] ====
[I] 4488820932 dxgi.c:390 | dxgi_init | Device Name : \\.\DISPLAY2
[I] 4488821243 dxgi.c:391 | dxgi_init | Device Description: NVIDIA GeForce RTX 3070
[I] 4488821571 dxgi.c:392 | dxgi_init | Device Vendor ID : 0x10de
[I] 4488821845 dxgi.c:393 | dxgi_init | Device Device ID : 0x2484
[I] 4488822121 dxgi.c:394 | dxgi_init | Device Video Mem : 8032 MiB
[I] 4488822690 dxgi.c:395 | dxgi_init | Device Sys Mem : 0 MiB
[I] 4488823233 dxgi.c:396 | dxgi_init | Shared Sys Mem : 11431 MiB
[I] 4488889570 dxgi.c:503 | dxgi_init | Feature Level : 0xc100
[I] 4488889940 dxgi.c:504 | dxgi_init | Capture Size : 2560 x 1440
[I] 4488890233 dxgi.c:505 | dxgi_init | AcquireLock : enabled
[I] 4488890523 dxgi.c:506 | dxgi_init | Debug mode : disabled
[I] 4488891896 dxgi.c:598 | dxgi_init | Source Format : DXGI_FORMAT_B8G8R8A8_UNORM
[I] 4488892240 dxgi.c:640 | dxgi_init | Request Size : 2560 x 1440
[I] 4488895277 dxgi.c:658 | dxgi_init | Output Size : 2560 x 1440
[I] 4488895727 dxgi.c:666 | dxgi_init | Copy backend : Direct3D 11
[I] 4488896021 dxgi.c:667 | dxgi_init | Damage-aware copy : enabled
Client startup (Fedora 38, GNOME on Wayland):
[I] 39160117604 main.c:1786 | main | Looking Glass (B6-rc1)
[I] 39160117617 main.c:1787 | main | Locking Method: Atomic
[I] 39160117948 cpuinfo.c:37 | lgDebugCPU | CPU Model: AMD Ryzen 9 5900X 12-Core Processor
[I] 39160117952 cpuinfo.c:38 | lgDebugCPU | CPU: 1 sockets, 12 cores, 24 threads
[I] 39160134470 main.c:1162 | lg_run | Using font: /usr/share/fonts/dejavu-sans-mono-fonts/DejaVuSansMono.ttf
[I] 39160134689 ivshmem.c:128 | ivshmemOpenDev | KVMFR Device : /dev/shm/looking-glass
[I] 39160136758 audio.c:159 | audio_init | Using AudioDev: PipeWire
[I] 39160136764 ps.c:245 | purespice_connect | Connecting to socket 127.0.0.1:5900
[I] 39160144770 rsa.c:178 | rsa_encryptPassword | Using Nettle
[I] 39160145064 ps.c:268 | purespice_connect | Connected
[I] 39160145141 agent.c:103 | agent_connect | Connected to the spice guest agent
[I] 39160145169 channel_main.c:167 | onMessage_mainName | Guest name: windows
[I] 39160145177 channel_main.c:183 | onMessage_mainUUID | Guest UUID: daf2f46b-9476-4ba6-9dbc-e34463a2a7ae
[I] 39160153205 ps.c:644 | ps_connectChannel | INPUTS channel connected
[I] 39160153293 egl.c:267 | egl_initialize | Double buffering is off
[I] 39160153299 main.c:1116 | tryRenderer | Using Renderer: EGL
[I] 39160153346 channel.c:312 | onMessage_notify | [notify] keyboard channel is insecure
[W] 39160153598 idle.c:31 | waylandIdleInit | zwp_idle_inhibit_manager_v1 not exported by compositor, will not be able to suppress idle states
[I] 39160175522 gl.c:58 | waylandGetEGLDisplay | Using eglGetPlatformDisplay
[I] 39160201140 egl.c:828 | egl_renderStartup | Single buffer mode
[I] 39160202639 egl.c:855 | egl_renderStartup | EGL : 1.5
[I] 39160202644 egl.c:856 | egl_renderStartup | Vendor : AMD
[I] 39160202647 egl.c:857 | egl_renderStartup | Renderer: AMD Radeon Pro WX 2100 (polaris12, LLVM 16.0.6, DRM 3.54, 6.6.0-0.rc6.20231017gt213f8915.247.vanilla.fc38.x86_64)
[I] 39160202650 egl.c:858 | egl_renderStartup | Version : OpenGL ES 3.2 Mesa 23.1.8
[I] 39160202653 egl.c:859 | egl_renderStartup | EGL APIs: OpenGL OpenGL_ES
[I] 39160202661 egl.c:930 | egl_renderStartup | Debug messages disabled, enable with egl:debug=true
[I] 39160209202 postprocess.c:133 | loadPresetList | Found preset: windows1080
[I] 39160236287 eglutil.c:35 | swapWithDamageInit | Using EGL_KHR_swap_buffers_with_damage
After switching HDR on on host:
[I] 4986907650 dxgi.c:390 | dxgi_init | Device Name : \\.\DISPLAY2
[I] 4986907968 dxgi.c:391 | dxgi_init | Device Description: NVIDIA GeForce RTX 3070
[I] 4986908290 dxgi.c:392 | dxgi_init | Device Vendor ID : 0x10de
[I] 4986908585 dxgi.c:393 | dxgi_init | Device Device ID : 0x2484
[I] 4986908867 dxgi.c:394 | dxgi_init | Device Video Mem : 8032 MiB
[I] 4986909148 dxgi.c:395 | dxgi_init | Device Sys Mem : 0 MiB
[I] 4986909431 dxgi.c:396 | dxgi_init | Shared Sys Mem : 11431 MiB
[I] 4986973156 dxgi.c:503 | dxgi_init | Feature Level : 0xc100
[I] 4986973446 dxgi.c:504 | dxgi_init | Capture Size : 2560 x 1440
[I] 4986973746 dxgi.c:505 | dxgi_init | AcquireLock : enabled
[I] 4986974026 dxgi.c:506 | dxgi_init | Debug mode : disabled
[I] 4986974788 dxgi.c:598 | dxgi_init | Source Format : DXGI_FORMAT_R16G16B16A16_FLOAT
[I] 4986975136 dxgi.c:640 | dxgi_init | Request Size : 2560 x 1440
[I] 4986977134 dxgi.c:658 | dxgi_init | Output Size : 2560 x 1440
[I] 4986977539 dxgi.c:666 | dxgi_init | Copy backend : Direct3D 11
[I] 4986977905 dxgi.c:667 | dxgi_init | Damage-aware copy : enabled
On client:
[I] 39506164187 main.c:698 | main_frameThread | Format: FRAME_TYPE_RGBA16F 2560x1440 stride:2560 pitch:20480 rotation:0
And then off again, on host:
[I] 5332654461 dxgi.c:390 | dxgi_init | Device Name : \\.\DISPLAY2
[I] 5332654766 dxgi.c:391 | dxgi_init | Device Description: NVIDIA GeForce RTX 3070
[I] 5332655102 dxgi.c:392 | dxgi_init | Device Vendor ID : 0x10de
[I] 5332655377 dxgi.c:393 | dxgi_init | Device Device ID : 0x2484
[I] 5332655750 dxgi.c:394 | dxgi_init | Device Video Mem : 8032 MiB
[I] 5332656037 dxgi.c:395 | dxgi_init | Device Sys Mem : 0 MiB
[I] 5332656314 dxgi.c:396 | dxgi_init | Shared Sys Mem : 11431 MiB
[I] 5332716700 dxgi.c:503 | dxgi_init | Feature Level : 0xc100
[I] 5332717276 dxgi.c:504 | dxgi_init | Capture Size : 2560 x 1440
[I] 5332717628 dxgi.c:505 | dxgi_init | AcquireLock : enabled
[I] 5332717927 dxgi.c:506 | dxgi_init | Debug mode : disabled
[I] 5332718693 dxgi.c:598 | dxgi_init | Source Format : DXGI_FORMAT_B8G8R8A8_UNORM
[I] 5332719054 dxgi.c:640 | dxgi_init | Request Size : 2560 x 1440
[I] 5332721964 dxgi.c:658 | dxgi_init | Output Size : 2560 x 1440
[I] 5332722409 dxgi.c:666 | dxgi_init | Copy backend : Direct3D 11
[I] 5332722690 dxgi.c:667 | dxgi_init | Damage-aware copy : enabled
And on client:
[I] 39512564535 main.c:698 | main_frameThread | Format: FRAME_TYPE_BGRA 2560x1440 stride:2560 pitch:10240 rotation:0
Client egl debug logs, HDR on:
[I] 41684647178 main.c:698 | main_frameThread | Format: FRAME_TYPE_RGBA16F 2560x1440 stride:2560 pitch:20480 rotation:0
[I] 41684670542 egl.c:701 | debugCallback | GL message (source: shader compiler, type: other): Shader Stats: SGPRS: 24 VGPRS: 16 Code Size: 180 LDS: 0 Scratch: 0 Max Waves: 8 Spilled SGPRs: 0 Spilled VGPRs: 0 PrivMem VGPRs: 0 Outputs: 2 PatchOutputs: 0 DivergentLoop: 0 InlineUniforms: 0 (VS, W64)
[I] 41684670565 egl.c:701 | debugCallback | GL message (source: shader compiler, type: other): Shader Stats: SGPRS: 16 VGPRS: 12 Code Size: 120 LDS: 0 Scratch: 0 Max Waves: 8 Spilled SGPRs: 0 Spilled VGPRs: 0 PrivMem VGPRs: 0 Outputs: 1 PatchOutputs: 0 DivergentLoop: 0 InlineUniforms: 0 (PS, W64)
[I] 41728007903 egl.c:701 | debugCallback | GL message (source: shader compiler, type: other): Shader Stats: SGPRS: 24 VGPRS: 16 Code Size: 180 LDS: 0 Scratch: 0 Max Waves: 8 Spilled SGPRs: 0 Spilled VGPRs: 0 PrivMem VGPRs: 0 Outputs: 2 PatchOutputs: 0 DivergentLoop: 0 InlineUniforms: 0 (VS, W64)
[I] 41728007934 egl.c:701 | debugCallback | GL message (source: shader compiler, type: other): Shader Stats: SGPRS: 16 VGPRS: 12 Code Size: 120 LDS: 0 Scratch: 0 Max Waves: 8 Spilled SGPRs: 0 Spilled VGPRs: 0 PrivMem VGPRs: 0 Outputs: 1 PatchOutputs: 0 DivergentLoop: 0 InlineUniforms: 0 (PS, W64)
[I] 41728011660 egl.c:701 | debugCallback | GL message (source: shader compiler, type: other): Shader Stats: SGPRS: 16 VGPRS: 8 Code Size: 232 LDS: 0 Scratch: 0 Max Waves: 8 Spilled SGPRs: 0 Spilled VGPRs: 0 PrivMem VGPRs: 0 Outputs: 1 PatchOutputs: 0 DivergentLoop: 0 InlineUniforms: 2 (PS, W64)
[I] 41746607291 ps.c:644 | ps_connectChannel | DISPLAY channel connected
[I] 41746608116 main.c:896 | spice_surfaceCreate | Create SPICE surface: id: 0, size: 1280x800
[I] 41746611380 egl.c:701 | debugCallback | GL message (source: shader compiler, type: other): Shader Stats: SGPRS: 24 VGPRS: 16 Code Size: 180 LDS: 0 Scratch: 0 Max Waves: 8 Spilled SGPRs: 0 Spilled VGPRs: 0 PrivMem VGPRs: 0 Outputs: 2 PatchOutputs: 0 DivergentLoop: 0 InlineUniforms: 0 (VS, W64)
[I] 41746611399 egl.c:701 | debugCallback | GL message (source: shader compiler, type: other): Shader Stats: SGPRS: 16 VGPRS: 12 Code Size: 120 LDS: 0 Scratch: 0 Max Waves: 8 Spilled SGPRs: 0 Spilled VGPRs: 0 PrivMem VGPRs: 0 Outputs: 1 PatchOutputs: 0 DivergentLoop: 0 InlineUniforms: 0 (PS, W64)
[I] 41746620589 ps.c:644 | ps_connectChannel | CURSOR channel connected
[I] 41747368365 main.c:698 | main_frameThread | Format: FRAME_TYPE_RGBA16F 2560x1440 stride:2560 pitch:20480 rotation:0
[I] 41747393293 egl.c:701 | debugCallback | GL message (source: shader compiler, type: other): Shader Stats: SGPRS: 24 VGPRS: 16 Code Size: 180 LDS: 0 Scratch: 0 Max Waves: 8 Spilled SGPRs: 0 Spilled VGPRs: 0 PrivMem VGPRs: 0 Outputs: 2 PatchOutputs: 0 DivergentLoop: 0 InlineUniforms: 0 (VS, W64)
[I] 41747393317 egl.c:701 | debugCallback | GL message (source: shader compiler, type: other): Shader Stats: SGPRS: 16 VGPRS: 12 Code Size: 120 LDS: 0 Scratch: 0 Max Waves: 8 Spilled SGPRs: 0 Spilled VGPRs: 0 PrivMem VGPRs: 0 Outputs: 1 PatchOutputs: 0 DivergentLoop: 0 InlineUniforms: 0 (PS, W64)
Client egl debug logs, HDR off:
[I] 41750250410 main.c:698 | main_frameThread | Format: FRAME_TYPE_BGRA 2560x1440 stride:2560 pitch:10240 rotation:0
[I] 41750255775 egl.c:701 | debugCallback | GL message (source: shader compiler, type: other): Shader Stats: SGPRS: 16 VGPRS: 4 Code Size: 100 LDS: 0 Scratch: 0 Max Waves: 8 Spilled SGPRs: 0 Spilled VGPRs: 0 PrivMem VGPRs: 0 Outputs: 1 PatchOutputs: 0 DivergentLoop: 0 InlineUniforms: 2 (PS, W64)
[I] 41750260925 egl.c:701 | debugCallback | GL message (source: shader compiler, type: other): Shader Stats: SGPRS: 24 VGPRS: 16 Code Size: 180 LDS: 0 Scratch: 0 Max Waves: 8 Spilled SGPRs: 0 Spilled VGPRs: 0 PrivMem VGPRs: 0 Outputs: 2 PatchOutputs: 0 DivergentLoop: 0 InlineUniforms: 0 (VS, W64)
[I] 41750260950 egl.c:701 | debugCallback | GL message (source: shader compiler, type: other): Shader Stats: SGPRS: 16 VGPRS: 12 Code Size: 120 LDS: 0 Scratch: 0 Max Waves: 8 Spilled SGPRs: 0 Spilled VGPRs: 0 PrivMem VGPRs: 0 Outputs: 1 PatchOutputs: 0 DivergentLoop: 0 InlineUniforms: 0 (PS, W64)
forgot I'm using B6-rc1
Why are you using a release candidate at all? rc1 is older then B6.
Please provide your full client log, not just snippets of what you think we need
On my system I am able to benefit from HDR. Having the option enabled in Windows triggers applications to render in PQ/ST2084, and I can pass those 10 bit pixels directly through to my monitor where I can tell it to expect PQ encoded images.
Latest bleeding edge now has support for configuring the HDR to SDR mapping, including disabling it. Can you please upgrade to this version and check if the problem still exists. Please be sure to update both the host and client applications.
Edit: I just re-read this, note that with DXGI we do not get 10-bit HDR, but rather 16-bit,(DXGI_FORMAT_R16G16B16A16_FLOAT), or 64-bits per pixel. Only NVIDIA NvFBC is capable of providing 10bit HDR at this time.
Further updates to this.
1) There was a bug with how the damage rects were being copied for the wider pixel format. This is fixed.
2) I figured out how to coax DXGI DesktopDuplication into providing 10-bit HDR instead, so there is no longer a bandwidth hit for using HDR.
3) When the guest is connected to a HDR aware monitor, DXGI DD provides the post tone mapped data. As a result the output is rather poor, and made worse by our assumption that the data is still un-mapped. I will work on resolving this in the near future.
More updates here:
Regarding point 2. This did not work as expected, additional work was required to implement a post-processor in windows to undo any mapping applied before converting to HDR10-bit. This is now done.
Regarding point 3. This is much better, about as good as we are going to get when mapping HDR to SDR. It's usable but might need some love from someone that is better versed with HDR and color spaces (ie, not me).
Please update to the latest bleeding version and test (both host and client), if your issues are now resolved please let me know here so I can close this issue off.
Sorry, I finally got around to testing this.
So with the latest commit f6b2cec I can now see the entire screen update correctly, so can confirm that issue 1 is fixed!
I'm still not quite seeing what I would expect though. I can never seem to get the "pq" mode to be enabled, regardless of the settings I change in Applications (Cyberpunk2077 or VLC) and also changing fullscreen or windowed has no effect.
main.c:698 | main_frameThread | Format: FRAME_TYPE_RGBA10 3840x2160 stride:3840 pitch:15360 rotation:0 hdr:1 pq:0
There is definitely some other tonemap or scaling being applied.
I can never seem to get the "pq" mode to be enabled,
There is no PQ mode, this is debugging to tell us what windows is feeding LG. PQ 0 means that windows has not applied PQ to the captured frames. This is a good thing because your host OS should be applying PQ to the frames to map them to your monitor.
There is definitely some other tonemap or scaling being applied.
Yes, like I said, it's a feature you can now disable. Press ScollLock+O
and turn it off in the EGL settings.
Sorry, I meant even when running with egl:mapHDRtoSDR=no
I still don't see what I would expect. I'll try to put together some more test cases. You can close this issue for now though!
If you still do not get what you expect there is nothing more we can do here at all. With that option turned off you are getting the raw frame that windows produces.
Closing as solved.
Sorry I had further thoughts on this. HDR will never work even if your monitor will accept ungraded frames. Linux does not composite or output raw HDR even in exclusive full screen mode. The GPU will be internally converting HDR to SDR with whatever mapping it feels is appropriate.
The GPU does no such thing. The desktop compositor sends 10bit RGB values down the DisplayPort cable, and it is up to my monitor to interpret those signals correctly. Usually the compositor sends a gamma encoded - sRGB pixel, but once waylands HDR support is finished, the compositor can know to correctly send down PQ. Until then, I can tell my monitor what signal to expect manually.
Here is a naive screenshot from my Gnome session (unfortunately the screenshot is only 8bit, but rest assured 10 bits are getting to my monitor.
And here is a photo of my screen, showing the test image correctly displayed in HDR, with my monitor settings visible:
The rest of my desktop is incorrect - white text from firefox and my terminal are wildly overexposed, but if I were to make the test image full screen - as I am hoping to do with LookingGlass, it would be correct.
Sorry I assumed X11, not Wayland. X11 will only operate R8G8B8 unless overridden at which point many applications break. This causes the GPU to do what it can to convert HDR10 textures to RGB8 to make things work.
Even still, the captured output from windows has not had any PQ transformations applied, the only thing that windows does is multiply the brightness of each pixel for SDR content with the SDRWhiteLevel reported as per the SDR adjustments in windows HDR color configuration.
I do know that NvFBC HDR has PQ applied already and results in a similar washed out image as per your reference, perhaps this is the better path for you to take. You have a NVIDIA guest GPU, see NVFBC_PRIV_DATA
in the LG documentation and do some research to fill in the blanks. Note you do not need to patch your drivers.
After enabling HDR in my windows 10 machine, LookingGlass correctly receives an RGBA16F buffer and draws the screen. However it appears that subsequent redraws of the screen only seem to affect around the first 1/2 of the window.
Here's a screenshot after enabling HDR, and then moving a window down and left:
I can force a redraw by toggling Scroll-lock+V to enable/disable video drawing, but again this only works for the initial draw. Subsequent redraws are incomplete.
I tried egl:noSwapDamage does not seem to affect the redrawing issue.
I wonder if an incorrect pixel bitdepth is being used when calculating redrawing bounds somewhere, but after a brief look through the code I haven't been able to spot it.
Thanks
Bug Report Required Information