Quản Lý Tài Nguyên Đa Tiến Trình Và Cơ Chế Tải Đa Dạng

Trong năm ngoái, tựa game Huyễn Thế Tây Du đã ra mắt phiên bản mới với công nghệ render nhân vật 3D. Tôi từng trực tiếp tham gia vào các buổi thảo luận kỹ thuật quan trọng. Về cơ bản, với sản phẩm nòng cốt của công ty, yếu tố được đặt lên hàng đầu luôn là tính ổn định hệ thống. Do đó, các thay đổi lớn ảnh hưởng sâu rộng đến kiến trúc chương trình đều bị hạn chế tối đa. Giải pháp cuối cùng được chọn là sử dụng engine 3D để render hình ảnh, sau đó tích hợp kết quả vào khung chương trình 2D truyền thống.

Việc áp dụng công nghệ 3D chủ yếu nhằm giải quyết bài toán “bùng nổ tổ hợp tài nguyên” khi người chơi thay đổi trang bị nhân vật. Bên cạnh đó còn mở ra khả năng trình diễn hiệu ứng hoa mỹ hơn trước. Tuy nhiên gần đây, trưởng dự án game nhận thấy hiệu năng phiên bản mới vẫn chưa đạt yêu cầu. Trong khi phiên bản cũ có thể chạy mượt mà 5 client song song thì phiên bản mới chỉ duy trì được 2 client. Tính năng cho phép mở nhiều client đồng thời là yếu tố sống còn đối với Huyễn Thế Tây Du.

Hiện tôi đang tập trung xử lý bài toán tối ưu hóa này. Giải pháp hiện tại là tách riêng tiến trình render hình ảnh, sau đó sử dụng cơ chế bộ nhớ chia sẻ để phân phối kết quả đến các client game. Cách tiếp cận này đã cải thiện đáng kể hiệu năng khi vận hành nhiều client. Tôi cho rằng đây cũng chính là lợi thế lớn khi tiếp tục tận dụng engine 2D làm lõi hệ thống (lý do quan trọng hơn là không thể xây dựng lại client từ đầu, bởi bất kỳ sai sót nghiêm trọng nào trong phiên bản remake đều gây thiệt hại to lớn cho công ty).

Sau khi phân tích giải pháp hiện tại và suy nghĩ kỹ lưỡng vài ngày, tôi đã tái thiết kế một số chi tiết kỹ thuật nhằm khai thác thêm tiềm năng hiệu năng. Quá trình render 3D không phải là nút thắt cổ chai chính yếu, vấn đề nằm ở khâu sao chép dữ liệu từ bộ nhớ đồ họa ra ngoài. Xu hướng cá nhân tôi nghiêng về việc sử dụng engine render phần mềm, cụ thể là Pixomatic - một lựa chọn tối ưu. Dù là mô-đun độc lập nên không bị áp lực thời gian phát triển, hiện tại hệ thống đã vận hành tốt nên chưa cần thay đổi.

Một điểm cần tối ưu là khâu nén dữ liệu bitmap 32bit thành định dạng RLE 8bit tương thích với engine 2D cũ. Hiện tại, thời gian xử lý của phần này chỉ bằng ¼ quá trình render. Dù còn không gian cải tiến (đặc biệt là thuật toán tính toán bảng màu), nhưng hiệu năng hiện tại vẫn chấp nhận được. Một thay đổi đáng lưu ý là cách lưu trữ dữ liệu RLE theo cơ chế phân đoạn: thay vì lưu địa chỉ con trỏ từng hàng, sẽ chuyển sang đánh dấu độ lệch tương đối từ đầu khối dữ liệu. Giải pháp này giúp dữ liệu trở nên độc lập với địa chỉ bộ nhớ, thuận tiện cho việc chia sẻ giữa các tiến trình, đồng thời không cần thay đổi định dạng lưu trữ trên đĩa.

Điểm then chốt để tối ưu nằm ở việc tập trung toàn bộ quá trình tải tài nguyên vào một tiến trình duy nhất, chứ không chỉ riêng render 3D. Cách tiếp cận này giảm đáng kể áp lực I/O khi nhiều client game hoạt động đồng thời. Dù các hệ điều hành hiện đại đã tận dụng bộ nhớ trống làm bộ đệm đĩa, nhưng việc sao chép dữ liệu trong RAM vẫn tiêu hao CPU. Giảm thiểu dữ liệu tải trùng lặp sẽ giúp giảm gánh nặng xử lý, đồng thời tiết kiệm tổng lượng bộ nhớ tiêu thụ.

Giải pháp cuối cùng sử dụng định danh 128bit duy nhất để xác định mỗi yêu cầu tài nguyên. Định danh này được tính toán từ toàn bộ tham số yêu cầu. Khi cần tài nguyên, client game sẽ gửi ID yêu cầu đến tiến trình quản lý tài nguyên nhưng không chờ phản hồi. Tiến trình này sẽ xử lý theo độ ưu tiên, lần lượt phân phát địa chỉ dữ liệu cho các client. Để tăng tốc phản hồi, hệ thống sẽ ưu tiên trả về hình ảnh mặc định trước, sau đó cập nhật dữ liệu hoàn chỉnh khi có sẵn. Mỗi client duy trì một bảng cache địa chỉ, cập nhật khi nhận được thông báo mới.

Việc chia sẻ tài nguyên sử dụng cơ chế phân trang bộ nhớ chia sẻ 8MB/trang. Tổng không gian chia sẻ lên đến 512MB, đủ đáp ứng nhu cầu game. Mỗi tiến trình có thể ánh xạ vào địa chỉ ảo khác nhau, nhưng nhờ tính độc lập địa chỉ của dữ liệu hình ảnh nên không gây vấn đề. Giải pháp này không chỉ giới hạn ở việc tải từ đĩa cứng hay render GPU, mà còn có thể mở rộng cho việc tải tài nguyên từ mạng, chỉ cần thiết kế cơ chế đẩy chia sẻ phù hợp. Thách thức chính vẫn là vấn đề tốc độ phản hồi.