Does your Source and Sink support DSC1.2?

Did some digging and found this thread:

CSV-1580 Thunderbolt 4 Portable 5-in-1 Hub connecting 3 displays

@MST1407 said this:
“… for DSC to work, Decode, Encode and Bypass needs to take place. We think that Iris xE should be able to do this as we have tested it with the CAC-1085/CAC-1586 adapters but not able to find DSC working on the Thunderbolt 4 hub. with the integrated chip.”

@MST1407, can you confirm that DSC works on the CAC-1586 and whether you were able to get [email protected] 4:4:4 with Iris Xe graphics?

.

For HBR3 x4 DisplayPort connection, 8K60 with 2376MHz HDMI timing requires [email protected] and 2069MHz CVT-RB2 timing requires [email protected]

Did you try creating a custom timing using CVT-RB2 calculation in case Windows won’t do DSC below 12bpp? I believe macOS only tries [email protected] but there might be a way to do other target bpp options.

If the CAC-1586 uses the same Realtek RTD2173 chip as the CAC-1085 then it might have some limitations:

The DisplayPort DPCD registers of the Realtek RTD2173 say it can do 1,2,4, or 8 slices at 340 Mp/s each which is 1360MHz for 4 slices and 2720MHz for 8 slices with a max slice width of 2560.

Does the GPU and driver and display support 8 slices? Or am I misinterpreting the DPCD (I don’t have the DisplayPort 1.4 spec)? I believe AMD drivers in macOS were limited to 4 slices but will allow 8 slices in macOS Ventura (but macOS doesn’t enable DSC in a lot of cases since after Catalina).

AMD and macOS are just examples of GPU and OS. An option for you might be Linux (for testing purposes), but probably not for your work machine.

I believe Intel’s Graphics Command Center has an option to create a custom timing. You may want to try a custom timing with Nvidia first since you know that GPU has full 8K60 4:4:4 support, just to verify that the TV can support a custom 8K60 timing.

The Nvidia or Intel tools may have the ability to extract the EDID from the TV. Then we can examine it to see what kind of DSC it supports using edid-decode. Or you can try Custom Resolution Utility (CRU) to extract the EDID. Hopefully, they’ll extract the entire EDID, and not just the first couple blocks.

For Display Stream Compression (DSC), the display image is divided into slices. This helps with parallel processing to decompress the image. For example one slice of 8K width requires processing 2376 megapixels per second. But if that’s divided into 8 slices, then each slice can be decompressed separately at 297 Mp/s. It also helps with errors – an error won’t affect more than the width of a slice.
https://www.quantumdata.com/assets/displayport_dsc_protocols_webinar.pdf

I don’t know an easy way to determine if Irse Xe supports 8 slices. Here’s a document that says 8 slices is possible:
https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-dg1-vol12-displayengine.pdf
There’s a lot of info in there about the calculations that I did not check. It doesn’t mean the drivers also support 8 slices (but I don’t see why they wouldn’t since we’re not talking about Apple). I don’t think that document is referring to the same GPU as yours though. The one for TigerLake is probably this Volume 12: Display Engine which shows mostly all the same limits as the discrete Intel Iris Xe Max GPU. All documentation is at
https://01.org/linuxgraphics/documentation/hardware-specification-prms

As for using a USB-C adapter with a DisplayPort only GPU, I think you’re only option is a Thunderbolt 3 Titan Ridge or Thunderbolt 4 Maple Ridge add-in card.

Intel graphics driver in Windows doesn’t have a method to switch bpc like AMD and Nvidia do except for maybe HDMI outputs. I suppose if it has a switch for HDR, then that might switch between 8bpc and 10bpc unless Windows can do HDR with 8bpc?

Another method to create custom timings is to make an EDID override using Custom Resolution Utility (CRU). Create a DisplayID extension block if one doesn’t already exist. Then add a detailed timing block inside that if one doesn’t already exist. Then add the custom 8K60 timing using CVT-RB2 calculation method.

The TV supports:
– 40 Gbps without DSC (8K60 at 4:2:2 8bpc or 4:2:0 10bpc for CVT-RB2 or just 4:2:0 8bpc for HDMI)
– 24 Gbps with DSC (8K60 10bpp for CVT-RB2 or 8bpp for HDMI). With this limited bandwidth for DSC, maybe a CVT-RB2 timing won’t be useful but it would be interesting to see if the TV can do it.

HBR3 x4 DisplayPort adapters have input of 25.92 Gbps so that makes DisplayPort 1.4 slightly more capable than the HDMI input of your TV at least for DSC.

Did you use edid-decode in macOS to see if it has any more info than SwitchResX? If you look at the edid-decode source code, you can see that “YCbCr 4:2:0 Capability Map Data Block” is a list of the VICs from “Video Data Block” which support RGB, 4:4:4, and 4:2:2 that also support 4:2:0 as you said.  This is explained in the “CTA-861-H: A DTV Profile for Uncompressed High Speed Digital Interfaces” spec referenced in the edid-decode man page. There is a separate data block called “YCbCr 4:2:0 Video Data Block” for 4:2:0 modes that don’t support RGB, 4:4:4, or 4:2:2. You can get the CTA spec but the HDMI 2.1 and DisplayPort 1.4 specs are not available. I’m not sure what a line of chunks is. 12288 bytes is enough for 3276.8 30bpp pixels or 8192 12bpp pixels. Maybe the linux source code has a clue.

I’m not sure why there’s a problem compiling the head branch. Try replacing all occurrences of 

[[clang::fallthrough]];

__attribute__ ((fallthrough));

CRU requires access to the registry where EDID overrides are kept (per display manufacturer/productid/GPU port).

Ok that edit fixed the compilation problems. edid-decode gives pretty much the same information as SwitchResX, except it has options for some more details, such as getting detailed timings for each VIC. I could have gotten those timings from wikipedia or the latest CTA manual though. Well I guess it also specifies that the standard VICs mentioned support both YCbCr 4:4:4 and 4:2:2, Underscans IT Video Formats by default, and has basic audio support.

I guess without CRU or system access, it sounds like I can’t diagnose and fix this problem, or at least not using my work laptop. Can anyone at Club-3D verify that this combo works though? 

What I’d like to know is what 8K60Hz 444 TV you actually have?

Could be a Samsung.

This one supports 4K120:
https://github.com/linuxhw/EDID/blob/f8504fd2caab513355286516d3a539017f747f7f/Digital/Samsung/SAM7040/27FC2B21B8CA

This one is limited to 60Hz:
https://github.com/linuxhw/EDID/blob/f8504fd2caab513355286516d3a539017f747f7f/Digital/Samsung/SAM7071/28BF4AF487CA

I have the 65″ QN800A! It’s still available for $2000 online, which IMO is actually a pretty good price given the size and resolution you get (good 32″ 4K monitors are >$500, and this TV is basically 4 of them without bezels in between). AFAIK these are the Samsung models that support 8K60hz 4:4:4:

• Q800TS and Q900TS (2020 models)
• QN800A and QN900A (2021 models)
• QN800B and QN900B (2022 models; 8K60hz 4:4:4 is so far unconfirmed, but processing should be the same as last year’s models)

Just note that at 8K, the TV adds some funky dithering in regular PC mode, but this goes away if you turn on Game Mode.

@joevt, I like how you reference TVs by EDID and not by model number 🙂

I only did a search for the EDID info you provided “Maximum number of bytes in a line of chunks: 12288” and those were the only two in the linux EDID database that matched. Those EDIDs don’t show a model number and the reviews at RTINGS.com don’t include EDID info.

8K, dithering, and macOS were discussed by you and others at  #248  but I didn’t remember who was all involved until I checked now. If I checked my collection of EDIDs I would have found these:

SAM_4c2d_703e Samsung 75″ Q800T 2020 8K monitor (4K)
SAM_4c2d_703f Samsung 75″ Q800T 2020 8K monitor (game mode on or auto (activates VRR) 8K)
SAM_4c2d_7040 Samsung 75″ Q800T 2020 8K monitor (8K without Free Sync)
SAM_4c2d_7153 Samsung Q900A (VRR)
SAM_4c2d_7154 Samsung Q900A (no VRR)

You can PM me at macrumors.com and post it in that thread about 8K. Just the hex string is sufficient.