한국어English日本語简体中文繁體中文DeutschไทยTiếng ViệtРусскийPortuguês (Brasil)EspañolBahasa Indonesia

คู่มือเกมแลค › L1 โปรเซสเกมฝั่งไคลเอนต์

V-Sync และคิวเรนเดอร์ V-Sync, render queue

ID สาเหตุ cg-vsync · ผู้รับผิดชอบหลัก พัฒนาไคลเอนต์ (ทีมพัฒนาเกม) · ร่วมกับ ภายนอก (ภายนอก)

เปิดการ์ดในฉบับหลักที่มีภาพและการทดลอง →

ระหว่างที่ GPU เก็บเฟรมที่วาดเสร็จไว้ในคิวหลายเฟรม แล้วค่อยส่งออกตามรอบของจอ อินพุตจะช้าลง

ทำไม ไดรเวอร์กราฟิกเก็บเฟรมไว้ล่วงหน้าในคิว 1–3 เฟรม → ผลคือ อินพุตต้องใช้เวลานานขึ้นเท่านั้นกว่าจะแสดงบนจอ → บนหน้าจอ ปิงต่ำแต่การควบคุมหนืดและตอบสนองช้า

อาการ
อินพุตดีเลย์, กระตุก
ปัจจัย
ความหน่วง
ใครเจอ
เราคนเดียว
เกิดเมื่อไร
ตลอดเวลา
ผู้รับผิดชอบ
ผู้รับผิดชอบหลัก พัฒนาไคลเอนต์ (ทีมพัฒนาเกม) · ร่วมกับ ภายนอก (ภายนอก)
งานฝั่งทีมพัฒนาเกม
รองรับโหมด low latency, ลดคิวเฟรม, มีตัวเลือกจำกัดเฟรมเรตให้ต่ำกว่าอัตรารีเฟรชเล็กน้อย, บนมือถือเปิดฟีเจอร์ frame pacing
งานฝั่งภายนอก
แนะนำให้ผู้เล่นใช้จอ VRR คู่กับการจำกัดเฟรมเรตให้ต่ำกว่าอัตรารีเฟรชเล็กน้อย, แนะนำให้เปิดโหมด low latency ในไดรเวอร์กราฟิก
ตัวเลขที่ควรรู้
ที่ 60 Hz เฟรมละ 16.7 ms ถ้า CPU เร็วกว่า GPU หรือรอบของจอ จนคิวสามเฟรม (ค่าเริ่มต้นของ DirectX 11) เต็ม จะเพิ่มขึ้นมา 50 ms ใน V-Sync แบบ double buffer เฟรมที่ใช้ 17 ms ต้องรอจนถึงรอบรีเฟรชจอถัดไป (33.3 ms) และระหว่างนั้นเฟรมก่อนหน้าจะแสดงซ้ำอีกครั้ง
บนกราฟ
สูงตลอดตั้งแต่แรก · ดีเลย์จากอินพุตถึงจอ
จุดที่ต้องดู
เทียบค่า MsClickToPhotonLatency, MsAllInputToPhotonLatency (ตั้งแต่อินพุตเมาส์/คีย์บอร์ดจนส่งภาพออกจอ) และ DisplayLatency ของ PresentMon ขณะสลับเปิดปิด V-Sync, โหมด low latency และการจำกัดเฟรมเรต MsPCLatency (ตั้งแต่ PC รับอินพุตจนส่งภาพออกจอ) จะถูกบันทึกเฉพาะเมื่อเกมส่ง PC Latency event ออกมา
สัญญาณว่าใช่
ตอนเปิด V-Sync หรือไม่จำกัดเฟรมเรต ดีเลย์นี้เพิ่มขึ้นหนึ่งถึงสองเฟรม (หลายสิบ ms) และลดลงเมื่อใช้โหมด low latency หรือจำกัดเฟรมเรตให้ต่ำกว่าอัตรารีเฟรชเล็กน้อย ปิงเท่าเดิม
สัญญาณว่าไม่ใช่
ดีเลย์ภายใน PC ต่ำแต่การควบคุมยังช้า: น่าจะเป็น “ดีเลย์จากจอ, อุปกรณ์อินพุต และ frame generation” ถ้าปิงสูง ให้ดูฝั่งเครือข่าย
วิธีตรวจ
ตรวจที่สภาพแวดล้อมฝั่งผู้เล่น
รายละเอียดเพิ่มเติม
V-Sync (vertical sync) คือการตั้งค่าที่ส่งเฟรมใหม่ออกไปเฉพาะจังหวะที่จอเปลี่ยนภาพ ภาพฉีก (screen tearing) จะหายไป แต่อินพุตจะช้าลงเท่าเวลาที่ต้องรอจังหวะนั้น และถ้า FPS ต่ำกว่า 60 จะสลับไปมาระหว่าง 60 กับ 30 จนภาพกระตุก จอ VRR (อัตรารีเฟรชแบบแปรผัน) จะเปลี่ยนภาพตามจังหวะที่เฟรมพร้อม จึงลดการรอนี้ได้ บนมือถือก็เกิดแบบเดียวกัน ถ้าเกม 30 FPS ส่งเฟรมออกให้สม่ำเสมอกับจอ 60 Hz ไม่ได้ ค่าเฉลี่ยจะยังเป็น 30 FPS แต่แต่ละเฟรมอยู่บนจอนานไม่เท่ากัน เช่น 49, 16, 33 ms จนภาพกระตุก (ตัวอย่างจากเอกสารนักพัฒนา Android) ลดได้ด้วยไลบรารี frame pacing (การทำให้ช่วงห่างการส่งเฟรมสม่ำเสมอ) ของ Android หรือตัวเลือกแบบเดียวกันในเอนจิน

แหล่งอ้างอิง

  1. IDXGIDevice1::SetMaximumFrameLatency Microsoft
    ค่าเริ่มต้นของจำนวนเฟรมที่ไดรเวอร์เก็บในคิวได้คือ 3 (1–16)
  2. Reduce latency with DXGI 1.3 swap chains Microsoft
    Present ถูกบล็อกจนกว่าคิวจะว่าง ทำให้ต้องรอเกือบอีกหนึ่งเฟรมตั้งแต่วาดเสร็จจนแสดงผล ลดได้ด้วย waitable swap chain
  3. Frame Pacing library Android (Google)
    บนจอ 60 Hz ถ้าไม่มีเฟรมใหม่จะแสดงเฟรมก่อนหน้าซ้ำ ตัวอย่างเกม 30 FPS ที่เฟรมไทม์แกว่งไม่สม่ำเสมอ เช่น 49, 16, 33 ms
  4. PresentMon Capture Application (README-CaptureApplication.md) Intel
    MsPCLatency (ตั้งแต่ PC รับอินพุตจนส่งภาพออกจอ), MsClickToPhotonLatency (คลิกเมาส์ถึงจอ), MsAllInputToPhotonLatency (อินพุตคีย์บอร์ด/เมาส์ถึงจอ), DisplayLatency (ตั้งแต่ submit เฟรมจนส่งออกไปที่จอ)
  5. PresentMon Console Application (README-ConsoleApplication.md) Intel
    MsPCLatency จะถูกบันทึกเมื่อแอปส่ง PC Latency event ออกมาเท่านั้น (--track_pc_latency), MsAllInputToPhotonLatency ยึดอินพุตคีย์บอร์ดและเมาส์

สาเหตุที่ควรดูประกอบ

ชั้นเดียวกัน: L1 โปรเซสเกมฝั่งไคลเอนต์

สาเหตุจากชั้นอื่นที่ทำให้เกิดอาการเดียวกัน (อินพุตดีเลย์)

ดูการ์ดในฉบับหลักที่มีภาพและการทดลอง