Giới hạn FPS có thể thay đổi thời điểm và nhịp Game Thread phải chuẩn bị frame, nhưng mức thay đổi không giống nhau trong mọi engine hay cảnh chơi. Khi game không cần tạo frame nhanh hơn giới hạn đã đặt, một số công việc có thể được giãn theo thời gian hoặc chờ; phần xử lý cần cho mỗi frame vẫn phụ thuộc logic game. Muốn đánh giá đúng, hãy so sánh trace nhiều frame trong cùng cảnh thay vì hứa trước mức giảm tải cố định.
Điểm chính
- Unreal Timing Insights cung cấp timeline để quan sát các sự kiện và thời gian trong Unreal; kết quả phụ thuộc trace, phiên bản engine và cách thu thập. [1]
- Microsoft mô tả SetMaximumFrameLatency như thiết lập số frame được xếp hàng trước khi ứng dụng cần chờ; đó không phải một bộ giới hạn FPS phổ quát. [2]
- Giới hạn FPS có thể đổi lịch chờ và thời điểm submit, nhưng không tự loại bỏ logic CPU cần thực hiện cho mỗi frame.
- Đo cùng cảnh, cùng cài đặt và cùng giới hạn khác nhau; ghi nhiều frame và theo dõi biến động thay vì chỉ một giá trị trung bình.
- Không diễn giải một thay đổi timing thành mức giảm điện năng hoặc tải CPU cố định nếu chưa đo trên cấu hình cụ thể.
Giới hạn tốc độ không xóa công việc của mỗi frame
Game Thread thường điều phối nhiều bước logic và chuẩn bị dữ liệu cho công đoạn dựng hình tiếp theo. Khi đặt giới hạn FPS thấp hơn mức game có thể đạt trong một cảnh, ứng dụng có thể có thêm thời gian giữa các lần bắt đầu frame hoặc chờ đến thời điểm thích hợp để tiếp tục. Tuy nhiên, các tác vụ gameplay cần thiết vẫn phải chạy; chỉ việc đặt một con số thấp hơn không tự xóa AI, mô phỏng, cập nhật thế giới hay xử lý đầu vào.
Tác động còn phụ thuộc cách engine thực thi giới hạn: ứng dụng có thể chờ ở một điểm khác nhau, đồng bộ với màn hình, hoặc chịu ảnh hưởng của giới hạn hàng đợi frame. Microsoft mô tả SetMaximumFrameLatency trong ngữ cảnh DXGI và số frame có thể được xếp hàng trước khi ứng dụng phải chờ. Đây là một cơ chế cụ thể của API, không nên đồng nhất với mọi bộ giới hạn FPS trong mọi trò chơi. [2]
Trong Unreal, Timing Insights cho phép xem dữ liệu theo timeline để hiểu các sự kiện chạy khi nào và kéo dài bao lâu. Công cụ này giúp đặt câu hỏi cụ thể về một trace, chứ không biến một biểu đồ mẫu thành quy luật cho mọi game. Khi xem dữ liệu, hãy phân biệt khoảng Game Thread thực sự xử lý với khoảng chờ hoặc trạng thái không hoạt động.
Đọc trace để biết điều gì đã đổi
Thiết kế phép đo trước khi mở profiler: chọn một cảnh có thể lặp lại, giữ nguyên tuyến đường hoặc hành động, ghi phiên bản game, cài đặt, độ phân giải, giới hạn FPS và trạng thái ứng dụng nền. Thu trace trong một khoảng đủ dài để thấy nhiều frame. Một cảnh có tải CPU dồn dập và một cảnh chờ GPU có thể phản ứng khác nhau, nên không nên chọn một khoảnh khắc rồi khái quát cho toàn trò chơi.
Trong timeline, xem thời lượng và khoảng cách giữa các lần xử lý Game Thread, sự kiện submit, thời gian GPU và dấu mốc present nếu công cụ cung cấp. Nếu có những khoảng trống mới xuất hiện sau khi bật giới hạn, hãy xác định chúng là chờ ở đâu trước khi gọi đó là “CPU giảm tải”. Một đường biểu diễn ít bận hơn có thể đến từ lịch trình khác, nhưng bản thân nó không chứng minh mức tiêu thụ điện đã giảm một tỷ lệ nhất định.
Unreal Timing Insights ghi nhận và trình bày thông tin timing trong Unreal Engine; cần sử dụng đúng phiên bản tài liệu và công cụ khớp với dự án. So sánh hai trace bằng cùng bộ lọc và cùng khoảng thời gian. Nếu thay đổi cài đặt đồ họa, driver và giới hạn cùng lúc, dữ liệu sẽ khó quy nguyên nhân. [1]
Diễn giải thận trọng theo từng cấu hình
Nếu Game Thread vốn là nút thắt và cảnh có thể tạo frame vượt giới hạn, việc giảm giới hạn có thể thay đổi cách công việc được phân bố và giảm nhu cầu chạy liên tục ở nhịp cao. Nhưng nếu game bị chặn bởi GPU, tải nền, đồng bộ hoặc công việc CPU không phụ thuộc tốc độ frame, kết quả sẽ khác. Do đó hãy báo cáo điều đo được: frame time, khoảng chờ, tải quan sát trong công cụ và điều kiện thử; tránh nói chung rằng “giới hạn FPS luôn làm CPU nhẹ đi”.
Lặp phép đo vài lần và kiểm tra biến động giữa các lần chạy. Nhiệt độ, tác vụ nền, shader compilation và tải mạng có thể làm mẫu đo khác nhau. Giữ kết quả trung bình cùng phân bố hoặc phạm vi phù hợp, đồng thời nêu rõ công cụ đo. Một kết quả đơn ở một máy chỉ mô tả đúng cấu hình và đoạn chơi được thử.
Nếu bạn muốn chuyển từ biểu đồ timing sang theo dõi nội dung thể thao trực tiếp, hãy Tìm các trận cầu đang diễn ra trên KLIVE. Liên kết này chỉ là điểm đến nội dung; không liên quan đến phép đo hiệu năng game.
Nguồn tham khảo
Câu hỏi thường gặp
Giới hạn FPS có luôn làm Game Thread nhàn hơn không?
Không phải lúc nào cũng vậy. Cách giới hạn, engine, cảnh và nút thắt hiện tại quyết định công việc được phân bố ra sao.
SetMaximumFrameLatency có phải là giới hạn FPS?
Không nên đồng nhất. Tài liệu Microsoft mô tả giới hạn số frame được xếp hàng trước khi ứng dụng phải chờ trong ngữ cảnh DXGI.
Nên đo bao nhiêu frame?
Không có con số chung cho mọi phép thử; cần ghi một chuỗi đủ dài, có thể lặp lại, và nêu rõ cảnh cùng điều kiện.
Một biểu đồ CPU thấp hơn có chứng minh giảm điện năng không?
Không. Cần phép đo điện năng riêng và điều kiện kiểm soát; biểu đồ timing chỉ trả lời các đại lượng nó ghi nhận.