Kiến trúc điện toán CDNA 3 của AMD
(chipsandcheese.com)- AMD CDNA 3 là kiến trúc GPU điện toán nhằm khắc phục những điểm mà CDNA 2, dù đạt kết quả trong siêu máy tính FP64, vẫn thua H100 về hiệu năng AI và quy mô GPU hợp nhất
- MI300X phơi bày tổng cộng 304 Compute Unit trên 8 XCD như một GPU đơn, giảm gánh nặng phải chia tác vụ giữa hai GPU và các vùng nhớ riêng như trên MI250X
- Hệ thống phân cấp bộ nhớ được tái cấu trúc với Infinity Cache 256MB, L2 4MB cho mỗi XCD và L1 32KB gần CU; về lý thuyết cung cấp băng thông cache 17,2TB/s, nhưng trong cấu hình bộ nhớ hợp nhất, liên kết die-to-die có thể trở thành nút thắt
- Các đơn vị thực thi đưa vào cấu trúc gần với dual issue và tăng số luồng có thể theo dõi trên mỗi SIMD để nâng mức tận dụng FP32; thông lượng xử lý phép toán ma trận trên mỗi CU cũng tăng gấp đôi so với thế hệ CDNA trước
- Thay đổi cốt lõi của CDNA 3 nằm ở hệ thống phân cấp bộ nhớ và đóng gói; MI300X được thiết kế để khiến nhiều chiplet trông như một bộ tăng tốc lớn duy nhất nhờ băng thông Infinity Fabric tăng mạnh
Khoảng cách mà CDNA 3 nhắm tới
- AMD đã phát triển kiến trúc qua Terascale 3, GCN và việc tách CDNA/RDNA để bắt kịp Nvidia trên thị trường GPU điện toán
- MI250X và MI210 dựa trên CDNA 2 đã giành được nhiều hợp đồng siêu máy tính, trong đó có Frontier của ORNL; Frontier đứng đầu TOP500 vào tháng 11/2023
- CDNA 2 mang lại hiệu năng FP64 vững chắc và hiệu quả chi phí, nhưng H100 có hiệu năng AI tốt hơn và cung cấp GPU hợp nhất lớn hơn
- CDNA 3 được thiết kế theo hướng thu hẹp khoảng cách này bằng cách kết hợp đóng gói tiên tiến của AMD, Infinity Fabric, Infinity Cache thuộc dòng RDNA và Compute Unit được cải tiến
Bố cục GPU của MI300X
- MI300X dùng cấu trúc chiplet tách phần điện toán thành Accelerator Complex Die (XCD)
- XCD đóng vai trò tương tự Graphics Compute Die (GCD) của CDNA 2/RDNA 3 và Core Complex Die (CCD) của Ryzen
- Có vẻ AMD đã đổi tên vì các sản phẩm CDNA không có phần cứng đồ họa chuyên dụng của dòng RDNA
- Mỗi XCD có 40 CDNA 3 Compute Unit về mặt vật lý, trong đó trên MI300X có 38 CU được kích hoạt trên mỗi XCD
- Một XCD có cache L2 4MB, được tất cả CU trên die đó sử dụng
- MI300X cung cấp tổng cộng 304 Compute Unit nhờ 8 XCD
- Con số này tăng đáng kể so với 220 CU của MI250X, và MI300X có thể phơi bày các CU này như một GPU đơn
- Trên MI250X, mỗi GPU có vùng nhớ riêng, nên lập trình viên phải tự chia tác vụ cho hai GPU
- Nvidia H100 phơi bày 132 Streaming Multiprocessor (SM) như một GPU hợp nhất, nhưng dùng phương thức truyền thống là triển khai điện toán trên một die đơn kích thước lớn
- H100 chia L2 thành hai instance; một SM đơn có thể dùng toàn bộ 50MB L2, nhưng truy cập vượt quá 25MB sẽ bị phạt hiệu năng
- XCD của MI300X không dùng dung lượng L2 của các XCD khác để cache, nên xét về mức tận dụng dung lượng cache, cách của Nvidia hiệu quả hơn
So sánh cấu trúc với Ponte Vecchio
- Ponte Vecchio (PVC) của Intel dùng Compute Tile làm khối điện toán cơ bản, gần tương ứng với XCD của CDNA 3
- Base Tile của PVC chứa cache cấp cuối lớn và bộ điều khiển bộ nhớ HBM, tương tự die IO của CDNA 3
- Card PVC cũng có thể được phơi bày như một GPU đơn với vùng nhớ hợp nhất, giống MI300X
- Khác biệt giữa hai cấu trúc thể hiện ở kích thước chiplet, cách bố trí cache và liên kết giữa các die
- Compute Tile của PVC gồm 8 Xe Core, nhỏ hơn XCD CDNA 3 có 38 CU
- Intel giảm nhu cầu lưu lượng cross-die bằng cache L1 lớn hơn thay vì cache dùng chung cho toàn bộ Compute Tile
- Khi dùng Ponte Vecchio 2-stack như GPU hợp nhất, cầu EMIB chỉ cung cấp 230GB/s, khiến khó tận dụng đầy đủ băng thông HBM khi striping truy cập trên tất cả bộ điều khiển bộ nhớ
- Intel cung cấp API có thể xử lý GPU như cấu hình NUMA
- Về cấu hình vật lý, CDNA 3 cần băng thông cao giữa các die IO, còn PVC dựa vào liên kết EMIB băng thông thấp hơn; tuy vậy thiết kế của PVC phức tạp do có bốn loại die cùng các tiến trình và xưởng đúc khác nhau
- MI300X chỉ dùng hai loại die, và cả 6nm lẫn 5nm đều là tiến trình của TSMC
Infinity Cache và nút thắt bộ nhớ
- Trong nhiều thập kỷ, hiệu năng điện toán tăng nhanh hơn bộ nhớ, và GPU cũng đã đáp lại bằng chiến lược cache tinh vi hơn giống CPU
- CDNA 2 dùng hệ thống phân cấp cache hai tầng truyền thống dựa vào L2 8MB và HBM2e, nhưng MI250X thiếu băng thông nhiều hơn so với Nvidia H100
- CDNA 3 bổ sung Infinity Cache lấy từ RDNA 2
- Infinity Cache của MI300 là cache phía bộ nhớ, được tài liệu kỹ thuật gọi là Memory Attached Last Level (MALL)
- Nó nằm xa Compute Unit hơn L1·L2 và gắn với bộ điều khiển bộ nhớ
- Toàn bộ lưu lượng bộ nhớ đi qua Infinity Cache, và lưu lượng IO cũng như giao tiếp peer GPU cũng có thể hưởng lợi từ băng thông Infinity Cache
- Vì luôn thấy trạng thái mới nhất của nội dung DRAM, nó không cần xử lý các thao tác duy trì cache như snoop
- Cache phía bộ nhớ thường có độ trễ cao hơn, nên AMD bảo vệ Compute Unit bằng cache L2 cỡ nhiều MB trên cả CDNA 3 lẫn RDNA 2
Dung lượng và băng thông lý thuyết của Infinity Cache
- Infinity Cache của CDNA 3 có cấu trúc 16-way set associative giống RDNA 2
- Triển khai của CDNA 3 được tối ưu cho băng thông hơn là dung lượng
- Gồm 128 slice
- Mỗi slice có dung lượng 2MB, băng thông đọc 64 byte mỗi chu kỳ
- Toàn bộ các slice cung cấp 8192 byte mỗi chu kỳ, tương đương 17,2TB/s ở 2,1GHz
- Infinity Cache 128MB của RDNA 2 cung cấp 1024 byte mỗi chu kỳ tính trên toàn bộ slice, về lý thuyết là 2,5TB/s ở 2,5GHz
- Dựa trên ảnh die, slice Infinity Cache của RDNA 2 có vẻ cung cấp dung lượng 4MB và 32 byte mỗi chu kỳ
- MI300X có thể đạt hiệu năng ổn ngay cả với workload có compute density thấp, nếu đạt đủ Infinity Cache hit
- Nếu xây dựng mô hình roofline bằng băng thông lý thuyết của Infinity Cache, MI300X có thể đạt toàn bộ thông lượng FP64 với 4,75 FLOPs trên mỗi byte được nạp
- Khi chỉ dùng DRAM, cần 14,6~15 FLOPs trên mỗi byte được nạp
Giới hạn của băng thông cross-die
- Infinity Fabric của MI300X trải trên 4 die IO, và mỗi die IO kết nối với 2 HBM stack cùng các phân vùng cache liên quan
- Khi MI300X hoạt động như một GPU logic đơn có vùng nhớ hợp nhất, băng thông kết nối die-to-die có thể giới hạn việc đạt toàn bộ băng thông lý thuyết của Infinity Cache
- Nút thắt tính theo từng phân vùng die IO đơn lẻ thể hiện trong phép tính băng thông
- Nó có băng thông ingress 2,7TB/s trên hai cạnh tiếp giáp với các die IO lân cận
- Hai XCD kết nối với die IO đó có thể nhận 4,2TB/s băng thông Infinity Cache
- Nếu các yêu cầu L2 miss được striping đều trên toàn bộ die, thì 3/4, tức 3,15TB/s, phải đến từ peer die
- 3,15TB/s lớn hơn 2,7TB/s, nên băng thông cross-die giới hạn băng thông cache
- Nếu tất cả die đều yêu cầu băng thông Infinity Cache tối đa trong cấu hình hợp nhất, truyền tải giữa các die ở góc đối diện cần 2 hop, tiêu thụ thêm băng thông ingress
- Nếu chia MI300X thành nhiều NUMA domain, tổng băng thông Infinity Cache có thể cao hơn
- L2 hit rate cao làm giảm khả năng gặp nút thắt, và khi Infinity Cache hit rate thấp, liên kết die-to-die của MI300X cung cấp đủ băng thông để xử lý lưu lượng HBM
Tính nhất quán giữa các XCD và hoạt động của L2
- Infinity Cache không cần lo về tính nhất quán, nhưng bộ nhớ đệm L2 cần được xử lý riêng
- Truy cập bộ nhớ GPU thông thường tuân theo relaxed coherency model, nhưng lập trình viên có thể dùng atomics để cưỡng chế ordering giữa các thread
- Truy cập bộ nhớ của GPU AMD có thể được đánh dấu bằng bit GLC (Global Level Coherent)
- Trên các GPU AMD trước đây, atomics và coherent access được xử lý ở L2
- Load có bit GLC được đặt sẽ bỏ qua L1 và lấy dữ liệu mới nhất từ L2
- Trên MI300X, cacheline mới nhất có thể nằm trong L2 của XCD khác, nên chỉ cách này là chưa đủ
- CDNA 3 đặt Coherent Master (CM) tại phần kết nối giữa XCD và IO die, giống Infinity Fabric của Ryzen, và đặt Coherent Slave (CS) cạnh mỗi bộ điều khiển bộ nhớ cùng với slice Infinity Cache
- Tài liệu Ryzen cho thấy Coherent Slave có probe filter và phần cứng để xử lý atomic transaction
- MI300X dường như cũng có triển khai CS tương tự
- Khi một coherent write đến CS, bất kỳ thread nào chạy ở bất cứ đâu trong GPU cũng phải có thể quan sát write đó qua coherent read
- Nếu triển khai đơn giản, CS sẽ phải probe L2 của mọi XCD
- Probe filter theo dõi XCD nào đã cache line đó để tránh probe traffic không cần thiết
- Whitepaper CDNA 3 cho biết snoop filter đủ lớn để bao phủ nhiều cache L2 của các XCD
- Tuy nhiên, CDNA 3 bên trong XCD hoạt động khá giống GPU trước đây
- Memory write thông thường không tự động invalidate line trong peer cache như CPU
- Code phải chỉ rõ việc writeback dirty L2 cache line và invalidate non-local L2 line trong peer L2 cache
- Tài liệu LLVM liên quan mô tả việc dùng
buffer_wbl2 sc1vàbuffer_inv sc0 sc1trên target GFX942
Cải tiến bộ nhớ đệm L2 và L1
- Mỗi XCD của MI300X có bộ nhớ đệm L2 4MB nằm gần Compute Unit
- L2 gồm 16 slice
- Mỗi slice 256KB cung cấp băng thông 128 byte mỗi chu kỳ
- Ở mức 2,1GHz, tương đương 4,3TB/s trên mỗi XCD
- MI300X có tỷ lệ L2 bandwidth-to-compute cao hơn H100 và MI250X
- Vì mỗi XCD đều có L2, khi sản phẩm CDNA 3 tăng số XCD thì băng thông L2 cũng tăng tự nhiên
- Tránh được bài toán phải kết nối nhiều Compute Unit vào một cache lớn duy nhất mà vẫn duy trì băng thông
- Với PVC, khi số Compute Tile tăng, L2 dùng chung trên Base Tile phải gánh nhu cầu băng thông lớn hơn
- Cấu trúc PVC đơn giản hơn về thiết kế cache vì L2 là điểm nhất quán duy nhất và đóng vai trò backstop cho L1 miss
- Nhưng không cung cấp băng thông cao như L2 của MI300X
- L1 của CDNA 3 cũng được cải tiến theo hướng ưu tiên băng thông
- Throughput L1 tăng từ 64 byte lên 128 byte mỗi chu kỳ
- Dung lượng L1 cũng tăng từ 16KB lên 32KB
- Cache lớn hơn có thể tăng hit rate, giảm độ trễ truy cập bộ nhớ trung bình và cải thiện mức sử dụng execution unit
- Vì việc lấy dữ liệu từ L2 trở lên tiêu tốn điện năng, hit rate tăng cũng có thể giúp cải thiện hiệu suất năng lượng
- Ponte Vecchio vẫn mạnh ở khía cạnh L1
- Mỗi Xe Core cung cấp 512 byte mỗi chu kỳ
- Dung lượng L1 là 512KB
- Các memory-bound kernel vừa với L1 có thể chạy tốt trên kiến trúc Intel
- Tuy nhiên, do không có mid-level cache ở cấp Compute Tile, hiệu năng có thể giảm mạnh khi dữ liệu vượt ra khỏi L1
Lập lịch và execution unit
- Ngoài cấu trúc chiplet và cache khiến MI300X trông như một GPU đơn, CDNA 3 còn cải tiến lặp lại kiến trúc Compute Unit để xử lý vấn đề tận dụng FP32 của CDNA 2
- CDNA 2 xử lý FP64 native và cung cấp FP32 tốc độ gấp đôi thông qua packed execution
- Trình biên dịch phải pack hai giá trị FP32 vào các thanh ghi liền kề và thực thi cùng một lệnh
- Nếu lập trình viên không dùng vector một cách tường minh, trong nhiều trường hợp trình biên dịch khó làm tốt việc này
- CDNA 3 đi vòng qua vấn đề này bằng cơ chế dual-issue linh hoạt hơn
- Dường như nó gần với việc mở rộng khả năng multi-issue của GCN hơn là cách VOPD/wave64 của RDNA 3
- CU scheduler chọn một trong bốn SIMD ở mỗi cycle và kiểm tra xem có thread nào sẵn sàng thực thi không
- Nếu nhiều thread đã sẵn sàng, GCN có thể gửi tối đa 5 thread đến execution unit
- Dual-issue của CDNA 3 nhiều khả năng chỉ hiệu quả khi lập trình viên bộc lộ thread-level parallelism bằng dispatch size lớn, hơn là phụ thuộc vào trình biên dịch
- Nếu SIMD đang thực thi nhiều thread hơn, khả năng tìm được hai thread có lệnh FP32 cùng lúc sẽ cao hơn
- Cần ít nhất 2 active thread trên mỗi SIMD để đạt toàn bộ throughput FP32
- Trên thực tế, do memory latency hoặc execution latency, cần occupancy cao hơn
- AMD đã tăng mạnh số thread mà SIMD của CDNA 3 có thể theo dõi, từ 8 lên 24
- Không có đề cập đến việc tăng dung lượng vector register file, trong khi dung lượng này thường giới hạn số thread mà SIMD có thể duy trì đồng thời
- Khả năng multi-issue có thể hoạt động tốt nhất trong các kernel đơn giản dùng ít register trên mỗi thread
- Dual-issue cũng có thể biến register file bandwidth thành vấn đề
- Packed FP32 của CDNA 2 tận dụng các register file port rộng truyền giá trị 64-bit, nên không cần thêm lượt read
- Các lệnh riêng biệt có thể tham chiếu các register khác nhau, đòi hỏi nhiều lượt read hơn
- AMD cho biết họ đã cải tiến source caching theo từng thế hệ để một lượt đọc vector register có thể hỗ trợ nhiều downstream vector hoặc matrix operation hơn
- Nhiều khả năng đây là cách dùng register cache lớn hơn để giảm port conflict và cấp dữ liệu cho execution unit
Phép toán ma trận và hiệu năng AI
- Sự lan rộng của machine learning khiến phép nhân ma trận ngày càng quan trọng, và Nvidia đã đầu tư mạnh vào lĩnh vực này khi bổ sung tensor core trong Volta và Turing
- AMD CDNA cũng hỗ trợ matrix multiply, nhưng các kiến trúc Nvidia cùng thời đầu tư nhiều hơn vào throughput ma trận cho các kiểu dữ liệu độ chính xác thấp như FP16
- MI300X tăng gấp đôi matrix throughput trên mỗi CU so với các thế hệ CDNA trước
- Thiết kế chiplet của MI300X cho phép số CU rất lớn, qua đó tăng tổng throughput
- Nvidia vẫn là đối thủ cạnh tranh mạnh nhờ hiệu năng ma trận cao trên mỗi SM, còn CDNA 3, đúng với xu hướng của AMD, gây áp lực lớn lên Nvidia bằng hiệu năng vector FP64 trong khi vẫn duy trì hiệu năng AI mạnh một cách độc lập
Thay đổi về bộ đệm lệnh
- Compute Unit không chỉ cần truy cập bộ nhớ dữ liệu mà còn phải lấy chính các lệnh từ bộ nhớ
- Mã GPU theo truyền thống khá đơn giản và có kích thước mã nhỏ, nên việc cung cấp lệnh tương đối dễ dàng
- CDNA 2 và GPU RDNA vẫn tiếp tục dùng instruction cache 32KB, nhưng CDNA 3 đã tăng lên 64KB
- associativity cũng tăng từ 4-way lên 8-way
- Giúp tăng tỷ lệ instruction cache hit trong các kernel lớn hơn và phức tạp hơn
- AMD dường như đã tính đến trường hợp đơn giản là chuyển mã CPU sang GPU
- Mã CPU phức tạp có thể trở thành gánh nặng trên GPU
- GPU khó che giấu độ trễ instruction cache miss bằng instruction prefetching tầm xa và branch prediction chính xác
- Instruction cache lớn hơn giúp chứa các kernel lớn, còn associativity cao hơn giúp giảm conflict miss
- Mỗi instance instruction cache của CDNA 3 được hai Compute Unit chia sẻ, giống như CDNA 2
- GPU kernel thường chạy với work size đủ lớn để lấp đầy nhiều Compute Unit, vì vậy chia sẻ instruction cache là cách sử dụng SRAM hiệu quả
- Nếu nhiều Compute Unit hơn cùng chia sẻ một cache instance, có thể khó đáp ứng yêu cầu về instruction bandwidth
Khác biệt giữa MI300X và MI300A
- Thay đổi thế hệ lớn nhất của CDNA 3 nằm ở hệ thống phân cấp bộ nhớ, và cải tiến cốt lõi thực tế cũng là việc bổ sung Infinity Cache
- Vấn đề chính của MI250X là nó giống hai GPU dùng chung cùng một package hơn là một GPU duy nhất
- Băng thông giữa hai GCD là 200GB/s cho mỗi hướng
- AMD cho rằng băng thông này không đủ để khiến MI250X trông như một GPU duy nhất, nên đã tăng mạnh băng thông die-to-die
- MI300 tăng tổng băng thông East-West lên 2.4TB/s cho mỗi hướng, tăng 12 lần so với MI250X
- Tổng băng thông North-South còn cao hơn, đạt 3.0TB/s cho mỗi hướng
- Nhờ mức tăng băng thông này, MI300 có thể trông như một bộ tăng tốc tích hợp lớn duy nhất, thay vì 2 bộ tăng tốc như MI250X
- Tổng ingress bandwidth 4.0TB/s của một IO die đơn lẻ gần như khớp với 4.2TB/s mà hai XCD có thể sử dụng, nên trên thực tế không phải là vấn đề lớn
- Tuy nhiên, một IO die đơn lẻ không thể tận dụng toàn bộ băng thông bộ nhớ 5.3TB/s
- Tình huống này tương tự việc một CCD trong Ryzen 7000 không thể tận dụng hoàn toàn băng thông DDR5 do giới hạn Infinity Fabric
- Trong MI300X, nhu cầu băng thông cao nhất khi tất cả die cùng hoạt động; trong trường hợp này, mỗi die tiêu thụ khoảng 1.3TB/s, nên việc lấy 3/4 qua cross-die link không phải là vấn đề
- MI300A là một APU “big iron” kết hợp 6 CDNA3 XCD và 24 core Zen 4, đồng thời tái sử dụng cùng base die
- CPU và GPU có thể chia sẻ cùng một không gian địa chỉ bộ nhớ
- Không còn cần sao chép dữ liệu qua bus bên ngoài để duy trì tính nhất quán giữa CPU và GPU
1 bình luận
Ý kiến trên Hacker News
Về mặt kỹ thuật, card tiêu dùng của AMD có hiệu năng tính toán rất tốt. Ví dụ UE5 render mesh tam giác bằng tính toán thay vì pipeline đồ họa https://www.youtube.com/watch?v=TMorJX3Nj6U
Hơn nữa, vì nVidia ưu tiên ray tracing và DLSS hơn hiệu năng tính toán và băng thông bộ nhớ, nên cũng có nhiều trường hợp card AMD vượt card nVidia cùng phân khúc
Vấn đề là không công ty công nghệ nào muốn thêm backend D3D hay Vulkan vào các thư viện AI như PyTorch. nVidia không làm vì họ hưởng lợi từ hiện trạng, còn Intel và AMD cũng không làm vì họ muốn thay CUDA bằng các lựa chọn độc quyền của riêng mình thay vì API GPU mở
Tuy vậy, đây không phải phân khúc sản phẩm vụng về, cũng không phải vấn đề kiến trúc cấp cao. Sản phẩm chuyên dụng luôn làm tốt lĩnh vực của nó hơn sản phẩm đa dụng. Nhu cầu cho một card vừa mạnh về tính toán vừa mạnh về game là nhỏ, và dù có những người như vậy thì họ vẫn ít hơn nhiều so với những người chỉ quan tâm một phía
Hiệu quả của việc tách GCN thành RDNA và CDNA là thấy ngay. Nếu so Radeon VII (GCN 5) với RX 5700 XT (RDNA 1), thì trong game hai bên bám đuổi nhau và trung bình Radeon VII nhỉnh hơn chút, nhưng RX 5700 XT thua xa ở benchmark tính toán. Cả hai đều dùng TSMC 7nm, nhưng RX 5700 XT có ít shader hơn (2560 so với 3840), die nhỏ hơn (251 so với 311 mm2), và điện năng thấp hơn (225 so với 300 W), cho thấy hiệu quả chơi game tốt hơn hẳn. Nhờ điện năng thấp hơn, ít ồn hơn, và giá rẻ hơn vài trăm USD, nó là chiếc card hấp dẫn hơn nhiều với game thủ
Card CDNA dường như thiếu các thành phần cần cho game như render output unit. Vì vậy chúng không có hỗ trợ chính thức cho DirectX, OpenGL, Vulkan. Tôi chưa từng thấy trường hợp nào chạy game bằng chúng. Ngược lại, hiệu năng tính toán quá mạnh nên bất chấp hệ sinh thái CUDA áp đảo, vẫn có nhiều công ty mua card này thay vì nVidia. Năm 2013 có một siêu máy tính dựa trên GCN lọt top 100, và đó là hệ thống dựa trên GCN duy nhất trong top 100. Giờ đây, 8 trong số 10 siêu máy tính hiệu quả năng lượng nhất dùng bộ tăng tốc CDNA, và siêu máy tính nhanh nhất thế giới đứng số 1 tổng thể cũng dùng CDNA
https://www.tomshardware.com/news/amd-enables-rocm-and-pytor...
Về căn bản đây là một công ty phần cứng (lý lịch của Lisa Su cũng vậy), và họ đã không sớm chấp nhận rằng CUDA là đòn quyết định. Tôi nhớ trên Phoronix, @Bridgman cứ tiếp tục một cuộc chiến cầm cự để giữ chân lập trình viên. Đó là cuộc chiến không thể thắng
Ở mức nào đó cũng dễ hiểu. Thế hệ phần cứng những năm 80/90 bản năng cho rằng phần cứng là thứ đứng cao nhất trong stack, và ban lãnh đạo AMD, kể cả Su, đều xuất thân từ phía đó
Kodura hiểu rằng nVidia áp đảo AMD vì CUDA chạy được cả trên card tiêu dùng. Vì vậy ông đã đẩy Radeon VII để đối đầu Lisa Su, và chiếc card đó cho tới tận rất gần đây vẫn là card tiêu dùng duy nhất được ROCm hỗ trợ trong nhiều năm. Không lâu sau ông gần như bị sa thải trên thực tế, còn RVII, một chiếc card rất tốt, cũng nhanh chóng bị khai tử. Sau đó Wang lên thay và củng cố sự tách biệt giữa dòng tiêu dùng và dòng chuyên nghiệp
Giờ AMD đang tuyệt vọng tìm cách đảo ngược tình thế, nhưng đã quá muộn. Có vài nơi họ muốn cạnh tranh, nhưng thực tế chỉ AAPL và Metal là đáng nhắc đến
AMD đã bỏ lỡ cơ hội
Dù vậy, điều này có lẽ cũng không tốt cho việc card AMD được chấp nhận cho tác vụ tính toán. Điểm hay của CUDA là không cần card tăng tốc chuyên dụng để phát triển mã CUDA
Nếu họ phải tự bỏ tiền túi hoặc dùng ngân sách nghiên cứu để mua GPU với cùng mức giá như người tiêu dùng bình thường, có lẽ tình hình đã khác
Cá nhân tôi cho rằng cách NVidia len vào môi trường học thuật và nghiên cứu đại học là rất phi đạo đức
Sau đó họ vẫn tiếp tục chờ đợi, nhiều lần đặt cược cả công ty vào việc thị trường cho những sản phẩm họ tạo ra “sẽ đến”
Trong vài năm gần đây điều đó thực sự đã xảy ra, và đã phản ánh vào giá cổ phiếu. Các bên khác về cơ bản đang chậm hơn 10 năm, và nhìn vào cơn sốt hiện tại cùng sự phổ biến của quy trình làm việc AI/ML, gần như không thể tưởng tượng được ai đó sẽ bắt kịp
Trong khi đó mã CUDA vẫn tiếp tục chạy được khi các thế hệ card Nvidia mới ra mắt
Hầu hết mọi người đang mua các mẫu từ A6000 trở lên với mức giá người dùng phổ thông từ những công ty như Exxact hoặc Supermicro
Từ thời V100, tức là sau hệ thống DGX-1, có lẽ tôi chưa từng thấy nhà nghiên cứu nào nhận được GPU miễn phí nữa
Khác với CPU, GPU không cố trực tiếp bù đắp điều đó. Thay vào đó, nó chấp nhận độ trễ cao hơn nhưng song song hóa rộng hơn nhiều, hoặc mạnh tay hơn, so với CPU, và vô số pseudo-thread song song tạo ra hiệu ứng che giấu độ trễ
Có thể thấy hiệu ứng này, chẳng hạn trong các bài trình bày về tối ưu hóa mã GPU
https://www.olcf.ornl.gov/wp-content/uploads/2019/12/03-CUDA...
Ví dụ là phần hoạt họa bắt đầu từ slide 11
Nói cách khác, rất nhiều công việc có thể được xử lý hoàn toàn trong thanh ghi và LDS, còn truy cập bộ nhớ toàn cục thì hiếm hơn nhiều so với CPU, nơi gần như mọi thứ nằm trong bộ nhớ toàn cục và số thanh ghi kiến trúc chỉ quanh mức 16
Dù vậy, bộ nhớ toàn cục vẫn là vấn đề. Không chỉ độ trễ mà băng thông cũng là vấn đề. Vì thế RDNA2 và Ada đã bổ sung lượng lớn cache cấp cuối. Một phần là để che giấu độ trễ tốt hơn, nhưng mục đích chính là đóng vai trò bộ khuếch đại băng thông
Very long instruction word(VLIW) là kiến trúc tập lệnh được thiết kế để khai thác tính song song ở mức lệnh (ILP). CPU thông thường chủ yếu chỉ để chương trình chỉ định các lệnh sẽ được thực thi theo thứ tự, còn bộ xử lý VLIW cho phép chương trình chỉ rõ một cách tường minh những lệnh nào có thể chạy song song. Thiết kế này nhằm đạt hiệu năng cao hơn mà tránh được độ phức tạp vốn có ở các cách tiếp cận khác
Những phương pháp truyền thống để tăng hiệu năng bộ xử lý gồm có pipelining, tức chia lệnh thành các giai đoạn con để một phần có thể chạy đồng thời; kiến trúc superscalar, tức gửi từng lệnh riêng lẻ tới các phần khác nhau của bộ xử lý để thực thi độc lập; và thậm chí cả thực thi ngoài thứ tự, tức chạy lệnh theo trình tự khác với chương trình. Các cách này làm phần cứng phức tạp hơn vì bộ xử lý phải tự đưa ra toàn bộ quyết định bên trong
https://en.wikipedia.org/wiki/Very_long_instruction_word
Nó đã không thành công lắm. Nên người ta mới gọi nó là Itanic
Tiền đề là compiler có thể xác định đủ tốt các phụ thuộc theo cách tĩnh để đưa nhiều luồng thực thi tuần tự và một số luồng nhánh vào cùng một lệnh. Nhưng thực tế cho thấy compiler không làm được như vậy, nên bộ xử lý lại phải tự động tìm ra các phụ thuộc và những lệnh có thể song song hóa từ luồng lệnh tuần tự
Điều này đòi hỏi rất nhiều công việc, rất nhiều tài nguyên chip và rất nhiều năng lượng. Và nó chỉ hoạt động tốt đến một mức nào đó, sau đó đụng phải quy luật lợi ích giảm dần. Có vẻ như hiện nay chúng ta đang đúng ở điểm đó
Đó không phải là ngôn ngữ dùng để gửi lệnh, mà là bản thân cách thức xử lý
Và cũng nên nhớ rằng các thuật ngữ như VLIW4 hay VLIW5 là chỉ những cách triển khai cụ thể
https://en.wikipedia.org/wiki/Single_instruction,_multiple_d...
0: https://en.m.wikipedia.org/wiki/Amazon_Elastic_Compute_Cloud
1: https://trends.google.com/trends/explore?date=all&q=Compute&...