รองรับ OpenGL 4.6 ที่ใช้งานร่วมกับ M1

 (rosenzweig.io)
2 คะแนน โดย GN⁺ 2024-02-15 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

รองรับ OpenGL 4.6 และ OpenGL® ES 3.2

  • M1 รองรับเพียง OpenGL 4.1 มาเป็นเวลานาน แต่ตอนนี้รองรับ OpenGL® 4.6 และ OpenGL® ES 3.2 อย่างสมบูรณ์แล้ว
  • สามารถติดตั้ง Fedora เพื่อใช้ไดรเวอร์ล่าสุดสำหรับซีรีส์ M1/M2
  • หากติดตั้งอยู่แล้ว สามารถอัปเกรดได้ง่าย ๆ ด้วยคำสั่ง dnf upgrade --refresh
  • ต่างจากไดรเวอร์ 4.1 แบบไม่เป็นมาตรฐานของผู้ผลิตเดิม ไดรเวอร์ลินุกซ์โอเพนซอร์สเหล่านี้ผ่านการรับรองตาม OpenGL เวอร์ชันล่าสุด จึงรับประกันความเข้ากันได้อย่างกว้างขวางกับเวิร์กโหลด OpenGL สมัยใหม่ เช่น Blender, Ryujinx และ Citra

การรับรองไดรเวอร์และการรองรับมาตรฐาน

  • ไดรเวอร์ 4.6/3.2 ที่ผ่านการรับรองต้องผ่านการทดสอบมากกว่า 100,000 รายการเพื่อรับประกันความถูกต้อง
  • รายชื่อไดรเวอร์ที่ได้รับการรับรองอย่างเป็นทางการตอนนี้รวม OpenGL 4.6 และ ES 3.2 แล้ว
  • แม้ผู้ผลิตรายนั้นจะยังไม่รองรับมาตรฐานกราฟิกสมัยใหม่อย่าง OpenGL แต่บริษัทนี้รองรับ
  • บริษัทนี้แสดงออกอย่างเปิดเผยถึงความรักต่อมาตรฐานเปิดที่ทำงานร่วมกันได้ และต้องการมอบอิสระให้ผู้ใช้และนักพัฒนารันแอปพลิเคชันได้ในที่ที่ต้องการโดยไม่ต้องมีพอร์ตพิเศษ

ฟีเจอร์ใหม่ใน OpenGL 4.6

  • OpenGL 4.6 เพิ่มฟีเจอร์บังคับหลายสิบรายการเมื่อเทียบกับ 4.1:
    • Robustness (ความทนทาน)
    • SPIR-V
    • Clip control
    • Cull distance
    • Compute shaders
    • Upgraded transform feedback

ปัญหาความเข้ากันได้ของ M1 กับมาตรฐานกราฟิก

  • M1 ไม่เหมาะกับมาตรฐานกราฟิกที่ใหม่กว่า OpenGL ES 3.1 มากนัก
  • Vulkan ทำให้บางฟีเจอร์เป็นตัวเลือกได้ แต่เลเยอร์สำหรับ DirectX และ OpenGL ยังขาดฟีเจอร์ที่จำเป็น
  • บน M1 ยังไม่มีโซลูชันเดิมที่ก้าวข้ามชุดฟีเจอร์ OpenGL 4.1 ได้

วิธีข้ามข้อจำกัดของ 4.1

  • จำเป็นต้องมีวิธีใหม่ในการทำฟีเจอร์ใหม่ ๆ ให้ใช้งานได้โดยไม่ต้องพึ่งการรองรับจากฮาร์ดแวร์
  • Geometry shaders, tessellation และ transform feedback ถูกแทนที่ด้วย compute shaders
  • Cull distance ถูกแทนที่ด้วยค่าการอินเตอร์โพเลตที่แปลงแล้ว
  • Clip control ถูกแทนที่ด้วย vertex shader epilogue

ความท้าทายด้านความทนทาน

  • โดยปกติแล้ว GPU มักให้ความสำคัญกับประสิทธิภาพดิบมากกว่าความปลอดภัย
  • สำหรับแอปพลิเคชันอย่างเว็บเบราว์เซอร์ การแลกเปลี่ยนแบบนี้ไม่ใช่สิ่งที่พึงประสงค์
  • ฟีเจอร์ด้านความทนทานช่วยลดพื้นผิวการโจมตีได้โดยยอมเสียประสิทธิภาพเล็กน้อย ด้วยการเปิดให้แอปพลิเคชันเลือกพฤติกรรมที่กำหนดไว้เมื่อมีการเข้าถึงบัฟเฟอร์นอกขอบเขตใน shader

ความทนทานของบัฟเฟอร์

  • API อื่น ๆ มีนิยามต่างกันว่าเมื่อเปิดใช้ความทนทานแล้ว การโหลดข้อมูลนอกขอบเขตของบัฟเฟอร์ควรคืนค่าอะไร
  • OpenGL กำหนดให้การโหลดนอกขอบเขตคืนค่าเป็นองค์ประกอบสุดท้ายของบัฟเฟอร์
  • การคำนวณเพิ่มเติมเพื่อรองรับความทนทานถูกย้ายไปไว้ใน preamble ของ shader จึงไม่มีต้นทุนกับ shader หลัก

ความทนทานของอิมเมจ

  • ความทนทานของอิมเมจกำหนดให้การโหลดอิมเมจนอกขอบเขตต้องคืนค่า 0
  • บน GPU ของ M1 มีการทดสอบเพียงรายการเดียวที่ล้มเหลวกับการโหลดอิมเมจแบบ mipmapped
  • วิธีหลบเลี่ยงเพื่อรองรับความทนทานคือไม่โหลดจากระดับที่ไม่ถูกต้อง หรือโหลดแบบคาดเดาก่อนแล้วใช้การเปรียบเทียบและการเลือกค่า

ความเห็นของ GN⁺

  • บทความนี้กล่าวถึงพัฒนาการสำคัญในการรองรับมาตรฐาน OpenGL รุ่นใหม่บนอุปกรณ์ M1 ซึ่งจะนำมาซึ่งความเข้ากันได้ที่กว้างขึ้นและประสิทธิภาพที่ดีขึ้นสำหรับผู้ใช้ลินุกซ์และนักพัฒนา
  • ฟีเจอร์ใหม่ของ OpenGL 4.6 สามารถยกระดับทั้งประสิทธิภาพและความทนทานของแอปกราฟิกได้อย่างมาก ซึ่งสำคัญอย่างยิ่งในงานพัฒนาเกมและการประมวลผลสมรรถนะสูง
  • บทความนี้เป็นตัวอย่างที่ดีว่าไดรเวอร์โอเพนซอร์สสามารถมอบการปฏิบัติตามมาตรฐานและความเข้ากันได้ที่ดีกว่าโซลูชันเชิงพาณิชย์ได้อย่างไร

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-02-15
ความคิดเห็นบน Hacker News
  • Alyssa Rosenzweig เป็นคนที่มีส่วนร่วมกับชุมชนอย่างต่อเนื่อง และถ้าได้อ่านบล็อกโพสต์ของเธอ คุณจะได้เรียนรู้สิ่งที่ไม่เคยรู้มาก่อนเกี่ยวกับภายในของฮาร์ดแวร์กราฟิกสมัยใหม่ ความพยายามแบบนี้พิสูจน์ให้เห็นว่าฝีมือสำคัญกว่าคำพูด และแค่การอ่านบล็อกก็ทำให้น่าคิดได้มาก ข้อความสำคัญอยู่ในประโยคที่สอง ไม่ใช่ประโยคสุดท้าย และผู้อ่านจะได้ดำดิ่งลงไปในโพรงกระต่ายเพื่อเพลิดเพลินกับโลกของการจัดการบิต
  • ชิป M1 ไม่ได้เหมาะกับมาตรฐานกราฟิกที่ใหม่กว่า OpenGL ES 3.1 มากนัก โดย Vulkan สามารถใช้ฟีเจอร์บางอย่างได้แบบทางเลือก แต่ยังขาดฟีเจอร์ที่จำเป็นสำหรับการทำเลเยอร์สำหรับ DirectX และ OpenGL บน M1 จึงยังไม่มีวิธีแก้ปัญหาที่ก้าวข้ามชุดฟีเจอร์ของ OpenGL 4.1 ได้ จึงสงสัยว่าผลกระทบด้านประสิทธิภาพจะเป็นอย่างไร โดยเฉพาะเมื่อเทียบกับ Metal บน macOS
  • คิดว่าน่าสนใจที่ในการเขียนโปรแกรมกราฟิก การเรียกการเข้าถึงนอกขอบเขตที่เปลี่ยนจากการ trap ไปเป็นการคืนค่าข้อมูลสุ่มว่า "ความทนทาน" (robustness)
  • สักวันหนึ่ง Apple ก็คงจะเลิกใช้ OpenGL 3.3 core และนั่นอาจทำให้ทุกคนเลิกใช้มันไปด้วย โดยทั่วไปมักพูดกันว่า OpenGL ใช้งานง่ายกว่า Vulkan แต่ถ้ามันซับซ้อนเกินไป ก็อาจกลายเป็นอุปสรรคสำหรับนักพัฒนาที่ประสบการณ์ยังน้อยในการใช้ GPU ซึ่งอาจทำให้นักพัฒนาเกมอินดี้บางส่วนหมดกำลังใจ แม้การใช้ Unity และ Unreal จะเป็นเรื่องปกติ แต่การสร้างเกมตั้งแต่ต้นกลับถูกมองว่าแปลก สถานะของการพัฒนาเกมโอเพนซอร์สบางครั้งให้ความรู้สึกสิ้นหวังมาก และการมาของกราฟิก API ยุคถัดไปก็ยิ่งทำให้สถานการณ์ยากขึ้น
  • นี่เป็นเรื่องเกี่ยวกับ Fedora สำหรับชิป M1 และถ้าจะทำสิ่งนี้บน macOS ได้ก็น่าจะน่าทึ่งมาก จึงสงสัยว่าต้องทำงานอะไรบ้างถึงจะไปถึงจุดนั้น
  • สงสัยว่าทำไมถึงไม่เลือกเจาะจง Vulkan ก่อน เพราะทุกวันนี้ Vulkan ดูเป็นเป้าหมายที่สำคัญกว่า และก็มี implementation ของ OpenGL อยู่แล้ว
  • จะก้าวข้ามกำแพง 4.1 ได้อย่างไร? หากจะทำฟีเจอร์ใหม่โดยไม่มีการรองรับจากฮาร์ดแวร์ ก็ต้องใช้วิธีใหม่ ๆ geometry shader, tessellation และ transform feedback ถูกทำด้วย compute shader, cull distance ทำด้วยค่าที่ถูก interpolate หลังการแปลง, ส่วน clip control ทำใน epilogue ของ vertex shader จึงสงสัยว่างานลักษณะนี้ในโค้ด GPU ของ M1 ถูกทำไปมากน้อยแค่ไหน และการทำฟีเจอร์ผ่านฟีเจอร์อื่นจะนำกลับมาใช้ซ้ำได้มากเพียงใด
  • ขอแนะนำอีกชิ้น เป็นอีกบทความที่อยากเข้าใจให้ดีขึ้นในบริบทเมื่อมีความรู้และความอดทนมากกว่านี้ ถึงอย่างนั้น งานเขียนของ Alyssa ก็อ่านสนุกอยู่ดี
  • เป็นเรื่องน่าทึ่งที่เหตุผลเดียวที่ OpenGL ถูกใช้กับเกม 3D ก็เพราะ John Carmack ยึดติดกับมันสำหรับ Quake II ในยุค 90s