Improved AMD Color Management Being Worked On For The Steam Deck

[WiR3D]

Starting today: https://wiki.gnome.org/Hackfests/ShellDisplayNext2023

I hope Micheal reports on the outcomes from this

[Mitch]

I hardly believe that the Steam Deck can somehow get a much better screen through a kernel update, unless they've been sitting on a tiny optimisation all this time.

What seems much more likely to me is that they're looking into HDR/OLED support for an eventual Steam Deck II in the future. All the copycats (ROG Ally the first of them) which lazily use Windows prove one thing: the Steam Deck's concept is easy to copy hardware-wise.
At this point anyway, Sony (Playstation), Microsoft (XBOX), Valve (Steam Deck), ASUS (Ally) and pretty much all the others have heard Lisa's call: "Zen 2, 8 cores, and RDNA with LPDDR".

Running Zen 4/RDNA3 or in a year or two Zen5/RDNA4 is kind of the logical follow up.

Also, IIRC, Zen 2 was the big push in POWER, not in efficiency. Zen 3 worked on that field quite a bit, and Zen 4 trounced efficiency to an almost absurd degree, with the 7800x3D rocking more perf/W than anything ever made. I really expect either Zen 4 or Zen 5 3D V-cache tools to appear in a gazillion mobile units, whether it's Steam Deck-sized or laptop sized, in the coming years, and for the depth of AMD's hand to lengthen continuously.

RDNA still is the lesser option compared to Nvidia, but not so lesser that it can't be nicely plugged in and forgotten about. I am really hopeful about several 1080p capable low power units to rush to market within the next 2 years.

This update certainly seems bigger than just the Steam Deck Gen 1. I imagine the Deck's screen may not benefit much/at all from HDR. However, the existing Steam Deck can still benefit from external displays that support HDR, right?

EDIT: I'd say it affects any hardware that we put SteamOS 3.5 on. It would be amazing to have that working for non-Deck hardware.

[shmerl]

> The userspace case here is Gamescope

What about regular Wayland compositors? Will their HDR support rely on this as well? Limiting this to Gamesope only would be weird.

[slagiewka]

> The userspace case here is Gamescope

What about regular Wayland compositors? Will their HDR support rely on this as well? Limiting this to Gamesope only would be weird.

The mailing list later says:

We have also had some other userspace interests from Xaver Hugl (KDE) in
experimenting with these properties for their HDR/color bring-up before
a generic interface is settled on also.

So long story short: others can use it in their compositors if they please. But without the generic interface there won't be a wide spread support in apps etc.

[qlum]

In general Its good to do the work, even looking at their own hardware, it stands to reason a steamdeck 2 or refresh will be hdr capable , Even if it is yet applicable / won't be for a while.

[WiR3D]

Just for those who missed it, the entire point of the Shell & Display Next Hackfests (started today) is to figure out what a generic interface looks like for all the different layers of the stack and it should be forward thinking, so that we don't end up here again.

[Joe2021]

Average users still buy 6+2 bit monitors that use dithering to render all 16,7M colors. Those displays don't even support 100% sRGB or have nits levels above 300. Usually the resolution is also 1440p or lower.

Yeah, and what do you think how this is going to change?

[Nille_kungen]

It's nice to see women in floss GPU software development.

What seems much more likely to me is that they're looking into HDR/OLED support for an eventual Steam Deck II in the future. All the copycats (ROG Ally the first of them) which lazily use Windows prove one thing: the Steam Deck's concept is easy to copy hardware-wise.

I thought it was the point with steam hardware to get others to develop devices for steam like the steam box (Steam Machines) before steam deck.

[JoshuaAshton]

> The userspace case here is Gamescope

What about regular Wayland compositors? Will their HDR support rely on this as well? Limiting this to Gamesope only would be weird.

There is nothing limiting this to Gamescope, any compositor can chose to use these initial vendored implementations for AMD.

Doing generic color mgmt is going to take a while -- every vendor has radically different hardware both in terms of features, requirements and implementation here. Solving this problem in the generic case is very difficult.

Differences in display HW is such an issue that that one of the initial ideas *for* a generic implementation would be to have vendored DRM properties, and a userspace library eg. libliftoff or whatever to handle the generic case.

I am definitely in favor of something like that fwiw; any complex problem like this where we have an unlimited amount of vendors to account for that do everything differently should be shifted to userspace.
Whatever we make today will be wrong, not account for something or not be good enough and we will have to re-do everything and still maintain support for it if it's implemented kernel side due to the uAPI guarantees there.
Much better to get started with vendored properties imo. It's the same as gfx driver development, we don't have a generic interface to GPUs for gfx/compute on the kernel side.

[shmerl]

Much better to get started with vendored properties imo. It's the same as gfx driver development, we don't have a generic interface to GPUs for gfx/compute on the kernel side.

I guess, if compositors agree to handle at least most common GPUs with their own quirks this way.

In the end we want it to work and not wait for decades until some kind of generic solution will materialize, becoming obsolete always on arrival due to GPUs already moving further.