RE: HDMI FRL: EDID max bit depth is preferred even when it forces DSC

AMD General

> -----Original Message-----
> From: Antoine Richermoz <[email protected]>
> Sent: Tuesday, August 18, 2026 06:31
> To: Zuo, Jerry <[email protected]>
> Cc: Wentland, Harry <[email protected]>;
> [email protected]; [email protected]
> Subject: Re: HDMI FRL: EDID max bit depth is preferred even when it forces
> DSC
>
> [You don't often get email from [email protected]. Learn why this
> is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> Here is dmesg log with the options requested, on stock 7.2.0-rc7-mainline
> (FRL but no VRR) All my testing was done at 4k@120hz, if you want me to do a
> more complete resolution and refresh rate sweep that's possible.

Thanks for your full dmesg that is clear. What I see from the log are:
1. Link detect: probe whatever the maximum link rate --> FRL5 for LG TV SSCR2
2. SetMode 4k60 RGB-12bpc:   Adopts FRL3 w/o DSC
3. SetMode 4k120 RGB 12-bpc: Adopts FRL2 + DSC --> pick up the link rate that barely fits the mode

The referred "YUV444 10bpc" is set as the "best" ranker but does not chase the maximum encoding/depth by Windows.
It aims at a specific target value and picks whichever enumerated timing sits closer to that "nearest-to-configured-target".

However, Linux has a user space capped max_requested_bpc that cannot fully honor the pre-defined "best" ranker (YUV444 10bpc).
In addition, Linux mode validation is "per-mode validation", instead of "enumerate-all, then rank" routine. That makes it impossible
to consider all other available modes and pick-up optimal encoding/depth combination.
Those are two major architectural delta makes a "greedy validate-first" policy is preferable to Linux, compared to "nearest-to-configured-target".
It basically ties to encoding outer (high priority), depth inner (low priority) until the validation passes.

Please let me know if there is any functional defect.
If not, it is simply a policy implementation delta without functional gap, given the architectural delta between OS.

Regards,
Jerry

>
> On Mon, 17 Aug 2026 at 21:01, Zuo, Jerry <[email protected]> wrote:
> >
> > AMD General
> >
> > > -----Original Message-----
> > > From: Antoine Richermoz <[email protected]>
> > > Sent: Monday, August 17, 2026 05:00
> > > To: Wentland, Harry <[email protected]>
> > > Cc: Zuo, Jerry <[email protected]>;
> > > [email protected];
> > > [email protected]
> > > Subject: HDMI FRL: EDID max bit depth is preferred even when it
> > > forces DSC
> > >
> > > [You don't often get email from [email protected]. Learn
> > > why this is important at
> > > https://aka.ms/LearnAboutSenderIdentification ]
> > >
> > > Hi Harry,
> > >
> > > A question about the bit depth and DSC policy for HDMI FRL, with
> > > test data from an RX 6800 (DCN 3.0) driving an LG 42C2 at
> > > 3840x2160p120, stock v7.2-
> > > rc7 with amdgpu.dcfeaturemask=0x402, direct HDMI, no PCON.
> > > As an aside, with Tomasz's out of tree HDMI VRR patches on top of
> > > the same base, FRL and native HDMI VRR come up and stay active
> > > together on this DCN generation, which I had not seen reported anywhere
> before.
> > >
> > > By default the stream ends up at 12bpc with DSC on, at 3 lanes and 6Gbps.
> > > The path there:
> > >
> > > - FRL verification trains at rate 5 (4 lanes at 10Gbps) on the first
> > >   attempt with no fallback, so the link is not the constraint.
> > > - Color depth is committed before DSC is considered and defaults to
> > >   the EDID maximum, 12bpc. At this timing
> > >   dc_bandwidth_in_kbps_from_timing() gives 42.77 Gbps for 12bpc RGB,
> > >   above the 40 Gbps dc_link_frl_bandwidth_kbps() reports for rate 5,
> > >   so apply_dsc_policy_for_stream() enables DSC.
> > > - Nothing afterwards reconsiders the depth. dc_dsc_compute_config()
> > >   is called with the 12bpc timing and the sink advertises DSC decode
> > >   at 12bpc, so it succeeds. The DSC target comes from
> > >   frl_dsc_max_frl_rate, which is 3 on this sink, so 24 Gbps, and
> > >   hdmi_frl_decide_link_settings() then walks up from the lowest rate
> > >   and stops at the first one that validates, 3 lanes at 6Gbps.
> > >
> > > Capping GNOME's max bpc setting to 10, via a maxbpc element in the
> > > monitor entry of monitors.xml, gives the other outcome on the same
> > > kernel, cable and display: 10bpc RGB needs 35.64 Gbps, fits the
> > > verified rate uncompressed, so no DSC, and the stream runs at 4 lanes and
> 10Gbps.
> > >
> > > I am honestly not sure which of the two is preferable. I have not
> > > done careful side by side testing and I cannot see a difference
> > > between 12bpc with DSC and 10bpc without it. What made me look in
> > > the first place is that the AMD Windows driver ends up at YCbCr444
> > > 10bpc at 4 lanes and 10Gbps on the same GPU, cable and TV, and
> > > without DSC. The TV's info panel flags DSC when it is active, and it
> > > does flag it in the default Linux case but not on Windows. So I
> > > thought you should know the Linux default lands somewhere else. One
> other detail that may matter:
> > > this sink advertises DSC decode at 12bpc only, with a DSC FRL rate
> > > cap of 3, so uncompressed 12bpc at this timing is not reachable on
> > > this link at all, and the panel is 10 bit in any case.
> > >
> > > So the question: is preferring the maximum advertised depth
> > > deliberate policy for HDMI FRL, or would it make sense to try lower
> > > depths against the verified link rate before enabling DSC? The max
> > > bpc property does get there, but it needs the user to know that, and
> > > on a GNOME desktop it means hand editing a config file that
> > > configuration tools can rewrite, while the driver already has the
> information.
> > >
> > > One thing worth flagging, since it bears on any step down: for
> > > DC_LINK_ENCODING_HDMI_FRL, dc_bandwidth_in_kbps_from_timing()
> > > returns the raw pixel rate times bpp product and it is compared
> > > against the raw FRL line rate, with no 16b/18b coding overhead on
> > > either side, so the comparison is optimistic by about 12 percent.
> > > 10bpc at this timing is therefore a lot closer to the rate 5 limit
> > > than 35.64 against 40 Gbps makes it look. What actually gates the
> > > mode is the capacity check reached from frl_validate_mode_timing(),
> > > which did accept it, so nothing unsafe happens today. Two related
> > > loose ends there: the dc_crtc_timing field that would supply the
> > > accurate figure, frl_uncompressed_video_bandwidth_in_kbps, is read
> > > in
> > > dc_bandwidth_in_kbps_from_timing() but never assigned anywhere in
> > > the tree, and dc_link_frl_margin_check_uncompressed_video() is
> > > exported in dc.h and wired up in link_factory.c but has no callers.
> > > If a depth step down were ever added, gating it on that check rather
> > > than on the coarse comparison seems like the right basis.
> > >
> > > I also have a debugfs proof of concept that does the step down
> > > inside apply_dsc_policy_for_stream(), written quickly with Claude
> > > Sonnet while I was diagnosing this, which I am happy to send if it
> > > is useful. It is not needed to reproduce any of the above.
> > >
> > > Happy to run further tests or provide EDID and FRL logs from this
> hardware.
> >
> > Thanks for your feedback. Please kindly attach full dmesg log by
> "drm.debug=0x106 log_buf_len=50M amdgpu.dcfeaturemask=0x402"
> >
> > I'd like to clarify the link rate selection policy as below.
> > 1. link detection: try the maximum link rate that the sink supports, and
> could pass link training, e.g., 4k120 FRL5 40G. This step is trying to probe the
> maximum link capability.
> > 2. Set_mode link training policy: try minimum link rate that can
> > barely support the resolution, e.g., 4k120 12-bpc FRL3 24G + DSC, in stead of
> FRL6 w/o DSC 3. Each Mode Validation Policy:
> >     a. Build up available pixel encoding and color depth table based on the
> edid
> >     b. Go through each combination by the policy: have optimal pixel
> encoding first, then try to walk through available bpc from top to bottom,
> until the optimal pixel encoding and color depth combination is found.
> >
> > Step #1 and #2, both OS shares the same policy, but step #3 could be
> diverged. Step #3 will eventually determine what pixel encoding and color
> depth will be used for each validated resolution.
> >
> > It would be helpful if you can briefly summarize what resolutions you
> observed in each experiment compared to Windows driver.
> >
> > >
> > > Thanks,
> > > Antoine Richermoz (rcmz)