Tác giả: Jonathan Swinney

Ngày xuất bản: ngày 03 tháng 04 năm 2025

Danh mục: Best Practices, Graviton, Open Source

Năm 2022, chúng tôi published a post de mô tả những lợi ích của việc chạy các tác vụ mã hóa video trên bộ xử lý AWS Graviton. Kể từ đó, AWS đã ra mắt các phiên bản C8g được trang bị Graviton4, mang lại hiệu suất cao hơn tới 30% so với Graviton3. Trong các tác vụ mã hóa video, Graviton4 có hiệu suất cao hơn 12-15% so với Graviton3, tùy thuộc vào trình mã hóa, như được thể hiện trong biểu đồ sau. Trong cùng thời gian đó, AWS và các đối tác khác đã đóng góp vào các dự án mã nguồn mở như x265 và SVT-AV1, giúp cải thiện hiệu suất của chúng. Hiệu suất của thư viện x265 đã được cải thiện từ 16-34% kể từ phiên bản 3.6. SVT-AV1 cũng đã được cải thiện; vào năm 2022, nó thiếu các tối ưu hóa quan trọng và chạy chậm hơn nhiều lần trên Graviton so với các loại instance Amazon Elastic Compute Cloud (Amazon EC2) khác.

Hình 1: Tỷ lệ cải thiện số khung hình mỗi giây (FPS) của bốn tác vụ mã hóa khác nhau khi so sánh giữa C8g (Graviton4) và C7g (Graviton3).

Các bộ mã hóa video phần mềm linh hoạt hơn so với các bộ mã hóa được tăng tốc bằng phần cứng, do đó chúng có thể là lựa chọn tối ưu cho nhiều trường hợp sử dụng, đặc biệt là mã hóa ngoại tuyến hoặc khi sử dụng các bộ lọc tùy chỉnh. Các bộ mã hóa được tăng tốc bằng phần cứng có thể là lựa chọn phù hợp cho các tác vụ yêu cầu độ trễ cực thấp, như chuyển mã video trực tiếp. Tuy nhiên, nếu giải pháp mã hóa phần mềm phù hợp với tác vụ của bạn, các phiên bản Graviton có thể cung cấp tỉ lệ hiệu năng/giá (price-performance) tốt nhất cho nhiều tác vụ và hiệu năng trên giá cạnh tranh cho các tác vụ khác. Đối với khách hàng sử dụng các phiên bản spot, việc bổ sung thêm lựa chọn các phiên bản Graviton sẽ giúp mở rộng dải sản phẩm instance của bạn, giúp bạn luôn có thể chạy trên các phiên bản rẻ nhất có sẵn.

Graviton vẫn là bộ xử lý hiệu quả về chi phí nhất cho nhiều tác vụ mã hóa video. Sử dụng cùng bài kiểm tra hiệu năng (benchmark) từ bài đăng trên blog năm 2022 và cập nhật lên phiên bản phần mềm mới nhất, Graviton4 đạt hiệu năng trên giá tốt nhất trong số các loại instance được thử nghiệm. Các instance được trang bị Graviton chiếm ba trong số năm vị trí hàng đầu của các instance được thử nghiệm, cho thấy ngay cả Graviton2, được công bố vào năm 2019, vẫn rất hấp dẫn cho nhiều trường hợp sử dụng.

Hình 2: So sánh hiệu suất giá cả so với C5 cho từng loại instance trên tác vụ FFmpeg, trong đó mã hóa một tệp đầu vào 4K thành năm tệp đầu ra có kích thước khác nhau sử dụng x264 và preset “veryslow.”

Cải thiện hiệu suất trên x265

Các đóng góp cho x265, một thư viện mã nguồn mở phổ biến được sử dụng để mã hóa video H.265, đã cải thiện hiệu suất trên nhiều cài đặt mã hóa khác nhau. Một số chức năng tốn nhiều thời gian nhất trong các bộ mã hóa video là chung cho nhiều thuật toán, bao gồm tổng chênh lệch tuyệt đối (SAD), phép tích chập (convolution) và biến đổi cosin rời rạc (DCT). Cải thiện hiệu suất trong các chức năng này có tác động lớn đến hiệu suất tổng thể của bộ mã hóa. Các cải tiến trong các chức năng này đã mang lại cải thiện hiệu suất trên nhiều thế hệ Graviton, nhưng một số cải tiến tốt nhất được ghi nhận trên Graviton4, vốn hỗ trợ các lệnh mới nhất như SVE2. Các biểu đồ dưới đây thể hiện tỷ lệ phần trăm cải thiện của phiên bản x265 4.1 so với nhánh phát hành 3.6. Sự cải thiện so với phiên bản 3.5, phiên bản phát hành có sẵn vào năm 2022, thậm chí còn đáng kể hơn, với các phiên bản Graviton đạt hiệu suất nhanh hơn 2,3–2,5 lần.

Mẹo tối ưu hóa hiệu suất trên Graviton

Để đạt được hiệu suất mã hóa tốt nhất trên Graviton, có một số mẹo mà bạn có thể áp dụng. Điều quan trọng nhất là đảm bảo rằng bạn xây dựng quy trình (pipeline) mã hóa của mình từ mã nguồn mới nhất có thể. Gần đây đã có nhiều cải tiến giúp nâng cao hiệu suất trên Graviton, đặc biệt đối với  x265 và SVT-AV1. Nếu bạn đang sử dụng một trong hai trình mã hóa này, hãy kiểm tra hiệu suất khi xây dựng từ commit mới nhất của nhánh chính. Hãy kiểm tra thường xuyên, vì công việc trên các dự án này vẫn đang được tiến hành tại thời điểm bài viết này được thực hiện.

Một việc khác có thể giúp cải thiện hiệu suất trên Graviton là biên dịch với trình biên dịch mới nhất có sẵn cho hệ điều hành của bạn, hoặc tốt hơn nữa là cài đặt một trình biên dịch mới hơn, chẳng hạn như Clang-17 hoặc phiên bản mới hơn. (Cách dễ nhất để làm điều này thường là cài đặt thông qua trình quản lý gói của hệ điều hành.) Điều này có thể tăng hiệu suất trong các thư viện mới hơn như x265, nơi nhiều nhân mã hóa được thực hiện bằng các hàm nội tại của trình biên dịch thay vì trực tiếp bằng ngôn ngữ lắp ráp.

Đối với một số thư viện, đặc biệt là x265, việc biên dịch bằng phiên bản mới nhất của Clang thay vì GCC có thể mang lại cải thiện đáng kể về hiệu suất; trong một thử nghiệm với C8g, việc biên dịch bằng Clang trên Ubuntu Noble 24.04, sử dụng phiên bản đóng gói của Clang-18 và so sánh với phiên bản đóng gói của GCC-13, x265 đạt hiệu suất cao hơn trung bình 11% trên các bài kiểm tra hiệu suất.

Hình 4: Cải thiện hiệu suất trên C8g của x265 khi biên dịch bằng Clang-18 so với GCC-13 trên Ubuntu Noble (24.04).

Hỗ trợ lệnh mới cho phép tối ưu hóa nhiều hơn

Trong phần này, chúng ta sẽ thảo luận chi tiết về cách các tính năng mới của Graviton3 và 4 có thể cải thiện hiệu suất. Bộ lệnh NEON, được hỗ trợ bởi tất cả các bộ xử lý Graviton, cho phép xử lý 128 bit single-instruction-multiple-data (SIMD). Sử dụng các lệnh này, Graviton có thể xử lý 16 kênh pixel mỗi lệnh khi xử lý video 8-bit. Các loại lệnh này là nền tảng để đạt được hiệu suất cao trong mã hóa video trên CPU. Graviton3 bổ sung hỗ trợ cho một bộ lệnh mới khác, Scalable Vector Extension (SVE). Graviton4 phát triển thêm trên nền tảng này, bổ sung hỗ trợ cho SVE2. Mặc dù SVE không tăng tổng thông lượng song song của Graviton, nó mang lại một cách viết mã SIMD mới và đơn giản hơn, thường sử dụng ít lệnh hơn. Nó cũng bổ sung các loại lệnh không có trong NEON, cho phép tối ưu hóa nhiều hơn cho việc mã hóa video. 

Ví dụ, trong x265, một nhóm các hàm được gọi có thể sử dụng lệnh SVE2 trên Graviton4 được gọi là có thể đếm số byte khớp với mỗi byte của vectơ thứ hai. Điều này cho phép hàm xây dựng một bảng tần số nhỏ từ các giá trị trong dữ liệu nguồn. Để làm điều này với các lệnh NEON, bạn phải che từng giá trị và đếm từng giá trị riêng biệt, với một lệnh riêng biệt.saoCuStatsE0 histseg

Một trong những nhiệm vụ mà hàm thực hiện là đếm tổng số của mỗi loại trong số 5 loại cạnh khác nhau trong khối đang được xử lý. Để làm điều này với các lệnh NEON, sau khi sử dụng một số phép toán đơn giản để tính toán loại cạnh, một mặt nạ được xây dựng với các hướng dẫn so sánh cho từng loại trong số 5 loại cạnh. Sau đó, mỗi mặt nạ trong số 5 mặt nạ đó được cộng với một lệnh thêm theo cặp mở rộng, được giới hạn ở một nửa băng thông SIMD trên cả Graviton3 và Graviton4. Điều này hoạt động và giúp góp phần tăng tốc độ gấp 2,7 lần so với triển khai C. Tuy nhiên, với sự sẵn có của SVE2 trong Graviton4, chúng ta có thể thay thế 5 so sánh và 5 lệnh thêm theo cặp bằng một lệnh duy nhất và lệnh NEON tiêu chuẩn không có giới hạn băng thông của việc mở rộng theo cặp. Điều này góp phần vào việc triển khai SVE2 của chức năng này đạt tốc độ tăng gấp 3,2 lần so với việc triển khai C. saoCuStatsE0 sadalp histseg add add

Đây chỉ là một ví dụ đơn lẻ về những lợi ích mà các lệnh mới có sẵn trên Graviton3 và Graviton4 mang lại. Còn có những trường hợp tương tự khác, và việc triển khai chúng đã giúp Graviton3 và Graviton4 đạt được lợi ích về hiệu năng so với Graviton2 vượt xa những gì có thể đạt được chỉ bằng cách tăng hiệu năng chip. Đối với các kỹ sư đang làm việc để đạt được hiệu năng tối đa trên Graviton, có thông tin về việc viết mã assembly và intrinsics tối ưu trong AWS Graviton Technical Guide. của chúng tôi

HDR và video 10-bit 

Bài viết trước đã đề cập rằng vẫn còn nhiều việc cần làm, đặc biệt là với nội dung HDR sử dụng độ sâu màu vượt quá 8 bit. Độ sâu màu 10 và 12 bit yêu cầu sức tính toán SIMD gấp đôi so với 8 bit, và trong hầu hết các trường hợp, các kernel tối ưu hóa phải được triển khai riêng biệt so với các phiên bản 8 bit. Mặc dù có độ phức tạp này, nhiều công việc đã được thực hiện để tăng tốc quá trình mã hóa 10-bit. Hầu hết công việc này tập trung vào x265 và SVT-AV1, vì các codec này được sử dụng phổ biến hơn để truyền tải nội dung HDR. Đối với x265, các biểu đồ này cho thấy sự cải thiện về điểm FPS cho ba thế hệ Graviton, với C8g, C7g và C6g lần lượt đạt mức cải thiện trung bình 12%, 8% và 10%.

Phương pháp so sánh hiệu năng

Trong mỗi bài kiểm tra hiệu năng được trình bày ở đây, đủ số lượng tác vụ mã hóa được chạy song song để tải đầy đủ phiên bản (instance) đang được kiểm tra. Điều này mô phỏng một khối lượng công việc tối ưu hóa cho chi phí mã hóa thấp nhất, và tổng thời gian để mã hóa mỗi video thì ít quan trọng hơn. Trừ trường hợp bài kiểm tra hiệu suất FFMpeg, vốn giống với bài kiểm tra được sử dụng trong bài viết blog năm 2022, mỗi bài kiểm tra trong bài viết blog này đều sử dụng tệp video nguồn thô trong định dạng container y4m và mã hóa trực tiếp bằng bộ mã hóa x264, x265 hoặc SVT-AV1. Quá trình mã hóa được thực hiện với đủ số lượng phiên bản song song để tải đầy đủ tất cả các lõi của hệ thống đang được kiểm tra.

Kết luận 

Khách hàng muốn giảm chi phí mã hóa video hoặc nâng cao hiệu suất nên xem xét các phiên bản được trang bị Graviton3 và Graviton4. Các phiên bản C8g được trang bị Graviton4 đặc biệt phù hợp cho mã hóa video, với hiệu suất cao hơn 12% so với Graviton3 và 73% so với Graviton2 trong các bài kiểm tra x265. Để đạt được hiệu suất tốt nhất từ Graviton, hãy sử dụng các nguồn mới nhất của trình mã hóa và xem xét việc biên dịch bằng Clang thay vì GCC. Các đóng góp cho các dự án nguồn mở này vẫn đang tiếp tục, vì vậy hãy thường xuyên kiểm tra các bản cập nhật cho các gói nguồn. Để biết thêm thông tin về việc chuyển sang Graviton, hãy tham khảo tại AWS Graviton Technical Guide.

Về tác giả

Jonathan Swinney

Jonathan Swinney là Kỹ sư Phát triển Phần mềm tại AWS (Annapurna Labs), làm việc về tối ưu hóa phần mềm cho bộ xử lý Graviton tại Austin, Texas. Anh đã đóng góp cho nhiều dự án mã nguồn mở nhằm cải thiện hiệu suất trên Graviton, bao gồm FFmpeg, OpenSSL, Golang và các dự án khác. Trước khi làm việc với Graviton, anh đã tham gia phát triển và duy trì instance EC2 F1.