FPS cho biết một hệ thống tạo khung hình nhanh đến đâu trong một khoảng thời gian, nhưng không tự cho biết thao tác của người chơi mất bao lâu để xuất hiện trên màn hình. Muốn đánh giá cảm giác phản hồi, cần xác định điểm bắt đầu, điểm kết thúc và điều kiện của phép đo input-to-display.
Điểm chínhFPS là tốc độ khung hình trung bình hoặc theo khoảng đo; nó không trực tiếp mô tả toàn bộ thời gian từ thao tác tới pixel sáng lên. · Độ trễ đầu vào có thể gồm lấy mẫu thiết bị, xử lý game, chờ khung hình, gửi lệnh đồ họa và cập nhật màn hình; phép đo phải nói rõ ranh giới. · NVIDIA Reflex SDK trình bày công cụ và cách tiếp cận để đo, phân tích độ trễ hệ thống; không nên biến một phép đo riêng thành kết luận phổ quát. [1] · DXGI cho phép ứng dụng đặt số khung hình tối đa được đưa vào hàng đợi trước khi cần chờ; hàng đợi là một phần cần phân biệt với FPS. [2]
Hai con số trả lời hai câu hỏi khác nhau
FPS (frames per second) mô tả số khung hình được tạo hoặc trình bày trong một giây theo cách đo cụ thể. Nếu một trò chơi duy trì FPS cao, đó là thông tin hữu ích về thông lượng hình ảnh; tuy nhiên, con số ấy không cho biết một lần bấm chuột cụ thể được lấy mẫu lúc nào, game xử lý nó trong khung nào hay khung đó chờ bao lâu trước khi được quét lên màn hình.
Có thể hình dung hai hệ thống có cùng FPS nhưng khác cách xếp hàng công việc. Ở một hệ thống, đầu vào mới được đưa vào khung sắp xử lý; ở hệ thống khác, một số khung đã nằm chờ trước đó. Khi đó nhịp khung hình nhìn chung có thể tương tự, nhưng thời điểm phản ánh một thao tác mới không nhất thiết trùng nhau. Không nên suy từ ví dụ này ra mức chênh lệch cụ thể nếu chưa đo.
FPS trung bình cũng che khuất dao động theo thời gian. Một giá trị tổng hợp không cho biết phân bố khung chậm, nhịp trình bày hay các khoảng chờ giữa thao tác và hiển thị. Vì thế câu hỏi “game chạy bao nhiêu FPS?” không thay thế được câu hỏi “độ trễ được đo từ đâu đến đâu?”.
Theo dõi đường đi từ thao tác đến hình ảnh
Input-to-display thường được dùng để nói về khoảng từ một sự kiện đầu vào đến khi thay đổi hình ảnh được quan sát trên màn hình. Nhưng cách gọi này không tự định nghĩa chính xác thiết bị đo, điểm kích hoạt, vùng màn hình, trạng thái game hay điều kiện đồng bộ. Một phép đo có thể bắt đầu tại nút bấm vật lý; phép khác có thể bắt đầu từ tín hiệu đã được máy tính nhận. Kết quả chỉ có ý nghĩa khi mô tả rõ ranh giới ấy.
Giữa hai đầu mút có nhiều công đoạn: thiết bị gửi dữ liệu, hệ điều hành và ứng dụng tiếp nhận, game xử lý logic, CPU chuẩn bị lệnh, GPU kết xuất, khung hình được xếp hàng và màn hình làm mới. Đây là mô hình giải thích để xác định chỗ cần quan sát, không phải khẳng định mọi trò chơi hay cấu hình đều đi qua một chuỗi có cùng thời lượng. Một thành phần có thể chờ thành phần khác, nên cộng các thông số nhà sản xuất quảng bá không tự tạo ra phép đo đầu-cuối.
NVIDIA Reflex SDK tập trung vào đo lường và phân tích độ trễ trong hệ thống chơi game, giúp người kiểm thử đặt câu hỏi về các giai đoạn thay vì chỉ nhìn FPS. [1] Khi đọc tài liệu hoặc công cụ, hãy kiểm tra định nghĩa từng mốc, thiết bị hỗ trợ và phạm vi mà công cụ thực sự quan sát được. Không gọi mọi con số hiển thị là “độ trễ chuột” nếu nó không bao gồm toàn bộ chuỗi từ công tắc đến màn hình.
Hàng đợi khung hình ảnh hưởng cách diễn giải
Ứng dụng có thể chuẩn bị khung hình trước khi GPU hoặc màn hình cần đến chúng. Một hàng đợi giúp các bộ phận làm việc liên tục, nhưng khung mới có thể phải đứng sau công việc đã được gửi. Microsoft mô tả IDXGIDevice1::SetMaximumFrameLatency như cách đặt số khung hình tối đa được phép xếp hàng trước khi ứng dụng phải chờ. [2] Đây là cơ chế điều khiển hành vi xếp hàng trong ngữ cảnh API, không phải lời bảo đảm rằng một giá trị đơn lẻ sẽ cho độ trễ cố định trên mọi máy.
Khi đánh giá, cần ghi lại chế độ đồng bộ, giới hạn hàng đợi, giới hạn FPS, thiết lập game và trạng thái tải. Nếu thay nhiều biến cùng lúc, khó biết thay đổi nào đi kèm kết quả. Cũng cần phân biệt tốc độ tạo khung với tốc độ màn hình quét: màn hình có tần số làm mới riêng, còn khung hình mới có thể đến không đều. Không lấy một thông số làm đại diện cho tất cả các thời điểm này.
Một quy trình thực tế là giữ nguyên cảnh thử và thao tác, lặp lại phép đo, ghi lại các cài đặt liên quan rồi so sánh cùng loại chỉ số. Nếu dùng công cụ đo chuyên dụng, đọc hướng dẫn để biết nó đánh dấu sự kiện nào và có cần thiết bị phần cứng hỗ trợ hay không. Khi chỉ có bộ đếm FPS, hãy báo cáo đúng FPS và giới hạn của kết luận, không tự đổi nó thành mili giây độ trễ.
Cách báo cáo kết quả có thể kiểm tra
Một báo cáo hữu ích nêu tên trò chơi, phiên bản, độ phân giải, thiết lập đồng bộ, giới hạn khung hình, phần cứng liên quan và cách ghi nhận đầu vào. Nêu cả điều kiện môi trường giúp người khác hiểu phép thử, nhưng không cần khẳng định rằng một cấu hình đại diện cho tất cả người chơi. Nếu số liệu đến từ một công cụ, ghi tên công cụ và định nghĩa chỉ số theo tài liệu của công cụ đó.
Khi so sánh hai lần chạy, thay một nhóm thiết lập có chủ đích và tránh diễn giải quan hệ thành nguyên nhân nếu không kiểm soát được yếu tố khác. FPS cao hơn có thể đi cùng trải nghiệm khác, nhưng riêng sự đồng thời đó không chứng minh input-to-display đã giảm. Ngược lại, một phép đo độ trễ không cho biết toàn bộ chất lượng hình ảnh hoặc độ ổn định khung hình. Nên trình bày từng câu hỏi riêng và kết luận vừa phạm vi dữ liệu.
Người xem có thể theo dõi nội dung thể thao và các trận đấu qua [Cùng KLIVE theo dõi các trận đấu game đối kháng]; liên kết này chỉ dẫn tới trang chủ KLIVE, không phải công cụ đo hiệu năng hay nguồn xác nhận kết quả thử nghiệm.
Nguồn tham khảo
Câu hỏi thường gặp
FPS cao có đồng nghĩa độ trễ đầu vào thấp không?
Không nhất thiết. FPS mô tả tốc độ khung hình, còn độ trễ đầu vào cần phép đo có điểm bắt đầu và điểm kết thúc rõ ràng.
Input-to-display bắt đầu và kết thúc ở đâu?
Tùy phương pháp. Báo cáo cần nói rõ sự kiện đầu vào được ghi nhận ở đâu và thời điểm hình ảnh được phát hiện như thế nào.
Hàng đợi khung hình có liên quan gì?
Khung hình được chuẩn bị trước có thể chờ đến lượt; API cung cấp cơ chế giới hạn số khung chờ, nhưng kết quả vẫn phụ thuộc toàn hệ thống.
Chỉ có bộ đếm FPS thì tôi nên kết luận gì?
Chỉ báo cáo FPS theo cách đo đã dùng. Không quy đổi nó thành độ trễ đầu-cuối nếu chưa có phép đo phù hợp.