Aros/開發者/文件/HIDD/ATI

workbench/hidd/hidd.nouveau 中的程式碼包含 nouveau 和通用 drm 程式碼。您應該能夠在 radeon 驅動程式中重用大部分通用內容。至於 GART，基本上需要做的是為模擬頁面的 4k 邊界處分配的驅動程式記憶體提供記憶體。nouveau 驅動程式已經具有將此對映到卡地址空間的必要程式碼。假設 radeon 驅動程式也是如此。

Dri2 - 鎖定

Dri1 - 鎖定

直接渲染基礎設施的硬體鎖定 Rickard E. Faith、Jens Owen、Kevin E. Martin Precision Insight, Inc. $Date: 1999/05/11 22:45:24 $，$Revision: 1.6 $

本文考察了針對直接渲染基礎設施 (DRI) 目前可用於 PC 平臺的典型基於 DMA 的硬體的鎖定要求。描述了一種鎖定演算法。此演算法透過以下單一最佳化增強了典型的基於核心呼叫的阻塞鎖：最近持有鎖的實體可以在不使用核心呼叫的情況下請求鎖。該演算法依賴於原子指令，並且在時間和空間上都是常數。假設熟悉 DRI 設計文件 [OM98，MFOA99]。

1. 前言

1.1 版權

允許製作和分發此文件的逐字副本，前提是在所有副本上保留版權宣告和本許可宣告。

1.2 商標

OpenGL 是 Silicon Graphics, Inc. 的註冊商標。Unix 是 The Open Group 的註冊商標。“X”裝置和 X Window System 是 The Open Group 的商標。XFree86 是 XFree86 專案的商標。Linux 是 Linus Torvalds 的註冊商標。Intel 是英特爾公司的註冊商標。提到的所有其他商標均為其各自所有者的財產。

2. 鎖定要求

儘管某些卡可能支援某些同時訪問的子集，但典型的基於英特爾的 PC 圖形硬體（1998 年價格低於 2000 美元）不允許同時交錯訪問幀緩衝區記憶體、基於 MMIO 的命令 FIFO 和基於 DMA 的命令 FIFO。例如，典型的卡在處理控制硬體游標位置的 MMIO 暫存器的更新時，將允許幀緩衝區和命令 FIFO 活動。某些卡將透過 DMA 傳送的命令原子地新增到命令 FIFO 中，從而允許某些型別的同時 MMIO 和 DMA。但是，其他卡將在命令 FIFO 中逐字混合 MMIO 和 DMA 命令，從而完全破壞命令 FIFO。其他卡不夠健壯，無法在執行其他操作時允許幀緩衝區訪問。

由於這些限制，典型的硬體將需要一個單一的（每個裝置）鎖，該鎖協作地限制 X 伺服器、核心和 3D 直接渲染客戶端對硬體的訪問。本節簡要概述了三種類型的 DRI 實體通常如何使用硬體鎖。某些硬體可能不需要在本文件中列出的所有例項中進行鎖定。

2.1 核心

DMA 緩衝區排程

當硬體準備好從核心的 DMA 緩衝區佇列進行另一次 DMA 排程時，核心將獲取硬體鎖。如果有關另一次 DMA 排程可能性的通知是透過硬體中斷髮出的，則核心可能必須重置硬體上的中斷。如果當前 GLXContext 與下一個要排程的 DMA 緩衝區所需的 GLXContext 不同，則核心必須更新硬體圖形上下文，可能透過回撥到 X 伺服器（見下文）。

圖形上下文儲存和恢復

如果 X 伺服器代表核心執行硬體圖形上下文切換，則核心將在上下文切換期間代表 X 伺服器持有硬體鎖。X 伺服器可以透過執行 MMIO 或發出立即排程 DMA 的請求（無需獲取另一個鎖）來執行上下文切換，然後發出 ioctl 以告訴核心上下文已切換，現在可以安全地繼續進行 DMA 排程。

垂直同步

當操作（例如，DMA 緩衝區排程）必須與下一個垂直同步同步時，核心將獲取鎖並在執行操作之前輪詢或等待中斷。

2.2 3D 客戶端庫：軟體回退

3D 客戶端庫在執行需要直接硬體訪問（例如，訪問幀緩衝區）的軟體回退時將獲取硬體鎖。在此期間，客戶端可能會發出繞過正常核心 DMA 緩衝區佇列（並且不需要核心獲取鎖）的高優先順序阻塞 DMA 請求。

3D 客戶端庫假設當前 GLXContext 的核心 DMA 緩衝區佇列已重新整理，其他核心 DMA 緩衝區佇列已停止（透過獲取鎖隱含），硬體處於靜止狀態，並且當前完整圖形上下文可用（包括紋理和顯示列表）。初始 DRI 實現將假設此上下文儲存在硬體上，而不是在 SAREA 中。

2.3 X 伺服器

硬體游標

根據圖形硬體的要求，可能需要鎖來移動硬體游標。（在撰寫本文時，我們還沒有發現任何需要鎖定硬體游標移動的硬體，但我們注意到了這種可能性，以便未來的驅動程式實現者可以檢查它。）在不更改視窗偏移量的情況下進行 2D 渲染

X 伺服器的 2D 渲染將需要鎖，並且可能需要硬體處於靜止狀態（取決於正在執行的操作和使用的硬體）。

區域修改

區域修改（例如，移動視窗）需要鎖和硬體處於靜止狀態。此外，所有核心 DMA 緩衝區佇列都必須重新整理（可以根據要移動的視窗和該視窗觸發的 GLXContexts 計算出一組最佳化的 DMA 佇列，以進行重新整理）。區域修改後，將更新視窗更改 ID（此更新可能不需要加鎖）。

DGA

當應用程式使用 XFree86-DGA 協議擴充套件時，X 伺服器將代表 DGA 客戶端持有鎖。對於直接訪問硬體但不知道 DRI 的客戶端，必須支援 XFree86-DGA。

OpenGL/全屏

將提供一個新的協議擴充套件，允許在 DRI 框架內進行全屏 OpenGL 訪問。伺服器將發出一個 ioctl 來停止所有現有 GLXContexts 的核心 DMA 緩衝區佇列。從那時起，所有新建立的 GLXContexts 將擁有可操作的（即未停止的）核心 DMA 緩衝區佇列。這意味著客戶端必須在建立任何 GLXContexts 之前發出 OpenGL/全屏請求。

3. 最佳化機會

3.1 分析

X 伺服器、3D 客戶端和核心將協作共享鎖。由於客戶端程序在持有鎖時可能會死亡，因此某些程序必須檢測客戶端死亡並回收鎖。當用於 X 協議的連線失敗時，X 伺服器可以檢測到客戶端死亡。但是，在 UNIX 域套接字（即命名管道）的情況下，及時通知需要在連線上進行主動 I/O。然而，核心級裝置驅動程式在客戶端關閉與核心裝置驅動程式的連線時就會知道客戶端死亡。客戶端死亡的及時通知，以及其他核心級問題（例如，SIGSTOP 的處理 [FM99]），使得使用核心作為最終的鎖仲裁者變得很有必要。

但是，透過 ioctl 獲取硬體鎖是一個重量級操作。如果某個實體正在執行多個短操作，則為了提供使用者感知的互動性，必須為每個操作獲取和釋放鎖。下一節將探討透過引入兩級鎖來避免每次鎖定操作都執行 ioctl 的方法。本節透過探索常見實體狀態之間的轉換並根據以下一般標準識別效能關鍵的轉換，概述了兩級鎖設計的需求

   Interaction is optimized for a single GLXContext.
   User-perceived responsiveness of the X server is maintained.

為了分析的目的，系統具有以下狀態

    DA: The kernel dispatching DMA buffers for GLXContext A.
    DB: The kernel dispatching DMA buffers for GLXContext B.
    SA: A 3D client doing software fallbacks for GLXContext A. Software fallbacks are assumed to be slow operations, such that the overhead of obtaining the hardware lock, regardless of implementation, is negligible.
    SB: A 3D client doing a software fallbacks for GLXContext B.
    2D: The X server performing 2D rendering.
    HC: The X server moving the hardware cursor. This operation is lightweight, but a human is involved, so responsiveness is more important than overall speed.
    RM: The X server performing region modifications.

最佳化的重要性將按以下等級進行排序

   Optimization is critical to meet performance goals.
   Optimization will help meet performance goals, but is not critical.
   Optimization may help meet performance goals, but may not have a large performance impact.

以下是任意兩個狀態之間轉換的排名

         DA       DB       SA       SB       2D       HC       RM

DA        1        2        3        3        2        2        3

DB        2        1        3        3        2        2        3

SA        3        3        3        3        2        2        3

SB        3        3        3        3        2        2        3

2D        2        2        2        2        1        2        3

HC        2        2        2        2        2        2        3

RM        3        3        3        3        3        3        3

3.2 討論

由於我們的目標是最佳化單個 GLXContext 的吞吐量以及 X 伺服器的響應能力，因此最重要的是最佳化 DMA 分派和 2D 渲染的鎖定。如果核心長時間持有鎖，則響應能力會受到影響。如果 X 伺服器長時間持有鎖，則渲染吞吐量會受到影響。因此，核心和 X 伺服器不得持有鎖超過最少必要的時間。但是，由於 DMA 分派和 2D 渲染操作都相對較短，因此鎖將被頻繁地獲取和釋放：重量級基於 ioctl 的鎖定可能會佔執行操作所用時間的很大一部分。在高階基於 MMIO 的圖形硬體（即與可用的基於 DMA 的硬體相比）的情況下，基於 ioctl 的鎖的開銷將是禁止的。

由於這些需求和觀察結果，我們進行了兩級鎖的設計。我們採用作業系統術語，將兩種獲取鎖的方法稱為“重量級”和“輕量級”。上述討論中的關鍵觀察結果是，必須針對單個 GLXContext 連續多次獲取和釋放鎖來最佳化鎖定（對於此討論，X 伺服器將被視為一個特殊的 GLXContext）。特別是，輕量級鎖的設計並非用於在 GLXContexts 之間共享，因為這樣的設計可能會以犧牲更關鍵的情況為代價來使演算法複雜化（例如，透過要求輕量級例程中進行額外的工作來設定標誌或檢查重要的狀態，但在單個 GLXContext 的情況下很少或從未使用這些狀態）。

4. 鎖設計

4.1 簡介

以下假設將簡化鎖設計

   Locking will be performed using the GLXContext ID to determine which entity last had the lock (or a hash of this ID that makes at least two bits (e.g., the high bits) and one ID (e.g., zero) available as flags.
   The heavyweight lock will use the ioctl interface to the kernel (an ioctl has the approximate overhead of a system call).
   The heavyweight lock will be used to resolve all cases of contention.
   The lightweight lock will be stored in a user-space shared memory segment that is available to all locking entities.
   A pointer-sized compare-and-set (CAS) atomic primitive is available. This is true for most modern processors, including Intel processors starting with the Intel486 (a double-wide CAS instruction is available starting with the Pentium). Similar lightweight algorithms can be designed using other atomic primitives. (For older hardware, such as the Intel386, which will have extremely poor 3D graphics throughput, the lightweight lock may simply fallback to the heavyweight lock.)

4.2 之前的工作

[MCS91] 討論了利用繁忙等待和原子操作（由 fetch-and-phi 原語抽象）的同步演算法，但沒有討論兩級鎖定機制。

[BKMS98] 描述了一種“細鎖”，可以“膨脹”為“粗鎖”。但是，粗鎖不能“收縮”為細鎖，因此這些方法不適用於我們的工作。

[L87] 描述了一種方法，在沒有競爭的情況下，使用 7 次記憶體訪問來提供互斥。如果修改 Lamport 的演算法以在發生競爭時提供核心級回退，則可能可以使用更少讀取和寫入次數的演算法。但是，由於所有現代架構都提供原子 fetch-and-phi 原語，因此探索僅依賴於原子讀取和寫入的演算法的價值有限。

[LA93] 探索了結合繁忙等待和阻塞的“兩階段”演算法。本文中描述的兩級鎖是 Lim 和 Agarwal 的兩階段鎖，輪詢值設定為 1。但是，目前我們施加了限制，即只有最後一個擁有鎖的程序可以透過檢查同步變數來獲取鎖——所有其他鎖獲取都必須阻塞。將來，在我們獲得更多關於 DRI 競爭的經驗後，我們可能會擴充套件我們的鎖定演算法以成為一個完全通用的兩階段鎖。

Lim 和 Agarwal 指出，結合輪詢和訊號的好處的想法最初由 Ousterhout 在 [O82] 中提出。不幸的是，我們無法獲得本文的副本。

4.3 鎖定演算法

演算法和結構以類似 C 的程式語言表示。

鎖結構

鎖結構是一個簡單的快取行對齊整數。為了避免在多處理器系統上發生處理器匯流排競爭，不應該在同一快取行中儲存任何其他資料。

    typedef struct lock_s {
        unsigned int context;
        unsigned int padding[3];
    } lock_t;

標誌

鎖字中的位將用於宣告鎖，並通知客戶端核心必須參與競爭解決。

#define LOCK_HELD 0x80000000
#define LOCK_CONT 0x40000000

比較並交換 (CAS)

這是一個標準的 32 位比較並交換 (CAS) 例程。它可以使用單個 Intel486 指令以原子方式實現。在 RISC 處理器上，CAS 通常使用指令對 load-linked/store-conditional 實現。

    int CAS(int *address,
            int compare_value,
            int update_value)
    {
        if (*address == compare-value) {
            *address = update-value;
            return SUCCEED;
        } else
            return FAIL;
    }

獲取輕量級鎖

    void get_lightweight_lock(lock_t *L, int my_context)
    {
        if (CAS(&L->context, my_context, LOCK_HELD|my_context) == FAIL) {
            // Contention, so we use the kernel to arbitrate
            get_heavyweight_lock(L, my_context);
        }
    }

釋放輕量級鎖

    void release_lightweight_lock(lock_t *L, int my_context)
    {
        if (CAS(&L->context, LOCK_HELD|my_context, my_context) == FAIL) {
            // Kernel is requesting the lock
            release_heavyweight_lock(L, my_context);
        }
    }

獲取重量級鎖

    void get_heavyweight_lock(lock_t *L, int my_context)
    {
        for (;;) {
            do {
               // If lock held, mark it as contended
               // Otherwise, try to get it
               current_context = L->context;
               if (current_context & LOCK_HELD)
                   new = LOCK_CONT | current_context;
               else
                   new = LOCK_HELD | my_context;
            } while (CAS(&L->context, current_context, new));
            if (new == LOCK_HELD|my_context) break; // Have lock
            // Didn't get lock
            // Suspend process until lock available
            place_current_process_on_queue();
            schedule(); // blocks until wake_up_queued_processes() called
            // Loop and try to obtain lock again
        }
    }

釋放重量級鎖

    void release_heavyweight_lock(lock_t *L, int my_context)
    {
        L->context = 0; // CAS can be used to detect multiple unlocks
        wake_up_queued_processes();
    }

討論

獲取和釋放輕量級鎖都需要 CAS 指令，這可能會導致處理器匯流排 LOCK 迴圈。如果快取行駐留在當前處理器的快取中，則在 Pentium Pro 及更高版本的處理器上會避免匯流排 LOCK。由於這通常是使用此鎖的情況，因此在處理器數量上的可擴充套件性應該很好。在 RISC 處理器上，使用指令對 load-linked/store-conditional 來實現 CAS。此指令對不會導致匯流排鎖定，並且在處理器數量上具有良好的可擴充套件性。

如果鎖釋放使用簡單的寫操作而不是 CAS，則在程序確定核心需要鎖的時間和鎖被釋放的時間之間會存在競爭條件。在此期間，核心可能會設定請求的位。如果程序沒有意識到核心正在等待鎖，那麼核心將無法獲得鎖，直到同一個程序或另一個程序再次請求鎖。由於這可能永遠不會發生，因此可能會導致死鎖。

5. 致謝

感謝 James H. Anderson 討論鎖實現問題。

6. 參考文獻

[AM97] James H. Anderson 和 Mark Moir。大型物件的通用構造。提交給 IEEE 並行與分散式系統彙刊，1997 年 6 月。可從 http://www.cs.pitt.edu/~moir/Papers/anderson-moir-tpds97.ps 獲取。（本文的早期版本發表在第九屆國際分散式演算法研討會的論文集中，計算機科學講義 972，施普林格出版社，第 168-182 頁，1995 年 9 月。）

[BKMS98] David F. Bacon、Ravi Konuru、Chet Murthy 和 Mauricio Serrano。細鎖：Java 的輕量級同步。ACM SIGPLAN '98 程式語言設計與實現會議論文集（加拿大蒙特利爾，1998 年 6 月 17-19 日）。發表在 SIGPLAN 通告 33，5（1998 年 5 月），258-268 頁。

[FM99] Rickard E. Faith 和 Kevin E. Martin。直接渲染基礎設施的安全分析。德克薩斯州雪松公園：Precision Insight, Inc.，1999 年。

[L87 Leslie Lamport。一種快速的互斥演算法。ACM 計算機系統彙刊 5，1（1987 年 2 月），1-11 頁。

[LA93] Beng-Hong Lim 和 Anat Agarwal。大型多處理器同步的等待演算法。ACM 計算機系統彙刊 11，3（1993 年 8 月），253-294 頁。

[M92] Henry Massalin。合成：作業系統基本服務的有效實現。博士學位論文，發表為技術報告 CUCS-039-92。哥倫比亞大學文理研究生院，1992 年，71-91 頁。可從 ftp://ftp.cs.columbia.edu/reports/reports-1992/cucs-039-92.ps.gz 獲取。

[MCS91] John M. Mellor-Crummey 和 Michael L. Scott。共享記憶體多處理器上可擴充套件同步的演算法。ACM 計算機系統彙刊 9，1（1991 年 2 月），21-65 頁。

[MFOA99] Kevin E. Martin、Rickard E. Faith、Jens Owen、Allen Akin。直接渲染基礎設施，低階設計文件。德克薩斯州雪松公園：Precision Insight, Inc.，1999 年。

[O82] J. K. Ousterhout。併發系統的排程技術。在第三屆國際分散式計算系統會議論文集中。IEEE，紐約，1982 年，第 22-30 頁。

[OM98] Jens Owen 和 Kevin E. Martin。3D 的多管道直接渲染架構。德克薩斯州雪松公園：Precision Insight, Inc.，1998 年 9 月 15 日。可從 http://www.precisioninsight.com/dr/dr.html 獲取。10°

Vulkan

從南島（GCN 1.0）及更高版本的圖形核心下一代 (GCN) 架構支援 Vulkan（Radeon 7000 系列為 Vulkan 1.0，而 8000 系列 Sea Islands 為 GCN 2 並支援 Vulkan 1.1）。較早的非 GCN 架構不應該原生支援 Vulkan。

Vulkan 可能是驅動程式級別唯一需要的 API。OpenGL 和 Direct3D 可以透過包裝器使用。

Radeon 影片記憶體結構，GPU 擁有自己的虛擬記憶體和類似 CPU 的頁表。

需要渲染迴圈和其他主要部分

初始化和獲取資訊。
圖形記憶體分配 (AMDGPU_GEM_CREATE)。
GPU 虛擬記憶體對映 (AMDGPU_GEM_VA)。
將命令緩衝區傳送到 GPU 環形緩衝區 (AMDGPU_CS)。
處理中斷以瞭解命令執行何時完成 (AMDGPU_WAIT_CS)

Radeon GPU 擁有自己的 MMU 單元，因此每個使用 3D 加速的過程都有其自己的 GPU 虛擬地址空間。GPU 使用兩級頁表將虛擬地址對映到 GPU 物理地址。

在 Southern Islands Radeon GPU 上，物理記憶體佈局為

    0…VRAM size: VRAM (video RAM)
    VRAM size…GTT end: GTT (CPU memory mapped to GPU)

環形緩衝區需要管理從系統 RAM MMU 到 GPU MMU 的讀寫操作，並將編譯後的著色器和繪圖命令傳送到 GPU 管道。

引用計數的 GPU 緩衝區類和 GPU 記憶體管理器。記憶體管理器可以分配三種類型的記憶體

可對映到 CPU 的 VRAM，
不可對映到 CPU 的 VRAM，
對映到 GPU 的 CPU 記憶體 (GTT)。GTT 緩衝區

一個 GART 頁表，將 CPU 記憶體對映到 GPU GTT 記憶體範圍。因此，CPU 記憶體對映在使用者空間中進行，無需特殊的核心驅動程式。確保 GPU DMA 引擎可以寫入 GTT 記憶體

間接緩衝區允許在環形緩衝區上執行命令，而無需將其複製到環形緩衝區。而是將執行間接緩衝區命令寫入環形緩衝區，並將間接緩衝區地址和大小作為引數。Vulkan 驅動程式準備併發送間接緩衝區中的命令。

GTT 緩衝區測試。bufAdr 是由 GART 對映到 GPU 並由 GPU DMA 引擎寫入的作業系統區域地址。

參考文獻

我理解的“驅動程式”在你的術語中是指位於此模組之上並僅允許與單個輸出互動的東西嗎？

驅動程式就是驅動程式。它是一個軟體模組（如當前的 nvidia.hidd、radeon.hidd 等）。它們幾乎不會改變。它們是 HIDD 類，並將保持不變。還有一個驅動程式的例項，即驅動程式類的物件。這些東西將真正控制不同的顯示器。因此，例如，如果您有一個帶有兩個顯示器的 ATI 顯示卡和一個帶有另一個顯示器的 NVidia 顯示卡，您將有兩個驅動程式和三個例項。目前我們始終只有一個驅動程式的一個例項。

因此，驅動程式的一個例項將表示一個可控輸出。客戶端（graphics.library？）如何建立這樣的例項。透過 OOP_NewObject 作為通常方式。

目前透過 OOP_NewObject 建立驅動程式的例項很容易，因為您只需要執行一次，並且建立後您就知道自己控制了正確的輸出。使用新方法，建立驅動程式的例項將返回一個控制輸出的物件 - 但客戶端如何知道它是哪個輸出？客戶端如何知道可以有多少個輸出 - 或者換句話說，客戶端如何知道為所有輸出建立驅動程式物件？（除非我錯了，客戶端在此階段唯一可以使用的是 OOP_NewObject 呼叫）

這個模型對我來說沒有多大意義。“驅動程式”的一個例項應該表示一個單個顯示介面卡，並公開單獨的物件來表示 ldp - IMHO

不同的輸出（或不同的卡 - 這無關緊要）是不同的 OOP 物件。每個驅動程式物件（例項）都使用 AddDisplayDriverA() 在顯示模式資料庫中註冊。這些驅動程式被分配了不同的顯示模式 ID

0x0010xxyy - 第一個顯示器 0x0011xxyy - 第二個顯示器 0x0012xxyy - 第三個顯示器

等等。

xxyy 是驅動程式相關的 ID 部分，它編碼同步和畫素格式索引，與以前相同。為什麼從 0x0010 開始？因為 Amiga(tm) 晶片組使用佔用從 0x0000xxyy 到 0x000Axxyy 範圍的固定定義。並決定將 0x000B - 0x000F 作為保留，以防萬一。無論如何，系統中最多 65519 個顯示器就足夠了。:)

每個顯示驅動程式都已為其顯示模式提供名稱。只是驅動程式必須為使用者傳遞不同的名稱（“Radeon 模擬”，“Radeon DVI”，“Radeon N2 模擬”，“Radeon N2 DVI”等）。

客戶端如何知道可以有多少個輸出 - 或者換句話說，客戶端如何知道為所有輸出建立驅動程式物件？（除非錯了，客戶端在此階段唯一可以使用的是 OOP_NewObject 呼叫）

客戶端不會執行 OOP_NewObject() 呼叫。驅動程式模組將有一個啟動程式碼來執行此操作。新模型非常接近於目前所做的。只有一件事不同

當前模型：當執行 OOP_NewObject() 時，會找到第一個相容的 PCI 裝置併為其建立一個物件。

新模型：驅動程式啟動程式碼列舉所有 PCI 裝置併為每個裝置呼叫 OOP_NewObject()。它使用私有屬性來傳遞裝置基地址等。驅動程式類甚至不必具有公共名稱。是的，驅動程式不必是庫。它可以是位於 DEVS:Monitors 中的普通可執行檔案，就像在其他系統上一樣。這樣，它可以在任何時候啟動，並且其顯示模式將立即新增到系統中。

請參閱 arch/all-mingw32/hidd/wingdi/startup.c 作為示例。目前它只建立了一個物件，將來可以修改它以建立多個物件來模擬多個顯示器（每個顯示器將有一個單獨的主機視窗）。這種方法甚至允許使用舊驅動程式，直到它們被重寫。它們需要一個非常小的載入程式。到那時，我將繼續進行轉換，建立 DEVS:Monitors，並編寫這樣的載入程式。

啟動序列中將沒有 LoadMonDrvs。IMHO，載入顯示驅動程式的更好位置是 dosboot 常駐程式，在 inithidds.c 中

R100 Radeon 7000

R200 Radeon 8000

RS400/RS480 Radeon XPRESS 200(M)/1100 IGP

R300 Radeon 9700PRO/9700/9500PRO/9500/9600TX，FireGL X1/Z1 R350 Radeon 9800PRO/9800SE/9800，FireGL X2 R360 Radeon 9800XT RV350 Radeon 9600PRO/9600SE/9600/9550，M10/M11，FireGL T2 RV360 Radeon 9600XT RV370 Radeon X300，M22 RV380 Radeon X600，M24 RV410 Radeon X700，M26 PCIE R420 Radeon X800 AGP R423/R430 Radeon X800，M28 PCIE R480/R481 Radeon X850 PCIE/AGP

RV505/RV515/RV516/RV550 Radeon X1300/X1400/X1500/X1550/X2300 R520 Radeon X1800 RV530/RV560 Radeon X1600/X1650/X1700 RV570/R580 Radeon X1900/X1950

RS600/RS690/RS740 Radeon X1200/X1250/X2100
R600 Radeon HD 2900

RV610/RV630 Radeon HD 2400/2600/2700/4200/4225/4250 RV620/RV635 Radeon HD 3410/3430/3450/3470/3650/3670 RV670 Radeon HD 3690/3850/3870 RS780/RS880 Radeon HD 3100/3200/3300/4100/4200/4250/4290 RV710/RV730 Radeon HD 4330/4350/4550/4650/4670/5145/5165/530v/545v/560v/565v RV740/RV770/RV790 Radeon HD 4770/4730/4830/4850/4860/4870/4890 CEDAR Radeon HD 5430/5450/6330/6350/6370 REDWOOD Radeon HD 5550/5570/5650/5670/5730/5750/5770/6530/6550/6570 JUNIPER Radeon HD 5750/5770/5830/5850/5870/6750/6770/6830/6850/6870 CYPRESS Radeon HD 5830/5850/5870 HEMLOCK Radeon HD 5970

PALM Radeon HD 6310/6250 SUMO/SUMO2 Radeon HD 6370/6380/6410/6480/6520/6530/6550/6620 BARTS Radeon HD 6790/6850/6870/6950/6970/6990 TURKS Radeon HD 6570/6630/6650/6670/6730/6750/6770 CAICOS Radeon HD 6430/6450/6470/6490 CAYMAN Radeon HD 6950/6970/6990 ARUBA Radeon HD 7000 系列

TAHITI Radeon HD 7900 系列

Radeon R9 280/280X PITCAIRN Radeon HD 7800 系列 Radeon R7 265/370 Radeon R9 270/270X/M290X VERDE Radeon HD 7700 系列 Radeon R7 250X/350 Radeon R9 M265X/M270X/M275X OLAND Radeon HD 8000 系列 Radeon R7 240/250/350 HAINAN Radeon HD 8800 系列 BONAIRE Radeon HD 7790 系列 Radeon R7 260/260X/360 KAVERI KAVERI APU KABINI KABINI APU HAWAII Radeon R9 290/290X/390/390X MULLINS (Puma/Puma+ 核心，GCN GPU) MULLINS/BEEMA/CARRIZO-L APU

radeon/R600_rlc.bin radeon/R600_uvd.bin
radeon/R600_rlc.bin radeon/RS780_uvd.bin radeon/RS780_pfp.bin radeon/RS780_me.bin

radeon/PALM_me.bin radeon/PALM_pfp.bin
radeon/SUMO_rlc.bin radeon/SUMO_uvd.bin SUMO radeon/SUMO_me.bin radeon/SUMO_pfp.bin

radeon/BTC_rlc.bin radeon/CAICOS_mc.bin radeon/CAICOS_me.bin radeon/CAICOS_pfp.bin radeon/CAICOS_smc.bin radeon/SUMO_uvd.bin
radeon/BTC_rlc.bin radeon/TURKS_mc.bin radeon/TURKS_me.bin radeon/TURKS_pfp.bin radeon/TURKS_smc.bin radeon/SUMO_uvd.bin

radeon/BONAIRE_ce.bin radeon/BONAIRE_mc.bin radeon/BONAIRE_mc2.bin radeon/BONAIRE_me.bin radeon/BONAIRE_mec.bin radeon/BONAIRE_pfp.bin radeon/BONAIRE_rlc.bin radeon/BONAIRE_sdma.bin radeon/BONAIRE_smc.bin radeon/BONAIRE_uvd.bin radeon/BONAIRE_vce.bin

https://github.com/aros-translation-team

https://wiki.archlinux.org/title/ATI