在 HDMI 2.1 訊號傳輸中，發送端（如顯示卡）與接收端（如螢幕）並不是直接溝通「壓縮成 1/2 或 1/3」這種比例概念，而是透過將畫面切碎，並藉由 DSC_TotalChunkKBytes（快取硬體上限）與 DSC_MaxSlices（核心分割上限）的交集，共同計算出壓縮後的「目標每像素位元數（Target bpp, Bits Per Pixel）」。
當目標 bpp 被確定後，它與原始未壓縮影像的 bpc（Bits Per Component，例如 8-bit 或 10-bit 色深）進行對比，就會精準落入 1/2、1/3 甚至 1/4 的壓縮能力區間。
以下為這兩個參數相互作用，最終合併決定壓縮能力的完整拆解：
第一步：理解基本換算關係（bpp 與壓縮比）
我們常說的 1/2、1/3 壓縮能力，在 DSC 技術中對應的是硬體能處理的最低 Target bpp 限制。
以常見的 RGB 4:4:4 / YCbCr 4:4:4 格式為例（一個像素由 3 個顏色通道組成）：
- 原始 8-bit 色深 = 原始一個像素佔用 24 bit (8-bit × 3)
- 若要達到 1/2 壓縮：壓縮後的目標必須降至 12 bpp。
- 若要達到 1/3 壓縮：壓縮後的目標必須降至 8 bpp。
- 原始 10-bit 色深 = 原始一個像素佔用 30 bit (10-bit × 3)
- 若要達到 1/2 壓縮：壓縮後的目標必須降至 15 bpp。
- 若要達到 1/3 壓縮：壓縮後的目標必須降至 10 bpp。
第二步：兩個參數如何合力「卡死」bpp 上限？
接收端的硬體解碼線緩衝區（Line Buffer）是固定的。在點亮某一條水平掃描線時，硬體必須保證把所有被切碎的 Slice 數據全部塞進暫存區。
核心的硬體限制公式如下：
$$\text{單條線所需的總傳輸數據量} \le \text{DSC\_TotalChunkKBytes} \times 1024 \times 8 \text{ (bits)}$$
當顯示卡要計算這條線能用多高的 bpp（也就是多高的畫質）進行壓縮時，會受到這兩個參數的雙重夾擊：
1. DSC_MaxSlices 限制了「最小切片寬度」
DSC 規定一個 Slice 的水平寬度（Slice Width）不能無限大，因為晶片並行處理能力有限。
- 假設螢幕水平解析度為 $H_{\text{active}}$（例如 4K 的 3840 像素）。
- 顯示卡會根據螢幕宣告的
DSC_MaxSlices，計算出每個 Slice 的基本寬度：
$$\text{Slice Width} = \frac{H_{\text{active}}}{\text{實際使用的 Slices 數量（不超過 DSC\_MaxSlices）}}$$ - 例如：3840 像素 / 4 個 Slices = 每個 Slice 寬度 960 像素。
2. DSC_TotalChunkKBytes 限制了「每個切片的位元數」
在 DSC 語法中，一個 Slice 的水平像素壓縮後會被封裝成一個 Chunk（數據塊）。
為了讓硬體不溢流，所有 Slice 的 Chunk 大小加起來，不能超過
$$\text{每個 Chunk 的最大 Bits 數} = \frac{\text{DSC\_TotalChunkKBytes} \times 1024 \times 8}{\text{實際使用的 Slices 數量}}$$
為了讓硬體不溢流，所有 Slice 的 Chunk 大小加起來，不能超過
DSC_TotalChunkKBytes：$$\text{每個 Chunk 的最大 Bits 數} = \frac{\text{DSC\_TotalChunkKBytes} \times 1024 \times 8}{\text{實際使用的 Slices 數量}}$$
3. 兩者合併求出 Target bpp
把上面兩個限制結合，就能算出每個像素在被壓縮時，硬體所允許的最大目標 bpp（Target bpp）：
$$\text{Max Target bpp} = \frac{\text{每個 Chunk 的最大 Bits 數}}{\text{Slice Width}} = \frac{\text{DSC\_TotalChunkKBytes} \times 8192}{H_{\text{active}}}$$
$$\text{Max Target bpp} = \frac{\text{每個 Chunk 的最大 Bits 數}}{\text{Slice Width}} = \frac{\text{DSC\_TotalChunkKBytes} \times 8192}{H_{\text{active}}}$$
💡 關鍵發現：當我們把公式展開，實際使用的 Slices 數量被消去了。這意味著：DSC_TotalChunkKBytes與螢幕的解析度寬度 $H_{\text{active}}$ 直接決定了這台螢幕最高能承受多大的 bpp 能力！而DSC_MaxSlices則是在背後當守門員，確保在超高解析度下，有足夠的硬體並行核心（Slices）去把頻寬拆小消化。如果DSC_MaxSlices太小，即使緩衝區夠大，晶片也來不及解碼。
第三步：實例模擬（以 4K 畫面為例）
我們來看看硬體宣告不同的
假設我們要在 4K（水平 3840 像素）、10-bit 色深（原始 30 bit/pixel） 的螢幕上開通 DSC：
DSC_TotalChunkKBytes 時，如何改變壓縮能力。假設我們要在 4K（水平 3840 像素）、10-bit 色深（原始 30 bit/pixel） 的螢幕上開通 DSC：
情況 A：硬體配置較低（只能做到約 1/2 壓縮）
- 螢幕宣告：
DSC_TotalChunkKBytes= 32 KB，DSC_MaxSlices= 4 - 帶入公式算最大允許 bpp：
$$\text{Max Target bpp} = \frac{32 \times 1024 \times 8}{3840} \approx \mathbf{68.26 \text{ bpp}}$$ - 解讀：硬體緩衝區上限允許非常高的 bpp，但 DSC 標準規定的最高目標壓縮 bpp 通常為 12 或 15（以滿足 VESA 視覺無損標準）。此時硬體限制完全不是瓶頸，顯示卡可以從容地選擇 15 bpp（將 30-bit 壓縮成 15-bit，即精準的 1/2 壓縮），提供極高畫質。
情況 B：硬體配置極度受限（被迫進入 1/3 或 1/4 強制壓縮）
- 螢幕宣告：
DSC_TotalChunkKBytes= 4 KB（極小的快取），DSC_MaxSlices= 4 - 帶入公式算最大允許 bpp：
$$\text{Max Target bpp} = \frac{4 \times 1024 \times 8}{3840} \approx \mathbf{8.53 \text{ bpp}}$$ - 解讀：此時因為硬體緩衝區太小，算出來的限制值卡在 8.53 bpp。
- 結果：顯示卡被逼無奈，絕對不能使用 1/2 壓縮（15 bpp），因為會撐爆緩衝區。它必須向下尋找 DSC 規格內支援的更低檔位，選擇 8 bpp 進行編碼（將 30-bit 壓縮成 8-bit，即 1/3.75 壓縮，逼近 1/4 壓縮）。
總結
發送端在讀取 EDID 時的決策鏈如下：
- 看解析度寬度與
DSC_TotalChunkKBytes算出這台螢幕在硬體上最高承受的 bpp 上限。 - 看
DSC_MaxSlices決定要橫向切成幾個區塊來並行解碼。 - 根據算出的 bpp 上限，在 VESA DSC 標準定義的檔位中（如 8 bpp, 10 bpp, 12 bpp 等），選擇一個符合當下 HDMI FRL 頻寬、且不超過硬體上限的數值。這個數值就直接定義了當前是運作在 1/2、1/3 或更低的壓縮比率。
如果想要進一步了解在特定解析度（例如 8K @ 60Hz）下，如何逆推這兩個參數在 EDID（SCDS 暫存器） 的正確填寫數值，請告訴我！
