จัดการ VRAM เกินลิมิต: เมื่อการ์ดจอของคุณมีมากกว่าที่คุณคิด 🚀

เคยไหมที่เล่นเกมแล้วเจอปัญหา VRAM เต็ม การ์ดจอทำงานหนักจนเกมค้าง หรือแย่กว่านั้นคือเกมเด้งหลุดไปเลย? ปกติแล้วหลายคนจะคิดว่าเมื่อ VRAM เต็ม ก็คือจบแล้ว ประสบการณ์การเล่นเกมจะพังไปตลอดกาล แต่ในความเป็นจริงแล้ว การที่ VRAM เต็ม ไม่ได้หมายความว่าเราต้องยอมแพ้เสมอไป! บทความนี้จะพาคุณไปเจาะลึกว่าทำไมการ VRAM เต็มถึงส่งผลเสีย และที่สำคัญที่สุด เราจะทำอย่างไรให้ปัญหานี้ส่งผลกระทบน้อยที่สุดได้อย่างไร

ความคาดหวังเมื่อ VRAM เกินลิมิต 💡

ในทางทฤษฎี การที่ VRAM เต็มควรเป็นเพียงปัญหาด้านประสิทธิภาพ ไม่ใช่ความเสถียร เพราะไดรเวอร์การ์ดจอส่วนใหญ่รองรับการ "Overcommit" VRAM มานานแล้ว หมายความว่าเราสามารถขอใช้ VRAM มากกว่าที่การ์ดจอมีจริงได้ โดยไดรเวอร์จะจัดการจัดสรรหน่วยความจำเท่าที่ระบบจะทำได้

ทำไมประสิทธิภาพถึงตก? 📉

สาเหตุหลักที่ทำให้ประสิทธิภาพลดลงอย่างมากเมื่อ VRAM เต็ม คือเมื่อเกมร้องขอ VRAM มากกว่าที่มีอยู่จริง หน่วยความจำบางส่วนของเกมจะต้องถูกย้ายไปเก็บไว้ใน RAM ของ CPU แทน ซึ่งการที่ GPU (การ์ดจอ) จะเข้าถึง RAM ของ CPU นั้นช้ากว่า VRAM มาก ไม่ใช่แค่ความเร็วที่ช้ากว่า แต่การส่งข้อมูลยังต้องวิ่งผ่าน PCI bus ซึ่งเป็นคอขวดที่เพิ่มความหน่วง (Latency) และจำกัดแบนด์วิดท์ (Bandwidth) ในการดึงข้อมูลจาก RAM ของ CPU

ด้วยข้อจำกัดด้านความเร็วของ PCI bus หากมีการย้ายข้อมูล (Evict) ออกจาก VRAM จำนวนมากจน GPU ต้องดึงข้อมูลเกิน 1GB ต่อเฟรม ก็เป็นไปได้ยากที่จะรักษาเฟรมเรตให้ถึง 30 FPS ได้

ไม่ใช่ทุกหน่วยความจำจะเหมือนกัน 🧐

แม้ว่าการเข้าถึง RAM ของ CPU จะช้า แต่ก็ไม่ใช่จุดจบของประสิทธิภาพเสมอไป บางครั้งไดรเวอร์การ์ดจอก็เลือกที่จะเก็บข้อมูลบางอย่าง เช่น Command Buffer ไว้ใน RAM ของ CPU แม้ว่าจะมี VRAM เพียงพออยู่แล้วก็ตาม ซึ่งในกรณีเหล่านี้ ทุกอย่างก็ยังทำงานได้ดี

แล้วอะไรที่ทำให้การเข้าถึง VRAM ที่ถูกย้ายไป RAM ของ CPU แตกต่างกัน? ปัจจัยสำคัญคือ แคช (Cache)

แคชคือฮีโร่ (บางส่วน) 🦸

เมื่อข้อมูลอยู่ในแคช (ไม่ว่าจะเป็น L1, L2 หรือ L3) การเข้าถึงจะมีความเร็วใกล้เคียงกัน ไม่ว่าข้อมูลนั้นจะมาจาก RAM ของ CPU หรือ VRAM ก็ตาม เพราะข้อมูลถูกดึงมาจากแคชโดยตรง

จากการทดสอบ จะเห็นว่าเมื่อข้อมูลมีขนาดเล็กพอที่จะอยู่ในแคช L2 (ประมาณ 6MB สำหรับการ์ดจอบางรุ่น) ความหน่วงในการเข้าถึงข้อมูลจาก RAM ของ CPU และ VRAM จะใกล้เคียงกัน

อย่างไรก็ตาม การเข้าถึงข้อมูลครั้งแรกที่ยังไม่ได้อยู่ในแคช จะมีความหน่วงสูงมาก และการสูญเสีย Infinity Cache (แคชพิเศษของการ์ดจอ AMD) ก็ส่งผลกระทบอย่างมากเช่นกัน การเข้าถึงข้อมูลผ่าน PCIe อาจมีความหน่วงสูงกว่าการเข้าถึงผ่าน Infinity Cache ถึง 7.3 เท่า!

ดังนั้น การใช้ RAM ของ CPU แทน VRAM จะส่งผลกระทบต่อประสิทธิภาพอย่างหลีกเลี่ยงไม่ได้ แต่ผลกระทบจะมากน้อยแค่ไหน ขึ้นอยู่กับปัจจัยเหล่านี้:

  • รูปแบบการเข้าถึงข้อมูล (Access Pattern): หากเข้าถึงข้อมูลในลักษณะที่เอื้อต่อแคช (Cache-friendly) ผลกระทบจะน้อยลง
  • ความถี่ในการเข้าถึงข้อมูล: หากข้อมูลที่ถูกย้ายไป RAM ของ CPU ไม่ค่อยถูกเรียกใช้งาน ผลกระทบก็อาจจะไม่มากนัก
  • ปริมาณข้อมูลที่ถูกเรียกใช้งานจริง: แม้จะย้ายข้อมูลไปหลาย GB แต่ถ้า GPU เรียกใช้ข้อมูลจริงแค่ส่วนเล็กๆ และไม่บ่อยนัก ประสิทธิภาพก็อาจจะไม่แย่ลงจนสังเกตได้

สรุปคือ แม้ประสิทธิภาพจะลดลง แต่ก็มีโอกาสที่คุณจะสามารถเล่นเกมต่อไปได้ โดยที่ประสิทธิภาพไม่พังไปเสียทั้งหมด หากการเข้าถึงข้อมูลที่ถูกย้ายไป RAM ของ CPU เป็นไปในลักษณะที่เหมาะสม

เมื่อทฤษฎีสวนทางกับความเป็นจริง: ปัญหาความเสถียร ⚠️

แม้ว่าเราจะสามารถจัดการให้ VRAM Overcommit ทำงานได้ดีขึ้นในทางทฤษฎี แต่ในทางปฏิบัติ การที่ VRAM เต็มมักนำมาซึ่งปัญหาความเสถียรเสมอ โดยเฉพาะอย่างยิ่งเมื่อลองเปิดเกมด้วยการตั้งค่าที่สูงขึ้น

ข้อความผิดพลาดอย่าง "radv/amdgpu: Not enough memory for command submission" อาจปรากฏขึ้น ซึ่งข้อความนี้ไม่ได้หมายถึงการจัดสรรทรัพยากรใหม่โดยตรง แต่เกิดจากการที่ Kernel คืนค่า -ENOMEM เมื่อพยายามส่งคำสั่ง (Submit commands) ทั้งที่ก่อนหน้านี้การจัดสรรหน่วยความจำทั้งหมดสำเร็จแล้ว

เบื้องหลังปัญหา Kernel Locking 🚧

ไดรเวอร์ amdgpu จำเป็นต้องตรวจสอบให้แน่ใจว่าหน่วยความจำทั้งหมดที่ GPU อาจจะต้องเรียกใช้ สามารถเข้าถึงได้ก่อนที่จะเริ่มประมวลผลคำสั่ง โดยเฉพาะอย่างยิ่งกับ API กราฟิกแบบ Bindless ที่อาจมีการเรียกใช้หน่วยความจำใดๆ ก็ได้

หน่วยความจำบางประเภท จำเป็นต้องอยู่บน VRAM เท่านั้น หากหน่วยความจำเหล่านี้ถูกย้ายไป RAM ของ CPU (เพราะแอปพลิเคชันอื่นขอใช้ VRAM) ไดรเวอร์ amdgpu จะต้องย้ายมันกลับมาที่ VRAM แต่เนื่องจาก VRAM เต็ม การย้ายกลับจึงต้องทำการย้ายข้อมูลอื่นออกไป ซึ่งบางครั้งกระบวนการนี้ก็ล้มเหลวและทำให้ Kernel รายงานว่าหน่วยความจำไม่เพียงพอ

ปัญหานี้เกิดจาก Deadlock ในการจัดการ Lock ของ Kernel เมื่อ GPU กำลังเตรียมคำสั่ง (Submission) ไดรเวอร์จะต้อง Lock หน่วยความจำทั้งหมดที่เกี่ยวข้อง เพื่อป้องกันไม่ให้แอปพลิเคชันอื่นมาย้ายหน่วยความจำเหล่านั้นในขณะที่กำลังทำงานอยู่

หาก GPU Submission หนึ่งกำลัง Lock หน่วยความจำหนึ่งอยู่ ในขณะที่ GPU Submission อีกอันหนึ่งต้องการ Lock หน่วยความจำจากอันแรกเพื่อทำงานของตัวเอง ก็จะเกิดสภาวะ ABBA Deadlock ขึ้น

การแก้ไขปัญหา Deadlock ใน Kernel 🛠️

Kernel มีกลไกในการตรวจจับและแก้ไข Deadlock โดยจะมีการทำเครื่องหมาย "Wounded" ให้กับ Transaction ที่เกิด Deadlock และเมื่อ Transaction นั้นพยายาม Lock หน่วยความจำอีกครั้ง จะได้รับข้อผิดพลาด -EDEADLCK เพื่อให้ยกเลิก Transaction นั้น ปลด Lock ที่ถืออยู่ทั้งหมด และเริ่มใหม่

ในบริบทของการส่งคำสั่ง GPU สิ่งนี้หมายถึงการที่ไดรเวอร์จะเริ่มกระบวนการตรวจสอบและทำให้หน่วยความจำทั้งหมดสามารถเข้าถึงได้ใหม่อีกครั้ง

ทำไมถึงยังเกิดปัญหา? 🤔

แม้ว่ากลไกนี้จะแข็งแกร่ง แต่ปัญหาที่พบคือ การนำไปใช้งานจริงยังไม่ครอบคลุมทั้งหมด ในส่วนของ TTM (หน่วยจัดการหน่วยความจำ GPU แบบใช้ร่วมกัน) ซึ่งเป็นส่วนสำคัญของ Linux GPU Subsystem กลับมีการใช้งานกลไก drm_exec ที่ช่วยจัดการเรื่องนี้ค่อนข้างน้อย และมี Comment ที่ระบุว่า -EDEADLCK จะทำให้การ Evict ล้มเหลว

นี่คือต้นตอของปัญหา! เมื่อเกิด Deadlock เนื่องจาก VRAM ที่มีแรงกดดันสูงในระหว่างการส่งคำสั่ง Kernel ก็จะยกเลิกการส่งคำสั่งนั้นแทนที่จะลองใหม่

ความหวังใหม่: การปรับปรุง Kernel Patch 🩹

ปัจจุบันมี Patch Set ที่เสนอให้มีการนำ drm_exec มาใช้ใน TTM ตั้งแต่ปี 2024 แต่ยังไม่ถูกรวมเข้า Kernel เนื่องจากยังมี Bug ที่ต้องแก้ไข

นักพัฒนาได้ทำการ Rebase Patch Set เหล่านี้ และแก้ไข Bug ที่พบ ซึ่งต้องใช้เวลาและความพยายามอย่างมากในการทดสอบกับเกมที่ทำให้ VRAM เกิดการแย่งชิงอย่างหนัก

หลังจากแก้ไข Bug เหล่านี้แล้ว Patch Set ก็พร้อมที่จะถูกส่งเข้าไปพิจารณาอีกครั้ง เมื่อการแก้ไขนี้ได้รับการรวมเข้า Kernel แล้ว การที่ VRAM เต็มจะไม่ทำให้แอปพลิเคชันแครชแบบสุ่มอีกต่อไป ทำให้เราสามารถตั้งค่ากราฟิกให้สูงขึ้น และสังเกตการณ์ประสิทธิภาพที่แท้จริงได้


คำถามที่พบบ่อย

VRAM Overcommit คืออะไร?

VRAM Overcommit คือการที่ไดรเวอร์การ์ดจอยอมให้โปรแกรมขอใช้ VRAM มากกว่าที่การ์ดจอมีอยู่จริง โดยระบบจะจัดการย้ายข้อมูลบางส่วนไปเก็บไว้ใน RAM ของ CPU แทน

ทำไม VRAM เต็มแล้วเกมถึงช้าลง?

เมื่อ VRAM เต็ม ข้อมูลบางส่วนจะต้องถูกย้ายไปเก็บใน RAM ของ CPU ซึ่งการเข้าถึง RAM ของ CPU นั้นช้ากว่า VRAM มาก และต้องวิ่งผ่าน PCI bus ซึ่งเป็นคอขวด ทำให้การดึงข้อมูลช้าลง ส่งผลให้เฟรมเรตตก

การใช้ RAM ของ CPU แทน VRAM ส่งผลต่อประสิทธิภาพเสมอไปหรือไม่?

ไม่เสมอไป หากข้อมูลที่ถูกย้ายไป RAM ของ CPU มีลักษณะการเข้าถึงที่เอื้อต่อแคช (Cache-friendly) หรือถูกเรียกใช้งานไม่บ่อยนัก ผลกระทบต่อประสิทธิภาพอาจไม่มากนัก

ปัญหา "Not enough memory for command submission" คืออะไร?

เป็นข้อผิดพลาดที่เกิดจากปัญหา Deadlock ในการจัดการหน่วยความจำของ Kernel เมื่อ GPU กำลังประมวลผลคำสั่ง และมีการย้ายข้อมูลระหว่าง VRAM กับ RAM ของ CPU ซึ่งทำให้การส่งคำสั่งล้มเหลว

การแก้ไข Kernel Patch จะช่วยได้อย่างไร?

การรวม Patch Set ที่ปรับปรุงการจัดการ Lock ของ Kernel จะช่วยให้ระบบสามารถจัดการกับ Deadlock ได้ดีขึ้น ทำให้ VRAM Overcommit ทำงานได้อย่างเสถียรมากขึ้น ลดโอกาสที่แอปพลิเคชันจะแครชเมื่อ VRAM เต็ม และอาจช่วยให้ประสิทธิภาพดีขึ้นในบางกรณี

ขอบคุณ แหล่งข้อมูล
https://pixelcluster.dev/VRAM-Overcommit/

จัดการ VRAM เกินลิมิต: เมื่อการ์ดจอของคุณมีมากกว่าที่คุณคิด 🚀เคยไหมที่เล่นเกมแล้วเจอปัญหา VRAM เต็ม การ์ดจอทำงานหนักจนเกมค้าง หรือแย่กว่านั้นคือเกมเด้งหลุดไปเลย? ปกติแล้วหลายคนจะคิดว่าเมื่อ VRAM เต็ม ก็คือจบแล้ว ประสบการณ์การเล่นเกมจะพังไปตลอดกาล แต่ในความเป็นจริงแล้ว การที่ VRAM เต็ม ไม่ได้หมายความว่าเราต้องยอมแพ้เสมอไป! บทความนี้จะพาคุณไปเจาะลึกว่าทำไมการ VRAM เต็มถึงส่งผลเสีย และที่สำคัญที่สุด เราจะทำอย่างไรให้ปัญหานี้ส่งผลกระทบน้อยที่สุดได้อย่างไรความคาดหวังเมื่อ VRAM เกินลิมิต 💡ในทางทฤษฎี การที่ VRAM เต็มควรเป็นเพียงปัญหาด้านประสิทธิภาพ ไม่ใช่ความเสถียร เพราะไดรเวอร์การ์ดจอส่วนใหญ่รองรับการ "Overcommit" VRAM มานานแล้ว หมายความว่าเราสามารถขอใช้ VRAM มากกว่าที่การ์ดจอมีจริงได้ โดยไดรเวอร์จะจัดการจัดสรรหน่วยความจำเท่าที่ระบบจะทำได้ทำไมประสิทธิภาพถึงตก? 📉สาเหตุหลักที่ทำให้ประสิทธิภาพลดลงอย่างมากเมื่อ VRAM เต็ม คือเมื่อเกมร้องขอ VRAM มากกว่าที่มีอยู่จริง หน่วยความจำบางส่วนของเกมจะต้องถูกย้ายไปเก็บไว้ใน RAM ของ CPU แทน ซึ่งการที่ GPU (การ์ดจอ) จะเข้าถึง RAM ของ CPU นั้นช้ากว่า VRAM มาก ไม่ใช่แค่ความเร็วที่ช้ากว่า แต่การส่งข้อมูลยังต้องวิ่งผ่าน PCI bus ซึ่งเป็นคอขวดที่เพิ่มความหน่วง (Latency) และจำกัดแบนด์วิดท์ (Bandwidth) ในการดึงข้อมูลจาก RAM ของ CPUด้วยข้อจำกัดด้านความเร็วของ PCI bus หากมีการย้ายข้อมูล (Evict) ออกจาก VRAM จำนวนมากจน GPU ต้องดึงข้อมูลเกิน 1GB ต่อเฟรม ก็เป็นไปได้ยากที่จะรักษาเฟรมเรตให้ถึง 30 FPS ได้ไม่ใช่ทุกหน่วยความจำจะเหมือนกัน 🧐แม้ว่าการเข้าถึง RAM ของ CPU จะช้า แต่ก็ไม่ใช่จุดจบของประสิทธิภาพเสมอไป บางครั้งไดรเวอร์การ์ดจอก็เลือกที่จะเก็บข้อมูลบางอย่าง เช่น Command Buffer ไว้ใน RAM ของ CPU แม้ว่าจะมี VRAM เพียงพออยู่แล้วก็ตาม ซึ่งในกรณีเหล่านี้ ทุกอย่างก็ยังทำงานได้ดีแล้วอะไรที่ทำให้การเข้าถึง VRAM ที่ถูกย้ายไป RAM ของ CPU แตกต่างกัน? ปัจจัยสำคัญคือ แคช (Cache)แคชคือฮีโร่ (บางส่วน) 🦸เมื่อข้อมูลอยู่ในแคช (ไม่ว่าจะเป็น L1, L2 หรือ L3) การเข้าถึงจะมีความเร็วใกล้เคียงกัน ไม่ว่าข้อมูลนั้นจะมาจาก RAM ของ CPU หรือ VRAM ก็ตาม เพราะข้อมูลถูกดึงมาจากแคชโดยตรงจากการทดสอบ จะเห็นว่าเมื่อข้อมูลมีขนาดเล็กพอที่จะอยู่ในแคช L2 (ประมาณ 6MB สำหรับการ์ดจอบางรุ่น) ความหน่วงในการเข้าถึงข้อมูลจาก RAM ของ CPU และ VRAM จะใกล้เคียงกันอย่างไรก็ตาม การเข้าถึงข้อมูลครั้งแรกที่ยังไม่ได้อยู่ในแคช จะมีความหน่วงสูงมาก และการสูญเสีย Infinity Cache (แคชพิเศษของการ์ดจอ AMD) ก็ส่งผลกระทบอย่างมากเช่นกัน การเข้าถึงข้อมูลผ่าน PCIe อาจมีความหน่วงสูงกว่าการเข้าถึงผ่าน Infinity Cache ถึง 7.3 เท่า!ดังนั้น การใช้ RAM ของ CPU แทน VRAM จะส่งผลกระทบต่อประสิทธิภาพอย่างหลีกเลี่ยงไม่ได้ แต่ผลกระทบจะมากน้อยแค่ไหน ขึ้นอยู่กับปัจจัยเหล่านี้:รูปแบบการเข้าถึงข้อมูล (Access Pattern): หากเข้าถึงข้อมูลในลักษณะที่เอื้อต่อแคช (Cache-friendly) ผลกระทบจะน้อยลงความถี่ในการเข้าถึงข้อมูล: หากข้อมูลที่ถูกย้ายไป RAM ของ CPU ไม่ค่อยถูกเรียกใช้งาน ผลกระทบก็อาจจะไม่มากนักปริมาณข้อมูลที่ถูกเรียกใช้งานจริง: แม้จะย้ายข้อมูลไปหลาย GB แต่ถ้า GPU เรียกใช้ข้อมูลจริงแค่ส่วนเล็กๆ และไม่บ่อยนัก ประสิทธิภาพก็อาจจะไม่แย่ลงจนสังเกตได้สรุปคือ แม้ประสิทธิภาพจะลดลง แต่ก็มีโอกาสที่คุณจะสามารถเล่นเกมต่อไปได้ โดยที่ประสิทธิภาพไม่พังไปเสียทั้งหมด หากการเข้าถึงข้อมูลที่ถูกย้ายไป RAM ของ CPU เป็นไปในลักษณะที่เหมาะสมเมื่อทฤษฎีสวนทางกับความเป็นจริง: ปัญหาความเสถียร ⚠️แม้ว่าเราจะสามารถจัดการให้ VRAM Overcommit ทำงานได้ดีขึ้นในทางทฤษฎี แต่ในทางปฏิบัติ การที่ VRAM เต็มมักนำมาซึ่งปัญหาความเสถียรเสมอ โดยเฉพาะอย่างยิ่งเมื่อลองเปิดเกมด้วยการตั้งค่าที่สูงขึ้นข้อความผิดพลาดอย่าง "radv/amdgpu: Not enough memory for command submission" อาจปรากฏขึ้น ซึ่งข้อความนี้ไม่ได้หมายถึงการจัดสรรทรัพยากรใหม่โดยตรง แต่เกิดจากการที่ Kernel คืนค่า -ENOMEM เมื่อพยายามส่งคำสั่ง (Submit commands) ทั้งที่ก่อนหน้านี้การจัดสรรหน่วยความจำทั้งหมดสำเร็จแล้วเบื้องหลังปัญหา Kernel Locking 🚧ไดรเวอร์ amdgpu จำเป็นต้องตรวจสอบให้แน่ใจว่าหน่วยความจำทั้งหมดที่ GPU อาจจะต้องเรียกใช้ สามารถเข้าถึงได้ก่อนที่จะเริ่มประมวลผลคำสั่ง โดยเฉพาะอย่างยิ่งกับ API กราฟิกแบบ Bindless ที่อาจมีการเรียกใช้หน่วยความจำใดๆ ก็ได้หน่วยความจำบางประเภท จำเป็นต้องอยู่บน VRAM เท่านั้น หากหน่วยความจำเหล่านี้ถูกย้ายไป RAM ของ CPU (เพราะแอปพลิเคชันอื่นขอใช้ VRAM) ไดรเวอร์ amdgpu จะต้องย้ายมันกลับมาที่ VRAM แต่เนื่องจาก VRAM เต็ม การย้ายกลับจึงต้องทำการย้ายข้อมูลอื่นออกไป ซึ่งบางครั้งกระบวนการนี้ก็ล้มเหลวและทำให้ Kernel รายงานว่าหน่วยความจำไม่เพียงพอปัญหานี้เกิดจาก Deadlock ในการจัดการ Lock ของ Kernel เมื่อ GPU กำลังเตรียมคำสั่ง (Submission) ไดรเวอร์จะต้อง Lock หน่วยความจำทั้งหมดที่เกี่ยวข้อง เพื่อป้องกันไม่ให้แอปพลิเคชันอื่นมาย้ายหน่วยความจำเหล่านั้นในขณะที่กำลังทำงานอยู่หาก GPU Submission หนึ่งกำลัง Lock หน่วยความจำหนึ่งอยู่ ในขณะที่ GPU Submission อีกอันหนึ่งต้องการ Lock หน่วยความจำจากอันแรกเพื่อทำงานของตัวเอง ก็จะเกิดสภาวะ ABBA Deadlock ขึ้นการแก้ไขปัญหา Deadlock ใน Kernel 🛠️Kernel มีกลไกในการตรวจจับและแก้ไข Deadlock โดยจะมีการทำเครื่องหมาย "Wounded" ให้กับ Transaction ที่เกิด Deadlock และเมื่อ Transaction นั้นพยายาม Lock หน่วยความจำอีกครั้ง จะได้รับข้อผิดพลาด -EDEADLCK เพื่อให้ยกเลิก Transaction นั้น ปลด Lock ที่ถืออยู่ทั้งหมด และเริ่มใหม่ในบริบทของการส่งคำสั่ง GPU สิ่งนี้หมายถึงการที่ไดรเวอร์จะเริ่มกระบวนการตรวจสอบและทำให้หน่วยความจำทั้งหมดสามารถเข้าถึงได้ใหม่อีกครั้งทำไมถึงยังเกิดปัญหา? 🤔แม้ว่ากลไกนี้จะแข็งแกร่ง แต่ปัญหาที่พบคือ การนำไปใช้งานจริงยังไม่ครอบคลุมทั้งหมด ในส่วนของ TTM (หน่วยจัดการหน่วยความจำ GPU แบบใช้ร่วมกัน) ซึ่งเป็นส่วนสำคัญของ Linux GPU Subsystem กลับมีการใช้งานกลไก drm_exec ที่ช่วยจัดการเรื่องนี้ค่อนข้างน้อย และมี Comment ที่ระบุว่า -EDEADLCK จะทำให้การ Evict ล้มเหลวนี่คือต้นตอของปัญหา! เมื่อเกิด Deadlock เนื่องจาก VRAM ที่มีแรงกดดันสูงในระหว่างการส่งคำสั่ง Kernel ก็จะยกเลิกการส่งคำสั่งนั้นแทนที่จะลองใหม่ความหวังใหม่: การปรับปรุง Kernel Patch 🩹ปัจจุบันมี Patch Set ที่เสนอให้มีการนำ drm_exec มาใช้ใน TTM ตั้งแต่ปี 2024 แต่ยังไม่ถูกรวมเข้า Kernel เนื่องจากยังมี Bug ที่ต้องแก้ไขนักพัฒนาได้ทำการ Rebase Patch Set เหล่านี้ และแก้ไข Bug ที่พบ ซึ่งต้องใช้เวลาและความพยายามอย่างมากในการทดสอบกับเกมที่ทำให้ VRAM เกิดการแย่งชิงอย่างหนักหลังจากแก้ไข Bug เหล่านี้แล้ว Patch Set ก็พร้อมที่จะถูกส่งเข้าไปพิจารณาอีกครั้ง เมื่อการแก้ไขนี้ได้รับการรวมเข้า Kernel แล้ว การที่ VRAM เต็มจะไม่ทำให้แอปพลิเคชันแครชแบบสุ่มอีกต่อไป ทำให้เราสามารถตั้งค่ากราฟิกให้สูงขึ้น และสังเกตการณ์ประสิทธิภาพที่แท้จริงได้คำถามที่พบบ่อยVRAM Overcommit คืออะไร?VRAM Overcommit คือการที่ไดรเวอร์การ์ดจอยอมให้โปรแกรมขอใช้ VRAM มากกว่าที่การ์ดจอมีอยู่จริง โดยระบบจะจัดการย้ายข้อมูลบางส่วนไปเก็บไว้ใน RAM ของ CPU แทนทำไม VRAM เต็มแล้วเกมถึงช้าลง?เมื่อ VRAM เต็ม ข้อมูลบางส่วนจะต้องถูกย้ายไปเก็บใน RAM ของ CPU ซึ่งการเข้าถึง RAM ของ CPU นั้นช้ากว่า VRAM มาก และต้องวิ่งผ่าน PCI bus ซึ่งเป็นคอขวด ทำให้การดึงข้อมูลช้าลง ส่งผลให้เฟรมเรตตกการใช้ RAM ของ CPU แทน VRAM ส่งผลต่อประสิทธิภาพเสมอไปหรือไม่?ไม่เสมอไป หากข้อมูลที่ถูกย้ายไป RAM ของ CPU มีลักษณะการเข้าถึงที่เอื้อต่อแคช (Cache-friendly) หรือถูกเรียกใช้งานไม่บ่อยนัก ผลกระทบต่อประสิทธิภาพอาจไม่มากนักปัญหา "Not enough memory for command submission" คืออะไร?เป็นข้อผิดพลาดที่เกิดจากปัญหา Deadlock ในการจัดการหน่วยความจำของ Kernel เมื่อ GPU กำลังประมวลผลคำสั่ง และมีการย้ายข้อมูลระหว่าง VRAM กับ RAM ของ CPU ซึ่งทำให้การส่งคำสั่งล้มเหลวการแก้ไข Kernel Patch จะช่วยได้อย่างไร?การรวม Patch Set ที่ปรับปรุงการจัดการ Lock ของ Kernel จะช่วยให้ระบบสามารถจัดการกับ Deadlock ได้ดีขึ้น ทำให้ VRAM Overcommit ทำงานได้อย่างเสถียรมากขึ้น ลดโอกาสที่แอปพลิเคชันจะแครชเมื่อ VRAM เต็ม และอาจช่วยให้ประสิทธิภาพดีขึ้นในบางกรณีhttps://pixelcluster.dev/VRAM-Overcommit/
4 Commentaires 0 Parts 237 Vue 0 Aperçu