Vortex 3.0 把算力變 3D GPU

Vortex 3.0 把一個開源 RISC-V GPGPU 堆疊，往 3D GPU 和現成 API 方向推了一大步。

我盯開源 GPU 專案很久了，老實說，大多數都卡在同一個毛病：一開始很會跑 compute，講得像什麼都能做，結果一碰到真正的開發流程就露餡。不是只有模擬器，就是只有 RTL；不是只有 OpenCL 口號，就是 driver 還在半成品。你要拿它來做點像樣的工作，最後都會變成自己補洞，補到懷疑人生。

所以我看到 Vortex 3.0 時，第一個反應不是「哇，好多功能」，而是「終於有人承認只做算力不夠了」。我如果要判斷一個開源 GPU 堆疊值不值得碰，我不只想看它能不能跑 kernel，我想看它能不能接工具、能不能走圖形路徑、能不能把工作提交和同步這些髒活處理好。這版的 Vortex，至少開始像在回答這個問題。

我先看的是它終於不再裝作 compute 就夠了

觸發我寫這篇的是 Michael Larabel 在 Phoronix 的整理：Vortex 3.0 Released As Full-Stack, Open-Source RISC-V GPU Now With 3D Pipeline。原始專案在 Georgia Tech 的 Vortex 頁面，程式碼也放在 GitHub repo。Phoronix 這篇沒有提供星數或觀看數，我就不亂補。

“With Vortex 3.0 they have introduced a fixed-function graphics stack complete with a rasterizer and texture units and more in providing a 3D pipeline for expanding their scope beyond just GPGPU compute.”

翻譯一下就是：這東西不再只是算數學了，它開始有圖形管線該有的骨架。光有 compute，很多時候只是研究展示；有了 rasterizer、texture units、3D pipeline，才比較像一個能被圖形軟體真正碰到的堆疊。

我之前看過一堆開源 GPU 專案，最常見的問題就是太早把自己定位成「通用加速器」，結果實際上只有一條窄窄的路。你要嘛能跑某種 kernel，要嘛能在簡化環境裡 demo 一下，但軟體開發者一看就知道，這條路太孤了。因為圖形世界不是只有算力，還有固定功能單元、同步、命令提交、資源管理。

Vortex 3.0 的意思很直白：它在補那些以前被當成「之後再說」的東西。這不是炫技，這是把專案從「研究 artifact」往「可被軟體團隊理解的平臺」推。

實操上我會這樣做：如果你也在做硬體或加速器，不要只問「能不能跑 benchmark」。先把下一個要吃掉的工作負載寫清楚。若目標是圖形，就把固定功能單元列進 roadmap；若目標是開發者採用，就先把 API 與 driver 路徑補齊。別把自己包裝成萬能，最後什麼都不像。

• 先定義下一個 workload，不要先定義宣傳詞。
• 把缺的固定功能方塊列出來。
• 硬體能力和軟體故事要對齊。

我反而很在意它還保留 simulator 這件事

Vortex 的官方資料一直把 simulator、RTL simulator、FPGA 這幾條路放在一起講，這點我其實滿買單。原始介紹明講它可在模擬器中跑，也能對 AMD-Xilinx 或 Altera FPGA 使用。這種寫法很務實，沒有裝成「上板才算數」。

“Vortex continues to consist of an open-source simulator or RTL simulator and can also be used with either AMD-Xilinx or Altera FPGAs too for this RISC-V GPU design.”

白話就是：你不用每次改一行都去燒板子賭運氣。先在模擬器裡把行為抓穩，再把同一套東西往 FPGA 推。這種節奏雖然不帥，但它真的比較像工程，不像表演。

我以前遇過一個很典型的坑：團隊太早把所有驗證都壓到實體板上，結果每天都在跟 synthesis、時序、bitstream、工具鏈版本吵架，真正的架構問題反而沒人有空看。最後大家嘴上說在做硬體，實際上是在跟工具商搏鬥。

Vortex 這裡比較像是把開發節奏分層：模擬器負責快、負責看得清楚；FPGA 負責整合、負責驗證接近真實環境的行為。這種分工很土，但很有用。

實操寫法很簡單：你如果在做硬體相關專案，先把「最快的驗證路徑」和「最接近目標平台的驗證路徑」拆開。前者用來日常開發，後者用來確認整合沒翻車。兩條路都要寫清楚，不然大家只會在黑箱裡猜。

• 預設開發目標放在 simulator。
• FPGA 只拿來做整合確認，不拿來天天賭。
• 把每個環境驗證了什麼講明白。

命令提交和排程才是這版最像平台的地方

如果說 3D pipeline 是門面，那 command processor、kernel scheduler、async barriers 就是骨架。Phoronix 提到 Vortex 3.0 加了新的 hardware kernel scheduler、command processor architecture、async barriers。這些字看起來很工程，但我反而覺得這才是重點。

“Vortex 3.0 also adds ... a new hardware kernel scheduler, a command processor architecture, async barriers...”

翻譯一下就是：工作怎麼進 GPU、怎麼排、怎麼同步，現在都不是臨時湊的。這種東西一旦沒設計好，硬體再快也沒用，因為工作提交會亂、pipeline 會卡、同步會變成性能稅。

我很常看到這種專案犯一個毛病： datapath 很努力，command path 很隨便。結果 driver 寫到後面，大家發現真正的產品不是硬體，而是那坨為了讓硬體能用而生出來的軟體補丁。這通常不是好消息。

Vortex 3.0 這次讓我比較有感的地方，就是它開始把工作提交和同步當成一級公民，而不是「之後 driver 再補」。這代表它不只想證明算得動，還想證明整個執行模型能站得住。

實操上我會建議：你只要是在做 accelerator，不管是 GPU、NPU 還是別的東西，都要先定義 command submission、ordering、synchronization。不要把它丟給軟體團隊自己想辦法。硬體怎麼吃工作，這本來就是架構的一部分。

Tensor 那幾個名詞不是裝飾，是真在擴 use case

這版還加了 tensor core structured sparsity、warp group-level matrix multiplication 這類東西。很多人看到會先翻白眼，覺得這又是把 AI 熱詞貼上去。但我覺得不能這樣看，因為現代 workload 本來就不是單一路線。

“Vortex 3.0 also adds tensor core structured sparsity, warp group-level matrix multiplication...”

白話講，這是在補現實世界常見的數學型工作。structured sparsity 針對有規律的零值，matrix multiplication 則是很多 AI、圖學、科學運算都繞不開的核心。它們不是炫耀用的名詞，是讓這顆 GPU 不只會跑一種東西。

我以前看過一個很慘的加速器專案，硬體做得不差，但只能吃一種很窄的 kernel。結果外部團隊試了兩週就放棄，因為你每次要碰它都得先改資料格式、改編譯流程、改 runtime。那種專案最後只會活在簡報裡。

Vortex 這次比較聰明的地方，是它沒有把 graphics、compute、tensor 當成互相排斥的東西，而是把它們當成同一個堆疊可以覆蓋的不同層次。這樣一來，專案的存在理由就更完整，不會只剩下「我也能算」這種很空的說法。

實操寫法：如果你在規劃新功能，先問它是不是能讓更多真實 workload 進來。不要只問它是不是很潮。功能要能擴張可用場景，才值得排進主線。

Vulkan 和 HIP 才是讓人真的敢碰的入口

我最在意的其實不是那些硬體名詞，而是它怎麼接到開發者熟悉的 API。Vortex 3.0 這次加了 Mesa/Lavapipe Vulkan backend，還有透過 chipStar 的 HIP support。Mesa driver 叫 vortexpipe。這幾個名字一出來，味道就對了：它不是叫你重學一套怪語言，而是想插進現成生態。

“Vortex 3.0 also adds a Mesa/Lavapipe Vulkan back-end as well as HIP support via chipStar. The new Mesa driver is called vortexpipe.”

翻譯一下就是：如果你本來就會 Vulkan 或 HIP，你不用先學一個很冷門的私有介面，才能摸到這顆 GPU。這件事超重要，因為開源硬體最大的死法之一，就是把門檻設得比硬體本身還高。

我看過太多團隊覺得「只要硬體夠酷，生態自然會來」。不會。工具鏈才是生態，driver 才是生態，translation layer 也是生態。你不把這些東西做出來，最後只會剩下一張架構圖和一群不想碰的開發者。

所以如果你自己也在做平台，我會很直接：把 API 接口當成產品的一部分，不是附屬品。你要讓人從 Vulkan、HIP、OpenCL 這些熟路進來，而不是逼他們先理解你的內部世界觀。

• 用現成 API 當採用入口。
• driver 命名和 backend 命名要乾淨、直白。
• 把工具鏈工作算進 release 範圍。

我學到的是：開源硬體要靠無聊的紀律活下來

Vortex 3.0 讓我最有感的，不是它某一個單點功能，而是它開始像一個有紀律的堆疊。Georgia Tech 這個團隊還是走開源 RISC-V GPGPU 路線，但它現在更像在做一個完整平台，而不是一個只適合發 paper 的原型。

“The open-source developers at Georgia Tech working on Vortex as an OpenCL-compatible RISC-V GPGPU implementation are out with their next major release for this open-source GPU design.”

白話就是：這版不是只有硬體亮點，而是整個 stack 在一起往前移。這很重要，因為開源硬體最怕的就是層與層之間不同步。硬體先跑、driver 還沒好，會變成空轉；driver 先做、工作負載還沒對上，會變成空談。

我不會說 Vortex 3.0 已經解決所有問題，當然沒有。可是它至少把「怎麼讓開源 GPU 被真的用到」這件事，講得比很多專案誠實。它知道自己不能只做 compute，也知道不能只靠硬體名詞撐場面。

實操上，我會把這版當成一個很好的 checklist：你要做的不是炫一個功能，而是把硬體、driver、API、驗證路徑一起對齊。這種東西看起來不性感，卻是專案能不能活下去的差別。

可抄的模板

# Open GPU / accelerator release note template（可直接改名套用）

## 這版到底多了什麼
- 新增 3D / graphics pipeline
- 新增固定功能單元：rasterizer、texture units
- 新增 command processor 與 hardware scheduler
- 新增 async barriers / synchronization support
- 新增既有 API backend：Vulkan / HIP / OpenCL 其中一個或多個
- 保留 simulator 與 FPGA 驗證路徑

## 這版解決的是什麼問題
我們不再只做 compute demo，而是把專案往可被真實開發者使用的 GPU / accelerator stack 推進。

## 你要特別說清楚的地方
- 工作怎麼提交：command submission
- 工作怎麼排序：scheduling
- 工作怎麼同步：barriers / fences
- 工具怎麼接：Vulkan / HIP / OpenCL backend
- 驗證怎麼做：simulator / RTL / FPGA

## 對外一句話版本
Project X 3.0 adds a graphics pipeline, command processing, async synchronization, and backend support so developers can target it through familiar APIs instead of a custom interface.

## README 可直接貼的短版
Project X now supports graphics workloads, structured scheduling, async synchronization, and existing API backends. Development can be done in simulation first, then validated on FPGA.

## 發版檢查清單
- [ ] 我有講清楚這版多了哪些硬體方塊
- [ ] 我有講清楚 driver / backend 接口
- [ ] 我有講清楚 simulator 和 FPGA 各自負責什麼
- [ ] 我有講清楚這版能多跑哪種 workload
- [ ] 我沒有只用形容詞包裝功能

這份模板是我根據 Vortex 3.0 的拆法整理出來的，不是原文照抄。你如果也在寫硬體、框架或加速器的 release note，可以直接拿去改。重點不是文案好不好看，是有沒有把「它現在能做什麼」講到讓別人敢接手。

來源我用的是 Michael Larabel 的 Phoronix 文章：phoronix.com/news/Vortex-3.0-RISC-V-GPGPU，再加上 Georgia Tech 的 Vortex 專案頁 和 GitHub repo。前面那些拆解是我自己的理解和整理，模板也是我衍生寫出來的。