全解析:從原理到DP認證測試)
如果你這兩年買過4K 144Hz以上的顯示器或者折騰過8K電視大概率已經(jīng)接觸過DSC這項顯示流壓縮技術(shù)只是廠商沒在你臉上貼標簽。DSC全稱Display Stream Compression是VESA組織制定的顯示流壓縮標準核心目標是在不犧牲肉眼可感知畫質(zhì)的前提下把一條顯示鏈路能傳輸?shù)膱D像數(shù)據(jù)量壓到原來的三分之一左右。先說明一下這里的DSC和醫(yī)學(xué)超聲設(shè)備里的圖像處理DSC、數(shù)據(jù)庫集群里的DSC不是一個東西我們只聊顯示接口領(lǐng)域的這個。我自己是從DP 1.2時代一路調(diào)過EDID、改過驅(qū)動、測過鏈路的老工程師這幾年最直觀的感受是沒有DSC今天所謂的4K高刷、8K60甚至8K120全都得靠降色深、轉(zhuǎn)YCbCr來湊體驗稀碎。DSC的出現(xiàn)把顯示接口從單純的“帶寬軍備競賽”拉回到“協(xié)議與算法協(xié)同”的賽道這也是為什么DP 1.4之后DSC幾乎是中高端產(chǎn)品的默認配置。這篇文章想把DSC這件事講透它到底是什么算法、在DisplayPort鏈路上怎么工作、以及過VESA官方認證測試時你大概會踩到哪些坑。適合三類人看做顯示器和顯卡/筆記本的硬件工程師、寫驅(qū)動和固件的軟件同學(xué)、以及純粹想搞清楚“為什么DSC關(guān)不掉”的高級玩家。1. 帶寬焦慮為什么中高端顯示設(shè)備離不開DSC1.1 先算一筆帶寬賬顯示接口的本質(zhì)就是一根數(shù)字水管單位時間內(nèi)能流過的像素數(shù)據(jù)有限。DisplayPort用lane通道的方式并行傳數(shù)據(jù)DP 1.4時代一根線是4條lane每條lane跑HBR3速率8.1Gbps物理層還要做8b/10b編碼也就是每傳10個bit只有8個bit是真正有效的數(shù)據(jù)所以總有效帶寬是4 × 8.1 × 0.8 25.92Gbps這個數(shù)字意味著什么我們按最常用的RGB 4:4:4、10bit色深來算幾個典型需求的帶寬如下4K3840×2160144Hz約35.8GbpsDP 1.4極限速率裝不下需要約1.4:1的壓縮5K5120×288060Hz約26.5Gbps剛好貼著DP 1.4的天花板8K7680×432060Hz約59.7GbpsDP 1.4連零頭都裝不下8K 120Hz約119.4Gbps即便DP 2.1的UHBR20理論有效帶寬約77.6Gbps依然裝不下。所以如果不想各種限制分辨率、刷新率、色深壓縮幾乎是唯一出路。DSC的常見壓縮比是2:1到3:1把8K60壓到20Gbps左右DP 1.4就能跑把8K120壓到40Gbps出頭DP 2.0和2.1的UHBR13.5以上也能跑。這就是DSC存在的最大理由。1.2 傳統(tǒng)妥協(xié)方案的代價在DSC普及之前業(yè)界靠什么硬撐高刷主要就兩招降色深、降色度采樣。降色深最直觀從10bit降到8bit立刻省掉20%帶寬。代價是漸變天空、暗部場景會出現(xiàn)肉眼可見的色帶也就是常說的banding。你在深色壁紙下看到一圈一圈的條紋多半就是8bit在作怪。降色度采樣則是把RGB轉(zhuǎn)成YCbCr再用4:2:2甚至4:2:0即壓縮色彩信息但保留亮度信息。這套方案電視上沒問題因為視頻內(nèi)容本身就是4:2:0格式但放在桌面顯示器上就是災(zāi)難文字邊緣出現(xiàn)彩邊、UI線條發(fā)虛、鼠標指針都可能帶一圈顏色。這兩招本質(zhì)上都是棄畫質(zhì)保流暢用戶不傻體驗一個比一個差。DSC的價值就在于你依然拿RGB 4:4:4 10bit的數(shù)據(jù)進去出來的還是RGB 4:4:4 10bit只是中間傳輸時被“看似有損”地壓縮了一下眼睛基本看不出來。1.3 DSC的本質(zhì)實時流式壓縮不是普通圖片壓縮有人會問那DSC和壓縮圖片的JPEG、PNG有什么區(qū)別區(qū)別大了。JPEG可以等整張圖片讀完再編碼壓縮率可以很高但延遲以毫秒甚至秒計。顯示鏈路不行像素是一行一行掃描出去的顯示器沒工夫等整幀壓縮完再解壓。DSC必須逐行、幾乎實時地完成編碼和解碼每一行像素從編碼到解碼的延遲被壓在微秒級。所以DSC的設(shè)計哲學(xué)很明確它不追求極限壓縮率追求的是在極低延遲下達到“視覺無損”效果。這是它和一般圖像壓縮算法的根本分水嶺也是后面所有技術(shù)細節(jié)的出發(fā)點。2. DSC壓縮原理拆解它到底怎么做到“肉眼無損”2.1 編碼器基本流程預(yù)測、量化、熵編碼DSC編碼器的工作流程簡單說是四步預(yù)測、量化、熵編碼、率控。預(yù)測這一步核心是利用已經(jīng)編碼完成的相鄰像素猜當前像素值是多少。DSC用的是一種叫改進中值自適應(yīng)預(yù)測MMAP的方案取左邊、上邊、左上角三個已經(jīng)重建的像素按一定規(guī)則取中值或均值得到一個預(yù)測值。對于大面積純色、漸變、自然紋理這類圖像這個預(yù)測值往往非常接近真實值產(chǎn)生的殘差接近零。殘差越小后面需要編碼的比特數(shù)就越少。打個比方你在紙上畫一條直線后面每一個點都能用“跟上一點差不多高”來推算根本不用記錄每個點的精確坐標只需要記錄少數(shù)偏離很大的點。DSC就是在干這件事只不過它工作在一行一行的像素流上而且是實時完成。2.2 量化利用人眼視覺特征的“狡猾”設(shè)計預(yù)測之后的殘差有大有小如果全部精確編碼數(shù)據(jù)量依舊可觀。DSC的做法是引入帶死區(qū)的量化器對接近零的小誤差直接當作零處理不花比特去記錄對較大的誤差用比較粗的階梯去近似。這樣能省下大量比特。關(guān)鍵是DSC并不是盲目粗糙它利用了人眼的對比度掩蔽效應(yīng)在高紋理區(qū)域眼睛對細節(jié)誤差的敏感度會顯著下降因為你已經(jīng)看不清細節(jié)了多一點噪聲區(qū)別不大在平坦區(qū)域則盡量保證誤差趨近于零避免出現(xiàn)肉眼可見的條紋和塊狀偽影。這套機制讓“看起來沒事”成為可能但從數(shù)值上說它確實是有損壓縮。2.3 率控實時流的命門率控是DSC區(qū)別于普通圖片壓縮的另一個核心。顯示鏈路要求每行、每個slice輸出的比特數(shù)嚴格控制在帶寬預(yù)算內(nèi)不能超也不能太少——太少等于浪費帶寬。DSC通過動態(tài)調(diào)整量化參數(shù)QP來實現(xiàn)這一點圖像內(nèi)容復(fù)雜時把QP調(diào)大一些犧牲一點細節(jié)圖像內(nèi)容簡單時把QP調(diào)小保留更多細節(jié)。DSC定義了三種率控模式極簡模式、靜態(tài)模式和動態(tài)模式。前兩種實現(xiàn)簡單但畫質(zhì)上限低動態(tài)模式允許每個slice根據(jù)局部復(fù)雜度實時調(diào)整QP畫質(zhì)最好也是目前主流實現(xiàn)采用的方式。率控如果調(diào)得不好復(fù)雜畫面下就會出現(xiàn)局部糊掉或者塊效應(yīng)這是DSC畫質(zhì)劣化最常見的表現(xiàn)。2.4 切片機制并行和低成本的基石DSC把一幀圖像水平切成若干個slice每個slice獨立編碼。slice寬度常見取32到256像素并且必須是32的倍數(shù)具體值取決于編碼器和解碼器line buffer的大小。為什么要切切片兩個原因。第一是并行多個slice可以同時編碼降低延遲也讓硬件實現(xiàn)更簡單。第二是解碼端內(nèi)存有限尤其顯示器里的scaler和TCON芯片內(nèi)存通常只有幾KB到幾十KB不可能緩存整幀圖像。切片越小解碼器需要緩存的行數(shù)據(jù)越少芯片成本就越低。DP源端和sink端在啟動DSC前會協(xié)商slice參數(shù)這個參數(shù)會在PPS里明確傳遞兩邊必須一致如果廠商在這里實現(xiàn)不嚴謹最容易出互操作問題。2.5 色彩模式、位深和HDR的處理DSC本身支持6/8/10/12/16bpc輸入RGB、YCbCr 4:4:4/4:2:2/4:2:0也都支持。這就意味著它在色彩格式上相當靈活尤其能保留桌面用戶最在意的RGB 4:4:4 10bit。HDR的靜態(tài)元數(shù)據(jù)不參與DSC壓縮走的是DisplayPort的輔助通道SDP專用包因此HDR信息和壓縮流是分開傳輸?shù)慕獯a端不會被壓縮影響。所有編碼參數(shù)——位深、色彩格式、slice數(shù)、壓縮比、QP策略等——最終會被打包成一個叫PPSPicture Parameter Set的數(shù)據(jù)結(jié)構(gòu)通過DP輔助通道傳給接收端。接收端必須正確解析PPS再按照里面的參數(shù)去解碼壓縮流。這個PPS字段眾多牽一發(fā)動全身認證測試里很大一部分時間都在查它。3. 在DisplayPort上落地DSC從DP 1.4到DP 2.13.1 DSC與DP版本演進VESA在DP 1.4中首次把DSC 1.2納入標準但它是可選功能當鏈路帶寬不夠時源端和接收端協(xié)商啟用DSC。到DP 2.0和DP 2.1時代標準升級為DSC 1.2a配合UHBR10、UHBR13.5、UHBR20速率鏈路帶寬大幅提高。很多人以為DP 2.1帶寬大了就不需要DSC了其實不完全對。舉個具體例子8K60 10bit RGB需要約59.7GbpsUHBR20的77.6Gbps可以容納確實不需要DSC但8K120 10bit RGB需要約119.4GbpsUHBR20再翻倍都不夠DSC依然是必需品。所以在DP 2.1的規(guī)范里DSC依然保留只是使用場景更集中在超高刷和8K以上分辨率。3.2 DSC、FEC、SDP三件套必須一起理解在DisplayPort上啟用DSC并不是說把壓縮流扔進主鏈路就完事了。這里有兩個繞不開的伴隨機制。第一是FEC前向糾錯DP 1.4及以后的標準規(guī)定只要啟用DSC就必須同時啟用FEC。原因很現(xiàn)實壓縮后的數(shù)據(jù)一旦在傳輸中出現(xiàn)bit錯誤錯誤會擴散到一片區(qū)域看起來就是一整塊屏幕花掉。FEC通過里德-所羅門碼等糾錯算法在接收端把偶發(fā)錯誤先修復(fù)掉避免解碼器“吞”進壞數(shù)據(jù)。第二是PPS通過輔助通道SDP傳遞。PPS不是走主鏈路視頻流而是通過SDP包在輔助鏈路上傳給接收端。所以看DSC是否正常工作不能只盯主鏈路還得看輔助通道上有沒有正確的PPS包。曾經(jīng)有產(chǎn)品在PPS分包時偶發(fā)丟失結(jié)果畫面間歇性花屏排查了很久才定位到是SDP鏈路的問題。3.3 三種DSC工作形態(tài)端到端、直通、重定時不同設(shè)備里DSC的參與方式其實不太一樣主要分三種。第一種是端到端壓縮也是最常見的場景顯卡或SoC作為源端壓縮顯示器作為接收端解壓。大多數(shù)筆記本外接4K高刷顯示器和旗艦顯卡接8K電視都是這種模式。第二種是DSC直通passthrough常見于擴展塢、KVM和信號切換器。這類橋接設(shè)備不解壓DSC流直接原樣轉(zhuǎn)發(fā)。優(yōu)點是延遲低、成本低但要求橋接芯片必須完整轉(zhuǎn)發(fā)PPS和相關(guān)時序參數(shù)一旦丟字段后面的顯示器就無法正確解碼。第三種是DSC重建rebuild橋接設(shè)備先把壓縮流解壓再重新壓縮輸出通常是為了在中間疊加OSD菜單、畫中畫或者做畫面處理。這個模式畫質(zhì)和延遲都有額外損耗但功能靈活多用于會議系統(tǒng)和高端視頻處理設(shè)備。3.4 實際體驗DSC的開關(guān)、黑屏與VRR兼容很多用戶最困惑的是“DSC到底怎么關(guān)”。答案是當分辨率、刷新率、色深組合起來的帶寬超出物理鏈路限制時DSC由源端自動啟用用戶根本沒有開關(guān)。想關(guān)掉它唯一的辦法是降低規(guī)格到鏈路帶寬范圍內(nèi)。比如DP 1.4下4K144 10bit必然開DSC但降到4K100或者8bit也許就能關(guān)掉DSC。另一個常見現(xiàn)象是黑屏。切換分辨率或刷新率、從游戲全屏退到桌面等操作都可能讓DSC重新協(xié)商鏈路重新訓(xùn)練顯示器黑屏1到3秒。這在DSC時代非常普遍不是顯示器壞了。VRR方面VESA在DP 2.0的Adaptive-Sync能力中明確支持DSC與VRR共存但DP 1.4早期設(shè)備里DSC加VRR的組合偶爾會出現(xiàn)閃屏、無法進入最低刷新率的情況最后基本都是靠固件更新解決。如果你手頭的設(shè)備恰好有這個問題可以先試試把刷新率固定在一個中間值排除率控和VRR沖突的可能。3.5 怎么判斷當前是否啟用了DSC判斷DSC是否生效有幾個土辦法。Windows下打開NVIDIA控制面板或AMD驅(qū)動看輸出色深能選到10bpc還是只能選8bpc結(jié)合當前分辨率和刷新率大致能判斷是不是已經(jīng)超出帶寬。更直接的辦法是看顯示器OSD菜單很多品牌在DSC啟用時會顯示“DP DSC ON”之類的信息。Linux下可以用drm_info查看connector的DSC能力以及當前模式是否帶DSC標志。想深入看就抓DPCD日志看源端有沒有在DPCD 0x0060段的DSC控制寄存器里寫入使能值。這套方法不需要額外硬件做工程排查時足夠用。4. DisplayPort認證測試全解析從源端到接收端怎么過檢4.1 認證測試的定位VESA的合規(guī)測試Compliance Test是為了保證不同廠商的設(shè)備能互聯(lián)互通。DisplayPort CTS覆蓋物理層、鏈路層、協(xié)議層和應(yīng)用層DSC測試屬于協(xié)議層和應(yīng)用層之間的一塊和HDCP、VRR這些功能并列。如果你的產(chǎn)品要打DP官方Logo必須過CTS。不過檢也能賣但兼容性全看運氣在成熟市場基本是賣不動的因為你無法保證用戶手上的老設(shè)備能跟你配合好。DSC相關(guān)的測試核心是驗證三件事源端能不能正確壓縮并發(fā)送DSC流接收端能不能正確解壓并顯示以及兩邊的參數(shù)協(xié)商是否一致。下面按源端和接收端分開說。4.2 源端測試內(nèi)容能力通告、PPS、壓縮流校驗源端要過的測試我總結(jié)下來主要有四個大項。第一是能力通告。源設(shè)備必須在DPCD的正確位置聲明自己支持DSC以及支持到哪個版本、支持哪些slice配置、支持多少位深。如果這里寫錯了接收端會認為源端不支持DSC鏈路協(xié)商直接退回非DSC模式或者干脆無法點亮高刷。第二是PPS生成。測試儀會檢查源端發(fā)出的PPS包含的所有字段slice數(shù)、bits_per_pixel、位深、色彩格式必須合法且和實際輸出的數(shù)據(jù)流一致。這里最容易出問題的是slice相關(guān)字段比如slice_width超出接收端能力、slice_per_line算錯、壓縮比超過了帶寬預(yù)算等等任何一個字段不對接收端解出來的畫面就是花的。第三是壓縮流校驗。協(xié)議分析儀會把源端輸出的壓縮流完整抓下來解碼后檢查每個slice的輸出比特數(shù)是否滿足率控預(yù)算并對解碼圖像和原始圖像算質(zhì)量指標。VESA定義了一套標準測試圖像要保證壓縮后圖像的各項質(zhì)量指標不低于閾值。第四是FEC聯(lián)動。啟用DSC后FEC必須同時啟動。有些早期實現(xiàn)會把DSC和FEC做成兩個獨立開關(guān)調(diào)試時單獨開了DSC忘了開FEC測試儀直接判Fail。4.3 接收端測試內(nèi)容能力聲明、解碼正確性、抗誤碼接收端的測試重點和源端不一樣它不需要生成壓縮流但要把各種壓縮流都正確吃下來。首先是能力聲明接收端要在DPCD里準確告訴源端自己支持什么。這個聲明必須和實際解碼能力完全一致不能吹牛。有的顯示器為了過某些PC認證偽裝支持高解壓能力結(jié)果真遇到高壓縮比數(shù)據(jù)流就花屏。其次是解碼正確性。測試源會向接收端發(fā)送不同slice數(shù)、不同壓縮比、不同位深的DSC流接收端解碼后要能還原出清晰畫面。壓縮比越高對解碼器的率控還原能力要求越高如果某些參數(shù)組合處理不到位會出現(xiàn)塊效應(yīng)、橫紋等問題。再次是抗誤碼能力。前面提到FEC會在接收端修復(fù)部分傳輸錯誤接收端測試也要驗證在注入錯誤比特的情況下畫面不會出現(xiàn)大范圍花屏或者至少能把錯誤控制在局部。這個測試對很多顯示器方案是一道坎因為解碼器的容錯邏輯做得簡陋的話一個bit錯誤可能導(dǎo)致整幀畫面錯亂。4.4 測試設(shè)備與實驗室選擇做DSC認證測試硬件投入不低。DP 1.4時代常用的協(xié)議分析儀比如Unigraf UCD-400系列能完成不少DSC測試工作。到了DP 2.0/2.1時代需要支持UHBR速率和解碼更高帶寬壓縮流的設(shè)備UCD-500這類型號才開始接觸。再往上是Teledyne LeCroy、Keysight、泰克這類家的鏈路分析儀和示波器組合物理層和協(xié)議層一起測價格非常高。所以實際項目里中小團隊很少直接買全套設(shè)備更多是租借測試儀器或者把產(chǎn)品送去第三方兼容性實驗室做認證。也有一些芯片原廠會提供配合測試的工具和參考方案比如驗證PPS參數(shù)的腳本、抓DPCD的輔助工具能省不少事。我的建議是如果你只是開發(fā)一款顯示器或者擴展塢先用協(xié)議分析儀抓一遍關(guān)鍵場景的log確認DPCD和PPS沒有明顯問題再送實驗室這樣通過率高很多。4.5 我實際遇到的失敗案例這些年調(diào)DSC我踩過的坑不少挑幾個有代表性的說說。第一個是接收端能力聲明自相矛盾。某款顯示器明明支持4K144但它的DPCD能力寄存器里沒寫DSC結(jié)果接PC時只能跑4K60或者降色深。當時我們一度以為是固件bug后來查下來是工廠燒錄EDID時把DisplayID里的DSC能力塊漏掉了PC拿到錯誤信息自然不啟用DSC。第二個是PPS的slice配置不對。源端在某個分辨率下把slice_per_line算錯導(dǎo)致每個slice的寬度超出接收端line buffer尺寸接收端解碼時直接出錯。這個問題最難查的是表面現(xiàn)象畫面看起來是正常的但偶爾會閃一下馬賽克頻率毫無規(guī)律。后來用協(xié)議分析儀抓到PPS字段發(fā)現(xiàn)slice配置和一個老款sink的能力不匹配更新了slice算法才徹底解決。第三個是忘開FEC。這個我在調(diào)試早期也犯過單獨驗證DSC功能時只開了壓縮沒開FEC結(jié)果在長線傳輸場景下畫面偶發(fā)花屏。當時先懷疑線纜換了好幾條線都沒解決最后翻DPCD寄存器才發(fā)現(xiàn)FEC沒使能。從那以后我的調(diào)試清單里永遠寫著DSC和FEC必須成對檢查。第四個是UHBR20線纜問題。DP 2.1的認證要求線纜和連接器都得滿足UHBR20的物理層標準很多普通DP線在UHBR20下直接training失敗。這個其實不是DSC的問題但在實測中很容易和DSC失敗混在一起因為報錯現(xiàn)象都一樣點不亮或者頻繁黑屏。排查時先確認鏈路training成功再查DSC相關(guān)參數(shù)順序不能反。4.6 給做產(chǎn)品認證的三條經(jīng)驗第一把物理層和鏈路層調(diào)試穩(wěn)定之后再進入DSC測試。如果link training都沒調(diào)好DSC測出來的所有失敗都不可信先解決基礎(chǔ)問題能省很多時間。第二手頭至少要準備三到五臺不同品牌的源端或接收端做互操作驗證。實驗室的標準測試通過只代表符合規(guī)范真實世界的設(shè)備組合千奇百怪多試幾臺老設(shè)備往往能提前暴露PPS兼容性問題。第三保存完整的DPCD dump和PPS dump。DSC問題很多是偶發(fā)的沒有l(wèi)og等于沒查有了一份完整的dump反饋給芯片原廠或VESA工作組定位效率會高很多。日志里除了DSC相關(guān)寄存器EDID、DisplayID、SDP包都要一起存這些信息往往是關(guān)聯(lián)的。做這些測試多了以后我最大的感受是DSC本身并不神秘真正考驗工程能力的反而是那些協(xié)議細節(jié)——PPS字段是否對齊、FEC使能時序是否正確、sink的line buffer能力差異有沒有被考慮到。如果你手頭正好在調(diào)一個DP項目我的建議是盡早把協(xié)議分析儀接上從第一次link training就開始看log別等到畫質(zhì)測試階段才反過來查DSC配置。磨刀不誤砍柴工在顯示協(xié)議這個領(lǐng)域幾乎沒有比這更劃算的投入了。