The State Of HDR On The Steam Deck With Valve's Gamescope Compositor

[AmericanLocomotive]

No, we're not. Our open source Mesa developers are working on OpenGL and video encode/decode, not Vulkan. The OpenGL code is used as a reference for the Mesa Vulkan driver, but we are not writing it.

Sorry, that was what I meant in my original post where I said it "boggles my mind that AMD devs are not contributing to the Mesa driver" The context was the Steamdeck, so I was referring to the Mesa RADV Vulkan driver. So by your own admittance - AMD is not actively contributing to that driver.

You have a super high profile product (Deck) with presumably hundreds of thousands (maybe into millions by now?) of units sold, and much of the software relies on Vulkan and RADV. And 3rd parties are basically writing that software for AMD. They're relying on Valve, RedHat, Igalia, etc.. to write the driver for them. It's completely nuts ..and while this is going on, you have a team maintaining the AMDVLK driver that no one really seems to care about or use. I think Stadia was the only really large user of AMDVLK, and well, that project is dead?

I get that you're hedging that some workstation software might transition to Vulkan, and that's why you're keeping AMDVLK around, but it just seems like a ton of wasted, duplicated effort. It seems like it'd be far more worthwhile to throw all of your weight behind RADV, since that's where the Linux gaming industry seems to be going.

If AMD's Linux popularity continues to increase, I don't think AMD can be "hands off" on the RADV driver forever. Eventually they're going to have to get involved.

[bridgman]

Sorry, that was what I meant in my original post where I said it "boggles my mind that AMD devs are not contributing to the Mesa driver" The context was the Steamdeck, so I was referring to the Mesa RADV Vulkan driver. So by your own admittance - AMD is not actively contributing to that driver.

Depends on what you mean by "actively". We do work with Valve and other embedded customers using RADV, and you will see AMD changes in the RADV commit history although I expect that more of our work results in a non-AMD commit than a direct AMD commit. It's not as black-and-white as people like to think.

I know it is also popular to think that we have some massive team working on AMDVLK but that just isn't the case. AMDVLK is a scripted source code extract from a shared code base used across multiple OSes and APIs. It was a lot of work to get it going in the first place (before RADV existed) but there is no big team that could be redirected to RADV.

[oiaohm]

Zink isn't a golden solution, many opengl apps dont work with it at all. not a good solution, and it doesnt seem like there is any one dedicated to getting it to work right on windows. A shame because I wanted to use it for olive.

https://www.phoronix.com/news/Zink-Windows-Kopper-Progress

There are parties working on zink on windows. Of course those parties are only focused on limited number of opengl applications at this time.

[Quackdoc]

https://www.phoronix.com/news/Zink-Windows-Kopper-Progress

There are parties working on zink on windows. Of course those parties are only focused on limited number of opengl applications at this time.

indeed, without wide support however I don't think it would be viable to ship zink at all on windows. the d3d12 gallium driver maybe, but even that still has a lot of bugs

[qarium]

Depends on what you mean by "actively". We do work with Valve and other embedded customers using RADV, and you will see AMD changes in the RADV commit history although I expect that more of our work results in a non-AMD commit than a direct AMD commit. It's not as black-and-white as people like to think.
I know it is also popular to think that we have some massive team working on AMDVLK but that just isn't the case. AMDVLK is a scripted source code extract from a shared code base used across multiple OSes and APIs. It was a lot of work to get it going in the first place (before RADV existed) but there is no big team that could be redirected to RADV.

AMD should do themself a favor and end this AMDVLK and the reason is this:
i for my self do not use AMDVLK and i also know no one who do use AMDVLK...
people go and install whatever linux distro they want and not a single one i know comes with AMDVLK pre installed
all only come with RADV preinstalled.

but it is fact that this AMDVLK driver has negative effect in the meaning of customers become confused they can not unterstand why there are 2 drivers who look like they compete with each other when in fact the AMDVLK has no meaning and nearly no one use it.

in my opinion this AMDVLK driver does more harm than good.

there are sadly more stuff what is harmfull around AMD drivers the linux drivers you can download from amd.com for example for most of the people it makes no sense. and also if people do it anyway they do not get the result they expect.

for example if a person installs driver from amd.com they of course expect a driver-gui but does not get one...

then the people expect an upgrade to make it better than what is installed but most of the time this is not the case.

for multible reasons the closed source driver most of the time gives worst result than the opensource driver.

in some rare scenario the closed source driver is usefull but most people do not even know the scenarios who the closed source driver makes sense.

to be honest my opinion is that people just become confused out of no reason at all and it is even to the extrem that people who never did start to get any info about all this end up having less problems unterstanding how to use their system.

the people who do not start to inform themself about the situation do not become confused because they use distro with pre installed RADV

this means AMD really harms themself.

the solution is simple:

STOP the closed source driver delivered by AMD.com driver.

STOP the AMDVLK driver.

make clear that the driver does not come from AMD.com and the people should use the Distro drivers instead.

why no driver-gui ?

why does amd need to ask people if linux people want amd AI hardware to run ???

[oiaohm]

indeed, without wide support however I don't think it would be viable to ship zink at all on windows. the d3d12 gallium driver maybe, but even that still has a lot of bugs

There are already games supping themselves zink on windows. So for those working on zink for windows it is viable for them to ship zink because zink makes their software work without issue where they have their software fail with AMD/Intel/Nvidia drivers otherwise due to some opengl non conformance or opengl specification limitation.

Fun limitation that effects X-plane is that by Opengl and Vulkan standard allocations in both have the right to presume they are exclusive. So having Wayland application loading opengl plugin library with AMD and Intel due to those following specification end up with your application collapsing in a heap as X-plane use to. So there are some applications that currently don't work with AMD opengl drivers on Windows that do work when you use Zinik for opengl with X-plane being one of them.

Remember this is devil in the detail as well. Making opengl and vuklan work with each other the way Nvidia did you end up with opengl implicit sync not working correctly so breaking another pile of applications this is why Valve is interested in Zink on windows as well to run applications that work fine with AMD and Intel yet fail with Nvidia that is their largest consumer base over all with most of it on Windows.

Wider support is partly limited of zink due to the fact application that use zink on windows end up having to bundle zink themselves. Zink on windows is really not that old. Its area we have to watch.

Yes something that simple to miss what AMD/Intel/Nvidia closed source driver developers decide todo could be wrong for different applications. Open source drivers do allow parties like valve and others to in fact fix up drivers to service their needs.

This is also linked to people asking why parties like Redhat/IBM keep on investing on open source Nvidia drivers. It simple really what if your problem why something does not work comes from some choice Nvidia closed source driver maker made as closed source you end up begging to Nvidia to fix it and at times no matter how important the problem is to you the Nvidia can decide to never to fix it.

[Quackdoc]

There are already games supping themselves zink on windows. So for those working on zink for windows it is viable for them to ship zink because zink makes their software work without issue where they have their software fail with AMD/Intel/Nvidia drivers otherwise due to some opengl non conformance or opengl specification limitation.

Fun limitation that effects X-plane is that by Opengl and Vulkan standard allocations in both have the right to presume they are exclusive. So having Wayland application loading opengl plugin library with AMD and Intel due to those following specification end up with your application collapsing in a heap as X-plane use to. So there are some applications that currently don't work with AMD opengl drivers on Windows that do work when you use Zinik for opengl with X-plane being one of them.

Remember this is devil in the detail as well. Making opengl and vuklan work with each other the way Nvidia did you end up with opengl implicit sync not working correctly so breaking another pile of applications this is why Valve is interested in Zink on windows as well to run applications that work fine with AMD and Intel yet fail with Nvidia that is their largest consumer base over all with most of it on Windows.

Wider support is partly limited of zink due to the fact application that use zink on windows end up having to bundle zink themselves. Zink on windows is really not that old. Its area we have to watch.

Yes something that simple to miss what AMD/Intel/Nvidia closed source driver developers decide todo could be wrong for different applications. Open source drivers do allow parties like valve and others to in fact fix up drivers to service their needs.

This is also linked to people asking why parties like Redhat/IBM keep on investing on open source Nvidia drivers. It simple really what if your problem why something does not work comes from some choice Nvidia closed source driver maker made as closed source you end up begging to Nvidia to fix it and at times no matter how important the problem is to you the Nvidia can decide to never to fix it.

it's been something i've been looking into quite a bit because yes, AMD's windows opengl driver is indeed trash. it has been a stream of non stop issues across a variety of softwares I have used, so looking into zink and d3d12 has been something I have been doing a lot, but I havent really had much progress, though zonotic does run now, most opengl qt apps break for me

[elvis]

Can anyone explain it for mere mortals?

The way we define the colour characteristics of a display have a series of rules that govern them. For a VERY long time, a lot of computer systems have gotten VERY lazy about this, and just assumed everything was static 8-bit SDR sRGB with no real understanding of how all that works at a technical level.

This work is finally paying off that technical debt. Mostly necessary because for the first time in quite a while, we have displays that are different to the bog standard sRGB/BT.601/BT.709 style displays we've had for decades (all of which are different in very specific ways, but "close enough" that few people care or even notice). Now we're entering a world no only where new standards like BT.2020/BT.2100/Display-P3/scRGB (and many more) exist, but now where even displays within that spec behave very differently. Almost zero displays available to hit a BT.2020 colour gamut at 100%, let alone the 10K nits that HDR can technically scale to. And the displays that are all on the market now all behave so differently, that it's almost impossible for regular users to be able to get a decent out-of-box experience with wide colour gamut or HDR displays and content today.

As a result, colour management is more important than ever. Ensuring the combination of GPU, display device, content, kernel, drivers and applications all talk the same language so that the final picture the user sees is consistent regardless of platform or hardware is pretty important. The luxuries we've had where we could be really, really lazy about that for the last couple of decades are gone now. So proper colour management is no longer "nice to have", but now mandatory.

If you want a real world example of this, punch the phrase "HDR washed out" into Google, and witness what the result is when colour management isn't made easy enough for regular audiences (or in some cases, doesn't exist at all). Given that HDR imaging is a concept that's been around almost as long as digital imagery has, it's now 2023 and we can still barely get static HDR images to display properly on websites. In a similar "check the Google results", look for phrases like "JXR washed out" in Google to see what happens to Windows users trying to take HDR screenshots of games and share the resulting files. If you understand colour science, it's not a problem. For regular folk, it's a nightmare, and the solution for most is just to disable HDR and avoid the problem all together.

What the presenter mentioned in the video was really "colour management 101" features that have been sorely missing for a long time from various Linux desktops. Somewhat frustratingly, professionals in the photography/imaging/video/media/VFX space have been saying this quite loudly for some time, and have been largely shot down by open source developers for that same amount of time (this is especially true of Wayland, as it was actually a step backwards when it came to colour management compared to X11 in certain ways). It's wonderful to see Igalia step up and do the hard yards here.

[timofonic]

The way we define the colour characteristics of a display have a series of rules that govern them. For a VERY long time, a lot of computer systems have gotten VERY lazy about this, and just assumed everything was static 8-bit SDR sRGB with no real understanding of how all that works at a technical level.

This work is finally paying off that technical debt. Mostly necessary because for the first time in quite a while, we have displays that are different to the bog standard sRGB/BT.601/BT.709 style displays we've had for decades (all of which are different in very specific ways, but "close enough" that few people care or even notice). Now we're entering a world no only where new standards like BT.2020/BT.2100/Display-P3/scRGB (and many more) exist, but now where even displays within that spec behave very differently. Almost zero displays available to hit a BT.2020 colour gamut at 100%, let alone the 10K nits that HDR can technically scale to. And the displays that are all on the market now all behave so differently, that it's almost impossible for regular users to be able to get a decent out-of-box experience with wide colour gamut or HDR displays and content today.

As a result, colour management is more important than ever. Ensuring the combination of GPU, display device, content, kernel, drivers and applications all talk the same language so that the final picture the user sees is consistent regardless of platform or hardware is pretty important. The luxuries we've had where we could be really, really lazy about that for the last couple of decades are gone now. So proper colour management is no longer "nice to have", but now mandatory.

If you want a real world example of this, punch the phrase "HDR washed out" into Google, and witness what the result is when colour management isn't made easy enough for regular audiences (or in some cases, doesn't exist at all). Given that HDR imaging is a concept that's been around almost as long as digital imagery has, it's now 2023 and we can still barely get static HDR images to display properly on websites. In a similar "check the Google results", look for phrases like "JXR washed out" in Google to see what happens to Windows users trying to take HDR screenshots of games and share the resulting files. If you understand colour science, it's not a problem. For regular folk, it's a nightmare, and the solution for most is just to disable HDR and avoid the problem all together.

What the presenter mentioned in the video was really "colour management 101" features that have been sorely missing for a long time from various Linux desktops. Somewhat frustratingly, professionals in the photography/imaging/video/media/VFX space have been saying this quite loudly for some time, and have been largely shot down by open source developers for that same amount of time (this is especially true of Wayland, as it was actually a step backwards when it came to colour management compared to X11 in certain ways). It's wonderful to see Igalia step up and do the hard yards here.

Amazing "article". I wish you were a Phoronix writer, sincerely. Thanks a lot!

Michael Any news about HDR and Linux?