顯示核心除錯工具

在本節中，你將找到關於從顯示角度除錯 amdgpu 驅動程式的有用資訊。本頁介紹除錯機制和程式，以幫助你確定某些問題是否與顯示程式碼有關。

縮小顯示問題範圍

由於顯示是驅動程式的視覺元件，因此使用者經常報告問題，但實際上問題是由另一個元件引起的。本節旨在幫助使用者確定特定問題是由顯示元件還是驅動程式的另一部分引起的。

DC dmesg 重要訊息

dmesg 日誌是要檢查的第一個資訊來源，amdgpu 透過記錄一些有價值的資訊來利用此功能。查詢與 amdgpu 相關的問題時，請記住驅動程式的每個元件（例如，smu、PSP、dm 等）都是逐個載入的，此資訊可以在 dmesg 日誌中找到。 從這個意義上講，請查詢看起來像以下日誌片段的日誌部分

[    4.254295] [drm] initializing kernel modesetting (IP DISCOVERY 0x1002:0x744C 0x1002:0x0E3B 0xC8).
[    4.254718] [drm] register mmio base: 0xFCB00000
[    4.254918] [drm] register mmio size: 1048576
[    4.260095] [drm] add ip block number 0 <soc21_common>
[    4.260318] [drm] add ip block number 1 <gmc_v11_0>
[    4.260510] [drm] add ip block number 2 <ih_v6_0>
[    4.260696] [drm] add ip block number 3 <psp>
[    4.260878] [drm] add ip block number 4 <smu>
[    4.261057] [drm] add ip block number 5 <dm>
[    4.261231] [drm] add ip block number 6 <gfx_v11_0>
[    4.261402] [drm] add ip block number 7 <sdma_v6_0>
[    4.261568] [drm] add ip block number 8 <vcn_v4_0>
[    4.261729] [drm] add ip block number 9 <jpeg_v4_0>
[    4.261887] [drm] add ip block number 10 <mes_v11_0>

從上面的示例中，你可以看到報告 <dm> (顯示管理器) 已載入的行，這意味著顯示可能是問題的一部分。 如果你沒有看到該行，則可能在 amdgpu 載入顯示元件之前發生了其他故障，表明我們沒有顯示問題。

在你確定 DM 已正確載入後，你可以檢查正在使用的硬體的顯示版本，該版本可以從 dmesg 日誌中使用以下命令檢索

dmesg | grep -i 'display core'

此命令顯示一條類似於此的訊息

[    4.655828] [drm] Display Core v3.2.285 initialized on DCN 3.2

此訊息包含兩個關鍵資訊

  • DC 版本 (例如，v3.2.285)：顯示開發人員每週釋出一個新的 DC 版本，如果使用者/開發人員必須根據顯示程式碼的經過測試的版本找到好點與壞點，則此資訊可能是有利的。 請記住來自頁面 顯示核心，每週都會使用 IGT 和手動測試對顯示的新補丁進行大量測試。

  • DCN 版本 (例如，DCN 3.2)：DCN 塊與硬體代相關聯，DCN 版本傳達驅動程式當前正在執行的硬體代。 此資訊有助於縮小程式碼除錯區域的範圍，因為每個 DCN 版本在每個 DCN 元件的 DC 資料夾中都有其檔案（例如，開發人員可能希望專注於具有 dcn32 標籤的檔案/資料夾/函式/結構）。 但是，請記住，DC 在不同的 DCN 版本之間重複使用程式碼； 例如，預期在一個 DCN 中設定的一些回撥與另一個 DCN 中的回撥相同。 總之，僅將 DCN 版本用作指南。

從 dmesg 檔案中，還可以透過使用以下命令獲取 ATOM bios 程式碼

dmesg  | grep -i 'ATOM BIOS'

這將生成如下所示的輸出

[    4.274534] amdgpu: ATOM BIOS: 113-D7020100-102

此類資訊有助於報告。

避免載入顯示核心

有時，可能很難確定驅動程式的哪一部分導致了問題； 如果你懷疑顯示不是問題的一部分，並且你的錯誤場景很簡單（例如，某些桌面配置），你可以嘗試從等式中刪除顯示元件。 首先，你需要從 dmesg 日誌中識別 dm ID； 例如，搜尋以下日誌

[    4.254295] [drm] initializing kernel modesetting (IP DISCOVERY 0x1002:0x744C 0x1002:0x0E3B 0xC8).
[..]
[    4.260095] [drm] add ip block number 0 <soc21_common>
[    4.260318] [drm] add ip block number 1 <gmc_v11_0>
[..]
[    4.261057] [drm] add ip block number 5 <dm>

從上面的示例中注意到，對於此特定硬體，dm id 為 5。 接下來，你需要執行以下二進位制運算來識別 IP 塊掩碼

0xffffffff & ~(1 << [DM ID])

從我們的示例中，IP 掩碼為

0xffffffff & ~(1 << 5) = 0xffffffdf

最後，要停用 DC，你只需要在你的引導載入程式中設定以下引數

amdgpu.ip_block_mask = 0xffffffdf

如果可以在停用 DC 的情況下啟動系統並且仍然看到問題，則意味著你可以將 DC 排除在等式之外。 但是，如果錯誤消失，你仍然需要考慮作為問題一部分的 DC 並繼續縮小問題的範圍。 在某些情況下，停用 DC 是不可能的，因為可能需要使用顯示元件來重現問題（例如，玩遊戲）。

注意：這可能會導致沒有顯示輸出。

顯示閃爍

顯示閃爍可能有多種原因； 其中之一是 GPU 電源不足或 DPM 切換出現問題。 一個好的第一個通用驗證是將 GPU 設定為使用高電壓

bash -c "echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level"

上面的命令將 GPU/APU 設定為使用允許的最大功率，這將停用 DPM 切換。 如果強制 DPM 級別升高不能解決問題，則問題與電源管理相關的可能性較小。 如果問題消失，則很有可能涉及其他元件，並且不應忽略顯示，因為這可能是 DPM 問題。 從顯示方面來看，如果功率增加解決了問題，則值得除錯時鐘配置和特定配置中使用的管道分割策略。

顯示偽影

使用者可能會看到一些螢幕偽影，這些偽影可以分為兩種不同的型別：區域性偽影和一般偽影。 區域性偽影發生在某些特定區域，例如 UI 視窗角附近； 如果你看到此類問題，則很有可能存在使用者空間問題，可能是 Mesa 或類似問題。 一般偽影通常發生在整個螢幕上。 它們可能是由顯示引數的驅動程式級別的錯誤配置引起的，但使用者空間也可能導致此問題。 識別問題來源的一種方法是在問題發生時擷取螢幕截圖或進行桌面影片捕獲； 檢查螢幕截圖/影片錄製後，如果你沒有看到任何偽影，則表示該問題可能發生在驅動程式端。 如果你仍然可以在收集的資料中看到問題，則這是可能在渲染期間發生的問題，並且顯示程式碼只是獲取了已損壞的幀緩衝區。

停用/啟用特定功能

DC 有一個名為 dc_debug_options 的結構，該結構由所有基於特定硬體特性的 DCE/DCN 元件靜態初始化。 由於開發人員可以從許多停用的功能開始並單獨啟用它們，因此該結構通常有助於啟動階段。 這也是一個重要的除錯功能，因為使用者可以在除錯特定問題時更改它。

例如，dGPU 使用者有時會看到一個問題，即在螢幕的某些特定部分發生水平閃爍的線狀物。 這可能表明子視口問題； 在使用者識別目標 DCN 後，他們可以在 dc_debug_options 的靜態初始化版本中將 force_disable_subvp 欄位設定為 true，以檢視問題是否得到解決。 同樣，使用者/開發人員也可以嘗試關閉 fams2_config 和 enable_single_display_2to1_odm_policy。 總之，dc_debug_options 是識別問題的一種有趣形式。

DC 視覺化確認

顯示核心提供一項名為視覺化確認的功能，該功能是由驅動程式在掃描輸出時新增的一組條形，用於傳達一些特定資訊。 通常，你可以使用以下方法啟用此除錯選項

echo <N> > /sys/kernel/debug/dri/0/amdgpu_dm_visual_confirm

其中 N 是開發人員要啟用的某些特定場景的整數，你將在以下小節中看到其中的一些除錯案例。

多個平面除錯

如果你想在特定的使用者空間應用程式中啟用或除錯多個平面，你可以利用一個名為視覺化確認的除錯功能。 要啟用它，你將需要

echo 1 > /sys/kernel/debug/dri/0/amdgpu_dm_visual_confirm

你需要重新載入你的 GUI 才能看到視覺化確認。 當平面配置更改或發生完全更新時，將在螢幕上繪製的每個硬體平面的底部顯示一個彩色條。

  • 顏色表示格式 - 例如，紅色是 AR24，綠色是 NV12

  • 條的高度表示平面的索引

  • 如果存在高度差異覆蓋同一平面的兩個條，則可以觀察到管道分割

考慮影片播放的情況，其中影片在特定平面中播放，桌面在另一個平面中繪製。 影片平面應在影片底部具有一個或兩個綠色條，具體取決於管道分割配置。

  • 應該沒有任何視覺損壞

  • 應該沒有任何下溢或螢幕閃爍

  • 應該沒有任何黑屏

  • 應該沒有任何游標損壞

  • 在視窗轉換或調整大小期間，多個平面可能會被短暫停用，但在操作完成後應恢復

管道分割除錯

有時我們需要除錯 DCN 是否正確分割管道，並且視覺化確認對於這種情況也很方便。 與 MPO 案例類似，你可以使用以下命令啟用視覺化確認

echo 1 > /sys/kernel/debug/dri/0/amdgpu_dm_visual_confirm

在這種情況下，如果你有管道分割，你將在顯示器的底部看到一個小紅條，覆蓋整個顯示器寬度，另一個條覆蓋第二個管道。 換句話說，你將在第二個管道中看到一個有點高的條。

DTN 除錯

DC (DCN) 提供了一個廣泛的日誌，該日誌轉儲了我們硬體配置的多個詳細資訊。 透過 debugfs，你可以使用顯示測試下一步 (DTN) 日誌捕獲這些狀態值，該日誌可以透過使用 debugfs 捕獲

cat /sys/kernel/debug/dri/0/amdgpu_dm_dtn_log

由於此日誌會根據 DCN 狀態進行更新，因此你還可以透過使用類似

sudo watch -d cat /sys/kernel/debug/dri/0/amdgpu_dm_dtn_log

報告與 DC 相關的錯誤時，請考慮在重現錯誤之前和之後附加此日誌。

收集韌體資訊

報告問題時，擁有韌體資訊很重要，因為它有助於除錯。 要獲取所有韌體資訊，請使用命令

cat /sys/kernel/debug/dri/0/amdgpu_firmware_info

從顯示的角度來看，請注意 DMCU 和 DMCUB 的韌體。

DMUB 韌體除錯

有時，dmesg 日誌是不夠的。 如果某個功能主要在 DMUB 韌體中實現，則尤其如此。 在這種情況下，當出現問題時，我們在 dmesg 中看到的所有內容都是一些通用的超時錯誤。 因此，為了獲得更相關的資訊，我們可以透過啟用 amdgpu_dm_dmub_trace_mask 中的相關位來跟蹤 DMUB 命令。

目前，我們支援跟蹤以下組

跟蹤組

名稱

掩碼值

資訊

0x1

IRQ SVC

0x2

VBIOS

0x4

註冊

0x8

PHY DBG

0x10

PSR

0x20

AUX

0x40

SMU

0x80

MALL

0x100

ABM

0x200

ALPM

0x400

計時器

0x800

HW LOCK MGR

0x1000

INBOX1

0x2000

PHY SEQ

0x4000

PSR STATE

0x8000

ZSTATE

0x10000

發射器 CTL

0x20000

面板 CNTL

0x40000

FAMS

0x80000

DPIA

0x100000

SUBVP

0x200000

INBOX0

0x400000

SDP

0x4000000

重放

0x8000000

重放駐留

0x20000000

游標資訊

0x80000000

IPS

0x100000000

注意：並非所有 ASIC 都支援所有列出的跟蹤組

因此，要僅啟用 PSR 跟蹤，你可以使用以下命令

# echo 0x8020 > /sys/kernel/debug/dri/0/amdgpu_dm_dmub_trace_mask

然後，你需要啟用將跟蹤事件記錄到緩衝區，你可以使用以下命令執行此操作

# echo 1 > /sys/kernel/debug/dri/0/amdgpu_dm_dmcub_trace_event_en

最後，在你能夠重現你要除錯的問題後，你可以使用以下方法停用跟蹤並讀取跟蹤日誌

# echo 0 > /sys/kernel/debug/dri/0/amdgpu_dm_dmcub_trace_event_en
# cat /sys/kernel/debug/dri/0/amdgpu_dm_dmub_tracebuffer

因此，在報告與 PSR 和 ABM 等功能相關的錯誤時，請考慮在重現問題之前啟用掩碼中的相關位，並在你建立的任何錯誤報告中附加你從跟蹤緩衝區獲得的日誌。