Quản Trị Viên Klive

Vì sao game esports thường nhạy với hiệu năng từng nhân CPU?

Nhiều game esports nhạy với hiệu năng từng nhân vì một phần công việc nằm trên đường xử lý có phụ thuộc: bước sau cần kết quả của bước trước. Khi muốn đạt FPS rất cao, chỉ một tác vụ quan trọng chậm cũng có thể giữ cả khung hình. Tuy vậy, game hiện đại vẫn dùng nhiều luồng; “nhạy đơn nhân” không có nghĩa toàn bộ game chỉ chạy trên một nhân.

Bài viết giải thích cơ chế và cách nhận diện giới hạn CPU. Các ví dụ thời gian là phép tính minh họa, không phải kết quả benchmark CS2, VALORANT hoặc một bộ máy cụ thể.

Luồng chính quan trọng nhưng không làm mọi việc

Một engine có thể phân công logic game, vật lý, âm thanh, hoạt ảnh, chuẩn bị lệnh vẽ và nạp tài nguyên cho các luồng hoặc hệ thống tác vụ khác nhau. Một số phần chạy song song, một số phải đồng bộ. Cách chia cụ thể tùy engine, phiên bản và cách nhà phát triển xây dựng game.

Ví dụ, Microsoft mô tả việc ghi nhiều command list đồng thời trong Direct3D 12.[1] Epic cũng có tài liệu riêng về dựng hình song song trong Unreal Engine.[2] Các tài liệu này cho thấy không thể lấy thứ tự cập nhật của một engine để kết luận mọi game đều xử lý input, va chạm và dựng hình hoàn toàn trên một luồng.

Nhóm công việcKhả năng chia việcĐiểm cần lưu ý

Cập nhật trạng thái gameMột phần có thể chia thành tác vụKết quả liên quan nhau cần đồng bộ

Chuẩn bị lệnh dựng hìnhCó thể ghi lệnh trên nhiều luồngCòn phụ thuộc API và thiết kế engine

Vật lý, hoạt ảnh, âm thanhCó thể dùng luồng hoặc hệ thống tác vụ riêngKhông phải mọi phép tính đều độc lập

Nạp tài nguyênCó thể chạy bất đồng bộVẫn có thể gây chờ nếu dữ liệu chưa sẵn sàng

Phần quyết định tốc độ khung hình là đường xử lý đang giới hạn tiến độ, không nhất thiết là luồng có tên “main”. Nó có thể nằm ở game thread, render thread, GPU hoặc một điểm chờ khác. Thêm nhân hữu ích khi phần việc giới hạn chia được hoặc khi tác vụ nền đang tranh tài nguyên.

FPS mục tiêu càng cao, ngân sách mỗi khung càng nhỏ

Mục tiêuThời gian trung bình tương ứng

60 FPS16,67 ms144 FPS6,94 ms240 FPS4,17 ms360 FPS2,78 ms

Các mốc được tính bằng 1000/FPS. Chúng là mục tiêu khoảng cách khung hình, không phải thời gian dành riêng cho CPU, cũng không phải tổng độ trễ đầu vào. CPU và GPU có thể xử lý các phần việc chồng lấp giữa nhiều khung.

Giả sử đường xử lý phía CPU mất khoảng 6 ms mỗi khung, còn GPU cần 3 ms, CPU có thể giới hạn tốc độ dù GPU còn dư. Đây là mô hình đơn giản để giải thích nút thắt, không phải công thức dự đoán chính xác FPS trong mọi pipeline. Muốn kết luận cần quan sát số đo thực tế.

Vì sao hạ độ phân giải đôi khi không tăng FPS?

Hạ độ phân giải thường giảm phần việc đồ họa liên quan đến số điểm ảnh. Nó không tự giảm số người chơi, số đối tượng cần cập nhật hoặc toàn bộ công việc chuẩn bị khung hình. Nếu FPS tăng rất ít trong một phép thử có kiểm soát, máy có thể đang bị giới hạn ở phía CPU hoặc ở một yếu tố khác.[3]

Đây là dấu hiệu để điều tra, không phải bằng chứng duy nhất. Giới hạn FPS, VSync, giới hạn của engine, điện năng và nhiệt độ cũng có thể làm FPS đứng yên. Ngược lại, tăng độ phân giải không bảo đảm máy sẽ chuyển sang nghẽn GPU.

Không nên chỉ nhìn tổng CPU ở 30% rồi kết luận CPU còn dư. Một tác vụ giới hạn có thể chỉ chiếm một phần tài nguyên toàn chip. Hệ điều hành còn có thể chuyển luồng giữa các nhân, nên cũng không bắt buộc phải thấy một nhân đứng liên tục ở 100%.

Tickrate máy chủ khác FPS trên máy chơi

Tickrate là nhịp cập nhật mô phỏng; FPS là tốc độ tạo hoặc trình bày khung hình, tùy cách đo. Hai chỉ số có liên quan đến trải nghiệm nhưng không đồng nhất.

Trong bài kỹ thuật về netcode VALORANT, Riot mô tả bước mô phỏng cố định 128 lần/giây, tách với tốc độ dựng hình.[4] Khoảng cách mô phỏng tương ứng là 7,8125 ms. Đây là mô tả của hệ thống trong tài liệu đó, không phải quy tắc cho mọi game esports.

Màn hình và máy chơi vẫn có thể tạo nhiều khung hơn nhịp mô phỏng nhờ các cách cập nhật và nội suy. Không thể lấy 128 tick để suy ra game chỉ cần 128 FPS. Tính nhất quán của mô phỏng cũng không bắt buộc toàn bộ tính toán phải nằm trên một luồng; đó là vấn đề thiết kế và đồng bộ.

Hiệu năng từng nhân không chỉ là GHz

Xung nhịp chỉ cho biết số chu kỳ, không cho biết mỗi chu kỳ hoàn thành bao nhiêu công việc có ích. Kiến trúc, bộ nhớ đệm, độ trễ bộ nhớ, dự đoán nhánh, mức điện và xung duy trì đều có thể ảnh hưởng một tải game cụ thể.

Vì vậy, không nên mặc định CPU 5,3 GHz luôn nhanh hơn CPU 5,0 GHz, hay điểm đơn nhân của một bài tổng hợp sẽ xếp hạng đúng mọi game. Hãy xem phép đo của đúng game, cùng phiên bản và cấu hình được công bố rõ. FPS trung bình, nhóm khung chậm và frame time bổ sung thông tin cho nhau.

Quy trình kiểm tra CPU có đang là giới hạn

Chọn một đoạn chơi lặp lại được; ghi CPU, GPU, RAM, phiên bản game, driver, giới hạn FPS và chế độ đồng bộ.

Đo cùng đoạn ở độ phân giải đang dùng, rồi giảm riêng độ phân giải. Giữ những tùy chọn khác không đổi.

Theo dõi FPS, biểu đồ frame time, mức sử dụng GPU, xung và nhiệt độ. Kiểm tra cả giới hạn điện và tác vụ nền.

Nếu game có chỉ số CPU/GPU frame time hoặc profiler được hỗ trợ, dùng chúng để xác định phía đang chờ. Tránh công cụ can thiệp không được hệ thống chống gian lận cho phép.

Lặp lại ít nhất ba lượt. Nếu kết quả dao động mạnh, xử lý điều kiện đo trước khi quyết định nâng cấp.

CPU mạnh hơn có thể cải thiện tình huống nghẽn CPU, nhưng không bảo đảm xóa được giật do shader, nạp tài nguyên, mạng hoặc lỗi game. Cũng không thể dùng video livestream để xác định CPU nào làm người chơi tụt FPS: video đã qua máy quan sát, mã hóa, truyền và giải mã.

Đọc thêm: số nhân CPU và nhu cầu chơi game. Khi mua, hãy cân cả hiệu năng trong game lẫn số tác vụ bạn thực sự chạy cùng lúc.