Linux 7.3 "giải cứu" game thủ: Hiệu năng ổn định hơn khi VRAM cạn kiệt

Trong một bước tiến lớn cho nền tảng Linux, loạt bản vá cải thiện quản lý VRAM (Video RAM) cho card đồ họa đã chính thức được hợp nhất vào nhân Linux 7.3. Công trình này hứa hẹn sẽ giảm thiểu tình trạng giật lag, crash và tối ưu hiệu năng khi game sử dụng vượt quá bộ nhớ đồ họa vật lý, một vấn đề nan giải mà game thủ Linux thường gặp phải.

Điểm mấu chốt của loạt vá này không chỉ dừng lại ở việc sửa lỗi, mà còn là một cuộc đại tu toàn diện cách kernel xử lý tình huống "khát" VRAM. Từ việc giải quyết các deadlock (bế tắc) trong kernel cho đến việc áp dụng các thuật toán thông minh để ưu tiên di chuyển dữ liệu, kết quả mang lại là một trải nghiệm chơi game mượt mà và ổn định hơn nhiều, ngay cả khi game yêu cầu nhiều bộ nhớ hơn mức card đồ họa có.

Hiểu đúng về "thảm họa" khi hết VRAM

Theo lý thuyết, việc hết VRAM chỉ nên là vấn đề hiệu năng, không phải sự ổn định. Driver đồ họa đã hỗ trợ "overcommit" (cho phép yêu cầu nhiều hơn bộ nhớ vật lý) từ lâu. Tuy nhiên, thực tế lại khắc nghiệt hơn nhiều.

Khi game yêu cầu nhiều VRAM hơn mức có, một phần dữ liệu sẽ bị "trục xuất" (evicted) xuống RAM hệ thống (CPU RAM). Vấn đề nằm ở tốc độ truy cập: GPU truy cập CPU RAM qua bus PCIe, vốn chậm hơn nhiều so với VRAM. Với kết nối PCIe 4.0 x16, băng thông tối đa chỉ khoảng 32GB/s, và để đạt 30 FPS, GPU chỉ có thể "kéo" tối đa khoảng 1GB dữ liệu từ RAM bị trục xuất trong mỗi khung hình.

Không phải mọi dữ liệu đều "đau" như nhau. Nhờ có bộ nhớ đệm (cache), một số dữ liệu được truy cập thường xuyên có thể "sống sót" tốt hơn khi bị đày xuống RAM. Các phép đo trên kiến trúc RDNA3 cho thấy, với các buffer nhỏ hơn 6MB (kích thước L2 cache), độ trễ truy cập là như nhau. Tuy nhiên, khi buffer lớn hơn, độ trễ khi truy cập CPU RAM tăng vọt lên đến 2400 chu kỳ, gấp 4-7 lần so với VRAM, khiến hiệu năng sụt giảm nghiêm trọng.

Biểu đồ đo độ trễ bộ nhớ RDNA3

Biểu đồ so sánh độ trễ truy cập giữa CPU RAM và VRAM trên kiến trúc RDNA3 cho thấy sự khác biệt rõ rệt khi buffer vượt quá kích thước cache.

Cuộc chiến với "deadlock" và thuật toán trục xuất thông minh

Một trong những nguyên nhân chính gây crash khi hết VRAM là lỗi deadlock trong kernel. Khi GPU cần di chuyển một vùng nhớ từ RAM lên VRAM, kernel phải khóa (lock) các vùng nhớ liên quan. Nếu hai tiến trình (ví dụ game và gamescope) cùng lúc cố khóa các vùng nhớ của nhau, sẽ xảy ra bế tắc. Kernel có cơ chế phát hiện và giải quyết, nhưng trong hệ thống quản lý bộ nhớ TTM, việc này chưa được triển khai đầy đủ, dẫn đến việc kernel từ chối nhận lệnh và gây crash.

Tác giả đã dành một tuần để sửa các lỗi còn sót lại và vá lỗ hổng này, giúp kernel có thể tự động "hồi phục" và thử lại thay vì bỏ cuộc.

Vấn đề tiếp theo là hiệu năng. Khi hết VRAM, kernel liên tục di chuyển dữ liệu qua lại giữa VRAM và RAM một cách vô ích, gây ra hiệu ứng "ping-pong". Hình ảnh từ công cụ phân tích gpuvis cho thấy hai ứng dụng liên tục trục xuất và nạp lại cùng một vùng nhớ, khiến hiệu năng tệ hơn cả khi không di chuyển gì.

Phân tích timeline với gpuvis

Timeline từ gpuvis cho thấy phần lớn thời gian bị tiêu tốn cho việc di chuyển bộ nhớ (sdma0) thay vì xử lý đồ họa thực tế (gfx_0.0.0).

Vấn đề "khó nhằn" từ bộ nhớ hiển thị và các giải pháp heuristic

Một thách thức đặc biệt đến từ bộ nhớ dùng để xuất hình ảnh ra màn hình (scanout). Loại bộ nhớ này bắt buộc phải nằm trong VRAM và phải liên tục về mặt vật lý. Trong khi đó, bộ nhớ ứng dụng thường bị phân mảnh. Điều này có nghĩa là để có đủ chỗ trống liên tục cho một buffer scanout nhỏ (~32MB), kernel có thể phải trục xuất tới 4GB VRAM, gây ra hiệu năng sụt giảm thảm hại.

Để giải quyết, tác giả đã phát triển một bộ heuristic:

• Pha "hard throttle": Trong vài mili giây sau khi bị trục xuất, kernel sẽ không cố nạp lại bất kỳ dữ liệu nào cho ứng dụng đó.
• Pha "soft throttle": Kế tiếp, kernel có thể nạp lại dữ liệu nhưng không được phép trục xuất dữ liệu của ứng dụng khác. Pha này kéo dài vài giây để đảm bảo hệ thống ổn định.
• Sau khi ổn định, các hạn chế được gỡ bỏ.

Kết quả thử nghiệm với game Indiana Jones: The Great Circle thật ấn tượng. Khi game yêu cầu 9GB VRAM trên card 8GB (overcommit 1GB), hiệu năng vẫn đạt trung bình 19.6ms mỗi khung hình, hoàn toàn có thể chơi được. Ngay cả khi overcommit lên 2GB, hiệu năng vẫn ở mức chấp nhận được dù có nhiều sự khác biệt hơn.

So sánh hiệu năng khi overcommit VRAM

So sánh hiệu năng khi game yêu cầu vượt quá VRAM vật lý, cho thấy sự cải thiện rõ rệt sau khi áp dụng các heuristic mới.

Trao quyền kiểm soát cho ứng dụng: Tương lai của quản lý bộ nhớ

Các heuristic hiện tại vẫn có nhược điểm vì không biết ứng dụng sử dụng bộ nhớ như thế nào. Giải pháp lâu dài là cho phép ứng dụng "nói" với driver về mức độ quan trọng của từng vùng nhớ thông qua extension Vulkan: VK_EXT_pageable_device_local_memory. Extension này cho phép ứng dụng gán giá trị ưu tiên (priority) cho từng buffer.

May mắn thay, vkd3d-proton (lớp chuyển Direct3D 12 sang Vulkan) đã hỗ trợ extension này. Các game D3D12 sử dụng API SetResidencyPriority sẽ tự động được hưởng lợi. Kernel có thể sắp xếp danh sách LRU (Least Recently Used) dựa trên các giá trị ưu tiên này, đảm bảo các buffer quan trọng nhất sẽ được trục xuất cuối cùng.

Kết luận: Game thủ Linux có gì để ăn mừng?

Toàn bộ công việc này đã được phát hành trong SteamOS (cả bản Stable và Preview) một thời gian. Nếu bạn sử dụng Steam Deck hoặc máy chạy SteamOS, chỉ cần cập nhật là có thể trải nghiệm ngay.

Đối với các bản phân phối Linux khác, tác giả đã công bố một nhánh kernel trên GitHub để mọi người có thể tự mình trải nghiệm, dù nó chưa trải qua quá trình kiểm thử kỹ lưỡng như bản SteamOS. Công việc hợp nhất lên kernel chính thức vẫn đang được tiếp tục và cần thêm thời gian.

Tóm lại, "chạm trán" với việc hết VRAM không còn là "án tử" cho hiệu năng. Với sự phối hợp ngày càng tốt hơn giữa kernel, driver và ứng dụng, trải nghiệm chơi game trên Linux đang trở nên mượt mà và đáng tin cậy hơn bao giờ hết. Đây chắc chắn là một tin vui cho cộng đồng game thủ, và là một minh chứng cho sức mạnh của sự phát triển nguồn mở không ngừng nghỉ.