การย้อนรำลึกถึงผลงานโลหะ

เราได้ส่งมอบระบบหลังบ้านสำหรับการเรนเดอร์แบบ Metal ให้กับผู้ใช้หลายล้านคนเรียบร้อยแล้ว และผมอยากจะเขียนเกี่ยวกับเรื่องนี้สักเล็กน้อย มีความคิดเห็นที่หลากหลายเกี่ยวกับ Metal ในอุตสาหกรรม - บางคนอ้างว่า Metal จะไม่จำเป็นหาก Apple ให้ความสนใจกับ OpenGL และ Vulkan มากขึ้น บางคนบอกว่ามันเป็น API กราฟิกที่ง่ายที่สุดที่เคยมีมา ทำไมต้องสนใจ Metal ด้วย บางคนถามว่า ถ้าคุณสามารถเขียนโค้ด OpenGL หรือ Vulkan และใช้ MoltenGL หรือ MoltenVK ให้ได้ผลเหมือนกันได้? นี่คือความคิดของฉันเกี่ยวกับ API นี้

ทำไมต้องเป็นโลหะ?

เมื่อแอปเปิลประกาศ Metal ที่งาน WWDC ในปี 2014 ปฏิกิริยาแรกของผมคือการไม่สนใจมัน มันสามารถใช้ได้เฉพาะบนฮาร์ดแวร์รุ่นใหม่ล่าสุดเท่านั้น ซึ่งผู้ใช้ส่วนใหญ่ของเราไม่มี และแม้ว่าแอปเปิลจะอ้างว่า Metal แก้ปัญหาประสิทธิภาพของ CPU ได้ แต่สำหรับเราแล้ว การปรับให้เหมาะกับตลาดที่เล็กที่สุดจะหมายถึงช่องว่างระหว่างอุปกรณ์ที่เร็วที่สุดกับอุปกรณ์ที่ช้าที่สุดจะยิ่งกว้างขึ้น ในขณะนั้น เรากำลังใช้งาน OpenGL ES 2 เฉพาะบนอุปกรณ์ของ Apple เท่านั้น และยังเริ่มพัฒนาพอร์ตไปยัง Android ด้วย

ข้ามไปข้างหน้าสองปีครึ่ง และนี่คือภาพรวมส่วนแบ่งตลาดของ Metal สำหรับผู้ใช้ของเรา:

นี่ดูน่าสนใจกว่าที่เคยเป็นมาอย่างมาก อย่างไรก็ตาม การนำ Metal ไปใช้ก็ยังไม่ช่วยอุปกรณ์รุ่นเก่าที่สุดอยู่ดี แต่ตลาด GL บน iOS ก็ยังคงหดตัวลงเรื่อยๆ นอกจากนี้ เนื้อหาที่เราใช้งานบนอุปกรณ์ที่เก่าที่สุดมักจะแตกต่างจากเนื้อหาที่ใช้งานบนอุปกรณ์ใหม่ล่าสุด ดังนั้นจึงมีเหตุผลอย่างยิ่งที่จะทุ่มเทความพยายามบางส่วนเพื่อทำให้อุปกรณ์เหล่านี้ทำงานได้เร็วขึ้น เมื่อพิจารณาว่าโค้ด Metal ของ iOS จะทำงานบน Mac ได้โดยมีการเปลี่ยนแปลงเพียงเล็กน้อย จึงอาจสมเหตุสมผลที่จะใช้โค้ดนี้บน Mac ด้วย แม้ว่าคุณจะมุ่งเน้นไปที่อุปกรณ์มือถือเป็นหลักก็ตาม (ปัจจุบันเราจัดส่งเฉพาะเวอร์ชัน Metal บน iOS เท่านั้น)

ผมคิดว่ามันคุ้มค่าที่จะวิเคราะห์ส่วนแบ่งตลาดในรายละเอียดเพิ่มเติมเล็กน้อย บน iOS เราสนับสนุน Metal สำหรับ iOS 8.3 ขึ้นไป แม้ว่าจะมีผู้ใช้บางรายที่ไม่สามารถใช้งาน Metal ได้เนื่องจากข้อจำกัดของเวอร์ชันระบบปฏิบัติการ แต่ส่วนใหญ่ของ 25% ที่ยังคงใช้ GL อยู่เป็นเพียงผู้ใช้ที่ใช้อุปกรณ์รุ่นเก่าที่มีฮาร์ดแวร์ SGX เท่านั้น พวกเขายังไม่มีฟีเจอร์ OpenGL ES 3 ใดๆ และเราพอใจกับการใช้เส้นทางการเรนเดอร์ระดับล่างในที่นี้ (แม้ว่าเราจะอยากให้ทุกอุปกรณ์ใช้ Metal ก็ตาม) โชคดีที่การแยก GL/Metal จะช่วยปรับปรุงให้ดีขึ้น) บน Mac, Metal API เป็นเวอร์ชันใหม่กว่าและระบบปฏิบัติการก็มีบทบาทสำคัญมาก คุณต้องใช้ OSX 10.11 ขึ้นไปเพื่อใช้ Metal และครึ่งหนึ่งของผู้ใช้ของเราใช้ระบบปฏิบัติการที่เก่ากว่า มันไม่ใช่เรื่องของฮาร์ดแวร์มากนัก แต่เป็นเรื่องของซอฟต์แวร์มากกว่า (95% ของผู้ใช้ Mac ของเราใช้ OpenGL 3.2 ขึ้นไป)

ดังนั้น เมื่อพิจารณาส่วนแบ่งตลาดแล้ว ยังมีตัวเลือกอื่น ๆ ที่ไม่จำเป็นต้องพอร์ตไปยัง Metal หนึ่งในนั้นคือการใช้ MoltenGL ซึ่งจะใช้โค้ด OpenGL ที่เรามีอยู่แล้ว แต่คาดว่าจะเร็วกว่า อีกทางเลือกหนึ่งคือการพอร์ตไปยัง Vulkan (เพื่อให้ได้ประสิทธิภาพที่ดีขึ้นบน PC และในที่สุดก็ Android) หรือใช้ MoltenVK ผมได้ประเมิน MoltenGL อย่างคร่าว ๆ แล้วและไม่ค่อยประทับใจกับผลลัพธ์ที่ได้ ต้องใช้ความพยายามพอสมควรในการทำให้โค้ดของเราทำงานได้เลย และถึงแม้ว่าประสิทธิภาพจะดีขึ้นเล็กน้อยเมื่อเทียบกับ OpenGL พื้นฐาน แต่ผมก็ยังคาดหวังมากกว่านี้ สำหรับ MoltenVK ผมคิดว่าเป็นแนวคิดที่ผิดทางที่จะพยายามนำ API ระดับต่ำหนึ่งมาทำเป็นชั้นซ้อนทับอีกอันหนึ่ง คุณจะต้องเจอปัญหาความไม่สอดคล้องกันของระบบ ซึ่งจะส่งผลให้ประสิทธิภาพไม่ดีที่สุด บางทีมันอาจจะดีกว่า API ระดับสูงที่คุณเคยใช้ แต่มันไม่น่าจะเร็วที่สุดเท่าที่จะเป็นไปได้ ซึ่งนั่นน่าจะเป็นเหตุผลที่คุณเลือกใช้ API ระดับต่ำตั้งแต่แรก! อีกประเด็นสำคัญหนึ่งคือการใช้งาน Metal นั้นง่ายกว่า Vulkan มาก - จะพูดถึงเรื่องนี้เพิ่มเติมในภายหลัง - ดังนั้นในบางแง่มุม ผมจึงชอบ wrapper จาก Metal ไป Vulkan มากกว่าจาก Vulkan ไป Metal

นอกจากนี้ยังควรสังเกตว่าไม่มีไดรเวอร์ GL บน iOS 10 บน iPhone รุ่นใหม่ล่าสุด ดูเหมือนว่า GL ถูกนำไปใช้บน Metal ซึ่งหมายความว่าการใช้ OpenGL จะช่วยประหยัดความพยายามในการพัฒนาได้เพียงเล็กน้อยเท่านั้น - ไม่มากนัก เมื่อพิจารณาถึงคำสัญญาของ "เขียนครั้งเดียว ใช้งานได้ทุกที่" ที่ OpenGL มี ซึ่งไม่ได้ผลจริงบนมือถือ

การพอร์ต

ผมขอบอกว่าการพอร์ตไปยัง Metal นั้นง่ายมากโดยรวม เรามีประสบการณ์มากมายในการทำงานกับ API กราฟิกต่างๆ ตั้งแต่ API ระดับสูงอย่าง Direct3D 9/11 ไปจนถึง API ระดับต่ำบนแพลตฟอร์มคอนโซล สิ่งนี้ให้ข้อได้เปรียบที่ไม่เหมือนใครในการสามารถใช้ API อย่าง Metal ได้อย่างสบาย ซึ่งอยู่ในระดับสูงพอสมควรแต่ก็ยังคงปล่อยให้งานบางอย่าง เช่น การซิงโครไนซ์ระหว่าง CPU และ GPU ให้ผู้พัฒนาแอปเป็นผู้จัดการเอง

อุปสรรคเดียวคือการทำให้เชดเดอร์ของเราสามารถคอมไพล์ได้ เมื่อทำสำเร็จและถึงเวลาเขียนโค้ด ก็เห็นได้ชัดว่า API นั้นเรียบง่ายและเข้าใจได้ด้วยตนเองมากจนโค้ดแทบจะเขียนได้เอง ผมสามารถทำให้พอร์ตที่แสดงผลส่วนใหญ่ได้ไม่ค่อยดีนักทำงานได้ในเวลาประมาณ 10 ชั่วโมงในวันเดียว และใช้เวลาอีกสองสัปดาห์ในการทำความสะอาดโค้ด แก้ไขปัญหาการตรวจสอบความถูกต้อง การวิเคราะห์และปรับประสิทธิภาพ และการขัดเกลาทั่วไป การที่สามารถสร้างการใช้งาน API ได้ในช่วงเวลานี้แสดงให้เห็นถึงคุณภาพของ API และชุดเครื่องมือได้อย่างชัดเจน ผมเชื่อว่ามีส่วนประกอบหลายประการที่มีส่วนช่วย:

• คุณสามารถพัฒนาโค้ดได้เป็นขั้นตอน โดยมีการให้ข้อมูลย้อนกลับที่ดีในทุกขั้นตอน โค้ดของเราเริ่มต้นด้วยการไม่สนใจการซิงโครไนซ์ระหว่าง CPU และ GPU เลย ซึ่งทำให้บางส่วนของการตั้งค่าสถานะไม่ดีนัก ใช้การติดตามทรัพยากรแบบอ้างอิงในตัว และไม่เคยรัน CPU และ GPU พร้อมกันเพื่อหลีกเลี่ยงปัญหา การปรับแต่ง/เพิ่มประสิทธิภาพในขั้นตอนต่อมาได้เปลี่ยนโค้ดนี้ให้กลายเป็นสิ่งที่เราสามารถนำไปใช้ได้ โดยไม่สูญเสียความสามารถในการเรนเดอร์ในระหว่างกระบวนการ
• เครื่องมือเหล่านี้มีให้คุณแล้ว; พวกมันทำงานได้ดีและทำงานได้ดีมาก นี่อาจไม่ใช่เรื่องน่าแปลกใจสำหรับผู้คนที่คุ้นเคยกับ Direct3D 11 แต่นี่เป็นครั้งแรกบนมือถือที่ผมมีโปรไฟล์เลอร์ CPU, โปรไฟล์เลอร์ GPU, ดีบักเกอร์ GPU, และชั้นตรวจสอบความถูกต้องของ API GPU ที่ทำงานร่วมกันได้ดี ตรวจจับปัญหาส่วนใหญ่ในระหว่างการพัฒนา และช่วยปรับปรุงโค้ดให้ดีขึ้น
• แม้ว่า API จะมีระดับต่ำกว่า Direct3D 11 อยู่บ้าง และปล่อยให้ผู้พัฒนาตัดสินใจในบางเรื่องที่สำคัญในระดับต่ำ (เช่น การกำหนดค่าการเรนเดอร์หรือการซิงโครไนซ์) แต่ก็ยังคงใช้โมเดลทรัพยากรแบบดั้งเดิมที่แต่ละทรัพยากรมี "แฟล็กการใช้งาน" ที่ถูกสร้างขึ้นมาด้วย แต่ไม่จำเป็นต้องใช้ตัวกั้นในท่อหรือการเปลี่ยนเลย์เอาต์ และใช้โมเดลการผูกแบบดั้งเดิมที่แต่ละขั้นตอนของเชดเดอร์มีช่องว่างหลายช่องที่คุณสามารถกำหนดทรัพยากรได้อย่างอิสระ ทั้งสองอย่างนี้คุ้นเคย เข้าใจง่าย และต้องการโค้ดเพียงเล็กน้อยเพื่อให้เริ่มใช้งานได้อย่างรวดเร็ว

อีกสิ่งหนึ่งที่ช่วยได้คือ อินเทอร์เฟซ API ของเราพร้อมสำหรับ API แบบ Metal แล้ว มันมีความเรียบง่ายมากแต่เปิดเผยรายละเอียดเพียงพอ (เช่น การผ่านขั้นตอนการเรนเดอร์) เพื่อให้สามารถเขียนการใช้งานที่มีประสิทธิภาพได้อย่างง่ายดาย ในระหว่างการดำเนินการของเรา ไม่มีจุดใดเลยที่ฉันจำเป็นต้องบันทึก/กู้คืนสถานะ (หลายอินเทอร์เฟซของ API มีปัญหานี้ โดยเฉพาะอย่างยิ่งเนื่องจากการจัดการการตั้งค่าเป้าหมายการแสดงผลเป็นการเปลี่ยนแปลงสถานะและการผูกทรัพยากร/สถานะที่คงอยู่ผ่านสิ่งนั้น) หรือทำการตัดสินใจที่ซับซ้อนเกี่ยวกับอายุการใช้งานของทรัพยากร/การซิงโครไนซ์ เกี่ยวกับโค้ดที่ "ซับซ้อน" เพียงอย่างเดียวที่จำเป็นสำหรับการเรนเดอร์ คือโค้ดที่สร้างสถานะของเรนเดอร์ไพพ์ไลน์โดยการแฮชบิตที่จำเป็นในการสร้างสถานะนั้น - วัตถุสถานะของไพพ์ไลน์ไม่ได้เป็นส่วนหนึ่งของการนามธรรม API ของเรา แม้แต่ส่วนนั้นก็ค่อนข้างตรงไปตรงมาและรวดเร็ว ผมจะเขียนเพิ่มเติมเกี่ยวกับอินเตอร์เฟซ API ของเราในโพสต์แยกต่างหาก

ดังนั้น หนึ่งสัปดาห์สำหรับการคอมไพล์เชดเดอร์ สองสัปดาห์สำหรับการปรับแต่งและเพิ่มประสิทธิภาพการใช้งาน (ใช่แล้ว บางทีอาจต้องใช้เวลาอีกหนึ่งสัปดาห์ในการแก้ไขบั๊กที่พบระหว่างการทดสอบ) - ผลลัพธ์เป็นอย่างไร? ผลลัพธ์ยอดเยี่ยมมาก Metal มอบประสิทธิภาพตามที่สัญญาไว้ได้อย่างสมบูรณ์แบบ ประการหนึ่ง ประสิทธิภาพการประมวลผลแบบเธรดเดียว (single threaded dispatch) นั้นดีขึ้นอย่างเห็นได้ชัดเมื่อเทียบกับ OpenGL (โดยส่วนของการส่งคำสั่งวาดภาพในเฟรมเรนเดอร์ของเราลดลง 2-3 เท่า ขึ้นอยู่กับปริมาณงาน) ทั้งที่การปรับแต่ง OpenGL ของเราเองก็ถือว่าทำได้ดีแล้วในแง่ของการลดการตั้งค่าสถานะที่ซ้ำซ้อนและทำงานร่วมกับไดรเวอร์ได้อย่างราบรื่นโดยใช้เส้นทางที่รวดเร็ว อย่างไรก็ตาม จุดเด่นยังไม่หมดเพียงเท่านี้—การประมวลผลแบบมัลติเธรดใน Metal นั้นสามารถนำไปใช้ได้อย่างง่ายดาย หากโค้ดการเรนเดอร์ของคุณพร้อมรองรับ เรายังไม่ได้เปลี่ยนไปใช้การส่งงานแบบแยกเธรด (threaded draw dispatch) แต่กำลังอยู่ในขั้นตอนการแปลงส่วนอื่น ๆ ที่เตรียมทรัพยากรให้ทำงานนอกเธรดการเรนเดอร์ ซึ่งแตกต่างจาก OpenGL ตรงที่กระบวนการนี้แทบไม่ต้องใช้ความพยายามเลย

นอกเหนือจากนั้น Metal ยังช่วยให้เราสามารถแก้ไขปัญหาด้านประสิทธิภาพอื่นๆ ได้โดยให้เครื่องมือที่เข้าถึงได้ง่ายและเชื่อถือได้ หนึ่งในส่วนสำคัญของโค้ดการเรนเดอร์ของเราคือระบบที่คำนวณข้อมูลแสงบน CPU ในพื้นที่โลกและอัปโหลดไปยังพื้นที่ของเท็กซ์เจอร์ 3 มิติ (ซึ่งเราต้องจำลองบนฮาร์ดแวร์ OpenGL ES 2) การอัปเดตเป็นแบบบางส่วน ดังนั้นเราจึงไม่สามารถทำซ้ำเท็กซ์เจอร์ทั้งหมดได้และต้องพึ่งพาวิธีการที่ไดรเวอร์ใช้สำหรับการจำลองการเข้าถึงหน่วยความจำแบบไม่ต่อเนื่อง (glTexSubImage3D) ในช่วงหนึ่งเราพยายามใช้ PBO เพื่อปรับปรุงประสิทธิภาพการอัปเดต แต่พบปัญหาความเสถียรอย่างมากในทุกด้าน ทั้งบน Android และ iOS สำหรับ Metal มีวิธีฝังตัวสองวิธีในการอัปโหลดพื้นที่ - MTLTexture.replaceRegion ซึ่งคุณสามารถใช้ได้หาก GPU ไม่ได้อ่านเท็กซ์เจอร์อยู่ในขณะนั้น หรือ MTLBlitCommandEncoder (copyFromBufferToTexture  หรือ copyFromTextureToTexture) ที่สามารถอัปโหลดพื้นที่แบบอะซิงโครนัสได้ทันเวลาพอดีที่ GPU จะเริ่มใช้เท็กซ์เจอร์ 

ในฐานะความคิดเห็นทั่วไปสุดท้าย การรักษาโค้ด Metal นั้นแทบไม่ต้องใช้ความพยายามเลย ทุกฟีเจอร์พิเศษที่เราต้องเพิ่มเข้ามาจนถึงตอนนี้ ล้วนง่ายกว่าการเพิ่มใน API อื่นๆ ที่เราสนับสนุน และผมคาดว่าแนวโน้มนี้จะยังคงดำเนินต่อไป มีความกังวลเล็กน้อยว่าการเพิ่ม API อีกหนึ่งตัวจะต้องมีการบำรุงรักษาอย่างต่อเนื่อง แต่เมื่อเทียบกับ OpenGL แล้ว สิ่งนี้ไม่ต้องการงานมากนัก ในความเป็นจริง เนื่องจากเราไม่จำเป็นต้องรองรับ OpenGL ES 3 บน iOS อีกต่อไป นั่นหมายความว่าเราสามารถทำให้โค้ด OpenGL บางส่วนที่เราใช้อยู่ให้เรียบง่ายขึ้นได้อีกด้วย

ความเสถียร

วันนี้บน iOS, Metal รู้สึกเสถียรมาก. ผมไม่แน่ใจว่าสถานการณ์เป็นอย่างไรในตอนเปิดตัวในปี 2014 หรือเป็นอย่างไรบน Mac ในวันนี้ แต่ทั้งไดร์เวอร์และเครื่องมือสำหรับ iOS รู้สึกค่อนข้างมั่นคง.

เรามีปัญหาเกี่ยวกับไดรเวอร์หนึ่งกรณีบน iOS 10 ที่เกี่ยวข้องกับการโหลดเชดเดอร์ที่คอมไพล์ด้วย Xcode 7 (ซึ่งเราได้แก้ไขโดยการเปลี่ยนไปใช้ Xcode 8) และไดรเวอร์ล่มหนึ่งกรณีบน iOS 9 ซึ่งปรากฏว่าเกิดจากการใช้งาน API ของ Metal ผิดวิธี (nextDrawable) นอกเหนือจากนี้ เราไม่พบปัญหาพฤติกรรมผิดปกติหรือการล่มใด ๆ สำหรับ API ที่ค่อนข้างใหม่ Metal ถือว่ามีความเสถียรมากในทุกด้าน

นอกจากนี้ เครื่องมือที่คุณได้รับพร้อมกับ Metal มีความหลากหลายและสมบูรณ์; โดยเฉพาะ คุณสามารถใช้:

• เลเยอร์การตรวจสอบความถูกต้องที่ครอบคลุมมาก ซึ่งจะระบุปัญหาทั่วไปในการใช้ API โดยพื้นฐานแล้วมันเหมือนกับการดีบัก Direct3D - ซึ่งคุ้นเคยสำหรับ Direct3D แต่แทบไม่เคยได้ยินใน OpenGL (ในทางทฤษฎี ARB_debug_callback ควรจะแก้ปัญหานี้ได้ แต่ในทางปฏิบัติแล้ว มันมักจะไม่พร้อมใช้งานและเมื่อใช้งานได้ ก็ไม่ค่อยมีประโยชน์มากนัก)
• ตัวดีบัก GPU ที่ใช้งานได้ซึ่งแสดงคำสั่งทั้งหมดที่คุณได้ส่งไปพร้อมกับสถานะของมัน, เนื้อหาของเป้าหมายการレンเดอร์, เนื้อหาของเท็กซ์เจอร์, เป็นต้น ฉันไม่ทราบว่ามันมีตัวดีบักเชดเดอร์ที่ทำงานได้หรือไม่ เพราะฉันไม่เคยต้องการมัน และการตรวจสอบบัฟเฟอร์อาจง่ายขึ้นนิดหน่อย แต่ส่วนใหญ่แล้วมันทำงานได้ดี
• โปรไฟล์ GPU ที่ทำงานได้ซึ่งแสดงสถิติประสิทธิภาพต่อรอบ (เวลา, แบนด์วิดท์) และเวลาการประมวลผลต่อเชดเดอร์ด้วย เนื่องจาก GPU เป็นแบบไทเลอร์ คุณจึงไม่สามารถคาดหวังเวลาการเรียกใช้ต่อครั้งได้แน่นอน การมีระดับการมองเห็นนี้ - โดยเฉพาะเมื่อพิจารณาถึงการขาดข้อมูลการจับเวลา GPU อย่างสมบูรณ์ใน API กราฟิกบน iOS - ถือว่ายอดเยี่ยมมาก
• การติดตามไทม์ไลน์การทำงานของ CPU/GPU (Metal System Trace) ที่แสดงการจัดตารางงานการประมวลผลของ CPU และ GPU (คล้ายกับ GPUView แต่ใช้งานง่ายกว่ามาก) ยกเว้นความแตกต่างบางประการของส่วนติดต่อผู้ใช้
• คอมไพเลอร์เชดเดอร์แบบออฟไลน์ที่ตรวจสอบไวยากรณ์เชดเดอร์ของคุณ ยืนยันความถูกต้อง และให้คำเตือนที่เป็นประโยชน์ในบางครั้ง พร้อมทั้งแปลงเชดเดอร์ของคุณเป็นไฟล์ไบนารีขนาดเล็กที่โหลดได้อย่างรวดเร็วในขณะรัน และได้รับการปรับแต่งประสิทธิภาพไว้ในระดับที่เหมาะสมล่วงหน้า (ช่วยลดเวลาในการโหลด เนื่องจากคอมไพเลอร์ของไดรเวอร์สามารถทำงานได้เร็วกว่า)

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

สรุป

Metal เป็น API ที่ยอดเยี่ยมสำหรับการเขียนโค้ดและพัฒนาแอปพลิเคชัน มันใช้งานง่าย มีประสิทธิภาพที่คาดการณ์ได้ และมีไดรเวอร์ที่แข็งแกร่งพร้อมชุดเครื่องมือที่มั่นคง มันเหนือกว่า OpenGL ในทุกด้านยกเว้นเรื่องความสามารถในการพกพา แต่ในความเป็นจริงแล้ว คุณควรใช้ OpenGL เฉพาะบนสามแพลตฟอร์มเท่านั้น (iOS, Android และ Mac) แพลตฟอร์มสองในจำนวนนั้นตอนนี้รองรับ Metal แล้ว นอกจากนี้ คำสัญญาเรื่องความสามารถในการพกพาของ OpenGL ก็ไม่ได้เป็นจริงมากนัก เนื่องจากโค้ดที่คุณเขียนบนแพลตฟอร์มหนึ่งมักจะไม่สามารถทำงานบนอีกแพลตฟอร์มหนึ่งได้ด้วยเหตุผลที่แตกต่างกัน

หากคุณกำลังใช้เอนจินของบุคคลที่สามเช่น Unity หรือ UE4 Metal ได้รับการสนับสนุนอยู่แล้ว; หากคุณไม่ได้ใช้และคุณชอบการเขียนโปรแกรมกราฟิกหรือให้ความสำคัญกับประสิทธิภาพและจริงจังกับ iOS หรือ Mac ฉันขอแนะนำอย่างยิ่งให้คุณลองใช้ Metal ดู คุณจะไม่มีวันผิดหวัง