Linux 5.3 To Enable HDR Metadata Support For AMDGPU Driver

[F.Ultra]

Well, while it's weird not to use 10-bit (or more) for HDR, it's certainly not required. I'm working on VPU and DRM drivers and currently my TV correctly shows 8-bit 4K HDR videos.

Of course it's required (and it's required by every single HDR standard that I've ever seen) since the wider gamut is exactly what enables the High Dynamic Range over the Standard Dynamic Range. How else do you propose that the dynamic range would get higher than standard when it's the bits per color that defines the dynamic range?

Perhaps your TV set supports ITM or similar technology where it simply upconverts SDR to HDR like this: https://www.cnet.com/news/technicolo...ideo-into-hdr/

[jernej]

When you use 24bits per pixel you only use 8bits per color, for HDR you use 10 or sometimes 12.

Well, while it's weird not to use 10-bit (or more) for HDR, it's certainly not required. I'm working on VPU and DRM drivers and currently my TV correctly shows 8-bit 4K HDR videos.

[F.Ultra]

Where did you get that? HDMI2 supports 2160p@60Hz with YUV4:4:4 or RGB using 594 MHz base clock and few other tricks like scrambling to lower possibility of data corruptions during transfer. I have cheap ARM board which supports that. Even wiki says it's supported (note 24 bits per pixel).

Not with HDR which is what the context was. HDMI2 is speced at max 18Gbps and 4:4:4 at 60Hz+ and 2160p or 4k requires much more bandwidth than that for HDR.

When you use 24bits per pixel you only use 8bits per color, for HDR you use 10 or sometimes 12.

[jernej]

since 4:4:4 at 2160p requires far more bandwidth at 60Hz than HDMI2 can handle.

Where did you get that? HDMI2 supports 2160p@60Hz with YUV4:4:4 or RGB using 594 MHz base clock and few other tricks like scrambling to lower possibility of data corruptions during transfer. I have cheap ARM board which supports that. Even wiki says it's supported (note 24 bits per pixel).

[F.Ultra]

Will this "just work" in the future? I remember when 10bpc was added and 2160p suddenly wasn't possible on HDMI2 due to 4:4:0 rather than 4:2:0 - I'm still not sure what that entirely means

Chroma Subsampling: https://en.wikipedia.org/wiki/Chroma_subsampling

And you are probably thinking about 4:4:4 vs 4:2:0 and not 4:4:0 vs 4:2:0 since 4:4:4 at 2160p requires far more bandwidth at 60Hz than HDMI2 can handle.

[skeevy420]

Will this "just work" in the future? I remember when 10bpc was added and 2160p suddenly wasn't possible on HDMI2 due to 4:4:0 rather than 4:2:0 - I'm still not sure what that entirely means

It's about tuning your guitar and getting high.

[Azrael5]

Work in (slow) progress for nouveau. HDMI2 is supported (where HW allows). 30bpp and fp16 scanout formats are supported (the latter will be in v5.3), LUTs/CTM are next, with HDR metadata coming in after that. Actually enabling >8bpc to the monitor will probably be last -- there are lots of wrinkles about what to select when (although it already happens over DP). Hopefully the other drivers will have that policy smoothed out by the time I get to it.

And what about their drivers?

[jernej]

There is also DW HDMI HDR support in the pipeline. This controller is used on Amlogic, Allwinner, Rockchip and other SoCs.

[imirkin]

What about Nvidia HDR support?

Work in (slow) progress for nouveau. HDMI2 is supported (where HW allows). 30bpp and fp16 scanout formats are supported (the latter will be in v5.3), LUTs/CTM are next, with HDR metadata coming in after that. Actually enabling >8bpc to the monitor will probably be last -- there are lots of wrinkles about what to select when (although it already happens over DP). Hopefully the other drivers will have that policy smoothed out by the time I get to it.

[Azrael5]

What about Nvidia HDR support?