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

[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]

[oiaohm]

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

There is a reason why I said broken.
Add those numbers up both are 32 bit. Yes a alpha value or 2. 0 1 2 3 transpancy 0 fully transparent 3 fully not transparent. No mid grade transparency.

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.

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

Turns out native HDR applications for Wayland are rare. There is only one I know of that not a game and its MPV, It does not support Nvidia HDR it need transparency for it overlays so need more than 2 bit of alpha. MPV mentioned in arch. DRM direct HDR applications are more common but these don't work with Nvidia GPUs that don't have 550.54.14+ Nvidia drivers .

https://www.phoronix.com/news/SDL3-Adds-Colorspace-HDR

The Valve work on SDL3 for SDL linux native applications. This supports the Intel/Gamescope HDR solution not the Nvidia one.

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]

[/QUOTE]

Is this current. That from a 2022 presentation. You failing to read what is written and have added you own bias.

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

This is 2023. This has 3 and 4 done for KDE Plasma.

Wayland protocol has always supported transporting greater than FP8 since wayland started using DMABUF. DMABUF allows transporting whatever buffers the GPU supports. So 12 bit HDR is supported on wayland.

The number 3 "The need to teach a Wayland compositor to render a HDR framebuffer" is teach Wayland compositor not to perform page 30 on it so producing only a sRGB output while accepting HDR in.

This has been the catch from day start of wayland even with gem buffers(before the change of the core design to DMABUF and file handles) Wayland protocol has supported the application sending HDR to the Wayland compositor in what ever bit depth the application and gpu supports.

Do notice out of those 4 issues only 1 in fact need a wayland protocol change.

mSparks go to page 35 in the AMD. Note the Existing protocols. "Subcompositor API" and "Viewporter API" these are not new protocol. These are two you need to transport the content. Viewporter has not changed since 2016. Subcompositor you will have trouble finding as it something AMD personal have habit of calling the core wayland protocol bits that have basically never changed since the Wayland protocol was made.

The reality is the Wayland protocol has always supported HDR. Issue was Wayland compositors have not supported rendering HDR(so conveting send HDR to sRGB) or not having color correction so everything comes out right.

Wayland protocol had broken full HDR support since Wayland was created before Nvidia even had the idea of implementing HDR support. Now AMD and others are getting around to fixing it. Yes full HDR as in able to use every HDR bitdepth with the correct amount of alphas.

Nvidia version of HDR is also missing correctly functional color management as well so issue 1/2 can be disregarded if you are doing a fair compare against Nvidia HDR offering..

Number 4 need to off load color pipeline to DRM/KMS this is to address a performance problem found. HDR color correction being done by CPU equals too much processing required.

mSparks; the Nvidia HDR solution to have the color depth support at the same level as wayland protocol always had the Deep Color extension need to merge into X11.

[WileEPyote]

I'm struggling to understand your logic

what you seem to be saying is something along the lines of

if you want http to keep going, you need to find a way to get it in active development again. Fork it.

This makes my head explode.

I don't know why it makes your head explode. It's simple facts. The only way to keep X11 alive in the long run is to get it back in active development. Point. Blank. Period. That is not an opinion. That is a fact.

You comparing it to http doesn't work because http is still fully active.

Are you going to be part of the solution, or just keep crying about x11 vs wayland? You don't get to have it both ways. It's one or the other. Contribute in some way to get what you want, or learn to accept the upcoming standard.

Contributing doesn't mean you have to code. Go out there and find devs that share your opinion, and have them fork it. Find devs willing to add what you want to wayland. Whatever, it doesn't matter. Just do SOMETHING. ANYTHING. To actually contribute. What you're doing now, which is just complaining on random forums about what you don't like, is accomplishing exactly fuck all. You are part of the problem. Nothing but opinions without offering solutions. Have fun suffering through all the shit you hate in the foreseeable future, because frankly, that's all that's available to you if nobody offers any alternatives.

Quite frankly, all the reasonable people are sick of hearing both the x11 and wayland fanboys.

Try to make a real difference, or stfu already. Nobody gives a flying fuck about your opinion. We just want shit that does what we ask it to do.

And you know what? I have no skin in this game. Both do exactly what I want, so I couldn't give a shit less what protocol wins.

I'm just tired of hearing all you motherfuckers constantly crying. Be part of the solution, or continue being part of the problem. That's all you whining assholes are doing. Causing problems. Fix it, or shut up.