AMD Radeon Linux Gaming Performance At Parity Between KDE Plasma 6.0 X11 vs. Wayland

[mSparks]

X11 explicit sync for vulkan is not merged for bare metal branch yet.

It doesn't need to be, any more than your personal website needs merging into the http standard.
Not least because X11 was always HDR then downscaled to whatever color palette the display supported. Can't remember if its 16bits or 32bit per color, think its FP32 per channel.

Wayland doesn't even support color management yet.

X11 server and X11 protocol don't support HDR.

It does, and has since nvidia driver version 545.23.06

[oiaohm]

It doesn't need to be, any more than your personal website needs merging into the http standard.
Not least because X11 was always HDR then downscaled to whatever color palette the display supported. Can't remember if its 16bits or 32bit per color, think its FP32 per channel.

Wayland doesn't even support color management yet.

It does, and has since nvidia driver version 545.23.06

Read prior post links because arch site and the maintainer of X11 server on bare metal tells you that it does not. Nvidia HDR support only works with Wayland compositor.

• HDR capable graphics driver: AMDGPU and NVIDIA (550.54.14+) are confirmed to work.

https://wiki.archlinux.org/title/HDR_monitor_support

545.23.06 Nvidia for HDR does not in fact work. Yes Nvidia introduced the feature in that version but the implementation is bugged until 550.54.14+ using prior to this will lead to black screens of death.

No matter how you argue the reality is that one of the X11 maintainers.

https://gitlab.freedesktop.org/xorg/xserver/-/issues/1037#note_521100

(right now you need to get the window contents from its corresponding Pixmap, and Pixmaps can't be larger than 32bpp...).

Why is this a problem. HDR 30 bit per pixel right. There is something mSparks you have missed. If the output is 30 bit and the pixmap can store only 32bpp where are you going to put the alpha channel data. The data defining transparency when you composite windows with each other.

Alpha channel data does not get sent to the monitor. 24 bit display output need 32 bits of pixel storage so you can have a 8bit alpha channel. So a 30 bit per pixel hdr output need a 40bits per pixel storage to have 10 bit alpha even 8 bit alpha the result it it does not fit.

https://en.wikipedia.org/wiki/High-dynamic-range_television

Monitor HDR normally 10 bit per channel. They had to make it fit in a 32 bit transfer limit. That only leaves 2 bits for alpha

Yes RGBA what applications output RGB what you send to monitor. Compositor in the middle processes the alpha bit out of existence before sending result to monitor.

[mSparks]

Nvidia HDR support only works with Wayland compositor.

BS, wayland doesn't even support nvidia yet, let alone HDR.
Even when it does eventually support NV, it will need color managment implementing before it can support HDR - still years away.

X11 support went in in 2016. FP16.

https://www.x.org/wiki/Events/XDC2016/Program/xdc-2016-hdr.pdf

[oiaohm]

BS, wayland doesn't even support nvidia yet, let alone HDR.
Even when it does eventually support NV, it will need color managment implementing before it can support HDR - still years away.

Arch linux tells you that HDR can be implemented before color management items are fully implemented.

X11 support went in in 2016

Wrong thing. 2016 is when Nvidia started looking at the problem not when it went in.
https://www.phoronix.com/news/X11-DeepColor-Visual-RFC
2017 here is when Nvidia proposed changing the X11 protocol to support HDR with the "DeepColor Visual Class Extension". This alteration to the X11 protocol was never merged and installing Nvidia drivers don't magically make it implemented either. This is why X11 protocol cannot support HDR because you need that Extension or equal to allow large than 32 bit per pixel so you can store HDR data with alpha has never come part of the X11 protocol result in no support for HDR by X11 protocol.

Wayland does not have this problem because DMABUF that is uses can use what ever bits per pixel the GPU supports yes this is based on the Intel HDR work mentioned in the X11 DeepColor phoronix write up.

https://www.phoronix.com/news/Linux-DRM-Layer-HDR

Yes this one is the one that end up merged and Wayland HDR in fact depends on.

Even Nvidia driver developers say that current X11 don't support HDR. Nvidia with the 545.23.06 started doing the bits to use the Intel design DRM layer HDR support. Yes the part that support Wayland not X11.

mSparks basically you are totally wrong as normal.

[mSparks]

Wrong thing. 2016 is when Nvidia started looking at the problem not when it went in.

Slide 17 quite clearly explains nothing needed changing in X11

And that
3D APIs (OpenGL, Vulkan).
• Video APIs (VDPAU, VAAPI).

Already produce it.
X11 runs at FP16 and has a well developed colour management API
The only thing that held it back until now was no one had the physical monitor hardware needed (cos they were like $100,000 a pop).

Wayland doesn't have a color management API and runs at FP8 - as the NV slide 16 puts it "Wayland compositors will need to be FP16-aware." - they still aren't.

[oiaohm]

Slide 17 quite clearly explains nothing needed changing in X11

No someone need to read.

Don’t need X rendering to FP16, but easier to prohibit or allow?
• Or make FP16 look like SDR RGBA8 to X rendering (hiding RGBA8/FP16 conversions in drivers)?
• Should we allow the root window to be FP16?
• Or add an FP16 overlay visual (like traditional 8-bit color index overlay)?

Notice all the question marks. 2016 is very early with Nvidia HDR. These are all open questions. In fact it does not state that nothing need changing in X11 and in 2016 Nvidia has not work how it need to be done.

https://www.phoronix.com/news/X11-DeepColor-Visual-RFC

This from 2017 is Nvidia attempt to answer those questions that never gets merged.

Funny that you pointed to the very side that say you are talking out you ass mSparks.

[oiaohm]

Wayland doesn't have a color management API and runs at FP8 - as the NV slide 16 puts it "Wayland compositors will need to be FP16-aware." - they still aren't.

Problem that write is pre https://www.phoronix.com/news/Linux-DRM-Layer-HDR
Pre valve doing HDR in gamescope.
and pre the following.

https://zamundaaa.github.io/wayland/2023/12/18/update-on-hdr-and-colormanagement-in-plasma.html

The arguement that X11 can be bypassed and not altered. Turns out this happens to be true with Wayland compositors it more that the compositor just had to not limit the DMABUF objects that can be passed to the GPU on the Wayland side.

So FP16 aware when KDE and gamescope implemented HDR with Wayland turned out not be required. Lot in that early 2016 write up by Nvidia turns out to be plan wrong and was found to be wrong once people started implementing..

mSparks remember in 2016 Nvidia is still pushing eglstreams for wayland. Eglstreams would required the "Wayland Compositors" to be FP16 aware. But the DRM/GBM/DMABUF solution does not require the Wayland compositors to be FP16 aware instead punt the problem straight down to the GPU drivers.

[mSparks]

No someone need to read.



Notice all the question marks.

"prohibit or allow" means provide an option to turn it off.

nvidias 545 does this via nvidia settings, which will not even start on wayland compositors.

https://forums.developer.nvidia.com/t/wayland-support-for-nvidia-settings/189799/21

So it cannot work on wayland because there is no software for the nvidia driver that works on wayland to tell the GPU to allow it.


And once again, generally wayland does not support nvidia, so how exactly do you think wayland supports nvidias hdr implementation?

Turns out this happens to be true with Wayland compositors

Nope, because wayland applications cannot access gpu specific functions, only what wayland offers them, and that is FP8 functions, there is simply no mechanism in place for a wayland application to send more than 8 bits per channel to the GPU, wayland will require basically a complete rewrite to do so.

I dont understand why you are kidding yourself about this?

gamescope

ohhhhh,
you think because valve wrote some linux software exclusively for their custom silicon on the steam deck that is something you can use....
ahhhhahahahaaa

Doesnt work like that.

[oiaohm]

nvidias 545 does this via nvidia settings, which will not even start on wayland compositors.

550.54.14+ Nvidia drivers to turn HDR on and off does not require nvidia settings.

https://www.nvidia.com/download/driverResults.aspx/218826/en-us/

Added support for HDR signaling via the HDR_OUTPUT_METADATA and Colorspace per-connector DRM properties when nvidia-drm is loaded with the `modeset=1` parameter.

This is important.

https://www.phoronix.com/news/Linux-DRM-Layer-HDR

This is Nvidia implementing the Intel designed HDR interface.

And once again, generally wayland does not support nvidia, so how exactly do you think wayland supports nvidias hdr implementation?

The simple answer Wayland compositors don't support the Nvidia designed HDR implementation. Wayland compositors support the Intel designed HDR implementation that Nvidia drivers 550.54.14+ provide interfaces of. The Intel design turns out to be stable and now is being expanded by AMD and Nvidia.

https://indico.freedesktop.org/event/2/contributions/56/attachments/64/105/2022%20XDC%20Is%20HDR%20Harder.pdf

There is AMD working with the Intel design. The reality DMABUF is already able to transport more than 8 bits per channel. Wayland protocol has need 2 extensions to transfer more metadata about the buffer but the buffer it self since it was DMABUF there was no size problem here.

Most of the work on the wayland compositor it have the compositor not do any software rendering and just throw more straight at the GPU driver. Page 32 on that one is very interesting.

[mSparks]

550.54.14+ Nvidia drivers to turn HDR on and off does not require nvidia settings.

I can assure you it does, all nvidia color profile stuff goes through nv settings - even command line stuff.

default is RGB 8bpc B8G8R8A8, with 10bpc optional from a dropdown (R10G10B10A2)


You can make an X11 application or desktop run in HDR10 even without an HDR monitor, but unless you manually configure a compatible monitor to 10bpc from nv settings all you will see is 8bpc, not 10.

The simple answer Wayland compositors don't support the Nvidia designed HDR implementation.

Indeed. and gamescope only works with X11 proton applications in fullscreen. So where is this Wayland HDR you proclaim exists?

Page 32 on that one is very interesting.

Page 33 says exactly what I just told you
How do we get there?
1 We need a way for an application to communicate the surface color space(1) with the compositor [Wayland needs color management support]
2 We need to teach the compositor how to compose content with different color spaces [Wayland needs color management support]
3 We need to teach the compositor to render to an HDR framebuffer [Wayland needs to support >FP8 functions]
4 We need to provide the ability to offload a compositor's color pipeline to DRM/KMS [Wayland needs to support >FP8 functions]