ภาพรวมโดยย่อของ Vulkan API

แล้ว Vulkan API ใหม่นี้มันสำคัญไฉน และทำไมเราต้องสนใจด้วย

นี่คือ Vulkan API ที่มีความยาวไม่เกินร้อยคำ: เป็น API ที่มีค่าใช้จ่ายต่ำและใกล้เคียงกับโลหะมากสำหรับกราฟิก 3 มิติและแอปพลิเคชันการคำนวณ Vulkan นั้นเป็นรุ่นต่อจาก OpenGL เดิมเรียกว่า "ความคิดริเริ่ม OpenGL รุ่นต่อไป" และรวมถึงชิ้นส่วนและชิ้นส่วนจาก Mantle API ของ AMD Vulkan ควรจะให้ข้อได้เปรียบมากมายเหนือ GPU API อื่น ๆ ทำให้สามารถสนับสนุนข้ามแพลตฟอร์มได้ดีกว่า รองรับโปรเซสเซอร์แบบมัลติเธรดได้ดีขึ้น โหลด CPU ต่ำลง และ OS ที่ไม่เชื่อเรื่องพระเจ้า นอกจากนี้ยังควรทำให้การพัฒนาไดรเวอร์ง่ายขึ้น และอนุญาตให้รวบรวมไดรเวอร์ล่วงหน้า รวมถึงการใช้ shaders ที่เขียนในภาษาต่างๆ

นั่นคือ 93 คำ ดังนั้น หากคุณไม่สนใจ คุณสามารถข้ามไปอีก 3,500 ได้ ในทางกลับกัน หากคุณต้องการทราบข้อมูลเพิ่มเติมเกี่ยวกับกราฟิก API ที่กำลังจะมีขึ้นซึ่งจะอยู่กับเราในอีกหลายปีข้างหน้า ฉันจะเริ่มต้นที่พื้นฐาน

Vulkan API เกิดขึ้นได้อย่างไร

เดิมที Vulkan ได้รับการประกาศโดย Khronos Group ในเดือนมีนาคม 2015 โดยมีกำหนดเปิดตัวอย่างคร่าวๆ ในช่วงปลายปี 2015 ในกรณีที่คุณไม่คุ้นเคยกับ Khronos เป็นกลุ่มอุตสาหกรรมที่ไม่แสวงหาผลกำไรซึ่งก่อตั้งขึ้นเมื่อ 15 ปีที่แล้วโดยชื่อที่ใหญ่ที่สุดบางส่วนใน อุตสาหกรรมกราฟิก รวมถึง ATI (ปัจจุบันเป็นส่วนหนึ่งของ AMD), Nvidia, Intel, Silicon Graphics, Discrete และ Sun Microsystems แม้ว่าคุณจะไม่เคยได้ยินเกี่ยวกับ Khronos มาก่อน แต่คุณคงเคยได้ยินเกี่ยวกับมาตรฐานบางอย่าง เช่น OpenGL, OpenGL ES, WebGL, OpenCL, SPIR, SYCL, WebCL, OpenVX, EGL, OpenMAX, OpenVG, OpenSL ES, StreamInput, COLLADA และ glTF

ถึงตอนนี้ คุณอาจจะคิดว่า “อ๋อ คนๆ นี้แหละ” ดังนั้นฉันจึงสามารถข้ามส่วนแนะนำที่เหลือและมุ่งความสนใจไปที่ API ได้

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

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

ตามทฤษฎีแล้ว Vulkan สามารถใช้ในฮาร์ดแวร์คอมพิวเตอร์แบบคู่ขนาน เพื่อควบคุมแกน GPU หลายหมื่นล้านคอร์ ในอุปกรณ์สวมใส่ขนาดเล็กและโดรนของเล่น ในเครื่องพิมพ์ 3 มิติ รถยนต์ ชุด VR และอื่นๆ เกือบทุกอย่างที่มี GPU ที่เข้ากันได้อยู่ภายใน

สำหรับรายละเอียดเพิ่มเติม เราขอแนะนำให้คุณดูภาพรวมอย่างเป็นทางการของ Vulkan ในรูปแบบ PDF

AMD เสื้อคลุม DNA

หากแนวทางที่ใกล้ชิดกับโลหะฟังดูคุ้น ๆ อย่างน่าขนลุก คุณอาจติดตามการประกาศ GPU ของ AMD ในช่วงสองปีที่ผ่านมาหรือประมาณนั้น AMD สร้างความประหลาดใจให้กับผู้สังเกตการณ์ในอุตสาหกรรมเมื่อมีการประกาศ Mantle API ในปี 2013 และทำให้พวกเขาประหลาดใจอีกครั้งเมื่อตัดสินใจดึงปลั๊กบน API โดยประกาศในเดือนมีนาคม 2015 ว่าจะไม่ปล่อย Mantle 1.0 เป็น SDK สาธารณะ โดยสรุป Mantle สัญญาว่าจะมอบประสิทธิภาพที่สำคัญและการปรับปรุงประสิทธิภาพในบางสถานการณ์ โดยเฉพาะอย่างยิ่งที่ด้านหน้าของ CPU เนื่องจากจะช่วยลดโอเวอร์เฮดในการประมวลผล ฟังดูเหมือนเป็นความคิดที่ดี เนื่องจากนักเล่นเกมสามารถประกอบพีซีแบบกำหนดเองเข้ากับโปรเซสเซอร์ที่ช้ากว่า และลงทุนเงินเพิ่มในการ์ดกราฟิกระดับบนได้ ฟังดูสะดวกมากสำหรับ AMD เช่นกัน เนื่องจากบริษัทไม่มี CPU ระดับไฮเอนด์ที่แข่งขันได้ในช่วงหลายปีที่ผ่านมา แม้ว่าจะยังมีผลิตภัณฑ์ GPU ที่ดีอยู่ก็ตาม

ในขณะที่แฟนบอย AMD ที่ร้องไห้คร่ำครวญรวมตัวกันเพื่อไว้อาลัยต่อการจากไปของผู้ช่วยให้รอด Mantle ก็ฟื้นคืนชีพอย่างอัศจรรย์ ข่าวดีมาในรูปแบบของบล็อกโพสต์ เขียนโดย Raja Koduri รองประธานฝ่าย Visual and Perceptual Computing ของ AMD มีอยู่ครั้งหนึ่งที่ Koduri จัดงานเทศนาบนภูเขาโดยบังเอิญ ตามธีมทางศาสนา ระหว่างงานเปิดตัว AMD ที่ฮาวายในปี 2013 แต่ฉันพูดไม่ออก

พูดเล่นๆ ว่าทีมของ Koduri ทำได้ดีมาก แม้ว่าเสื้อคลุมจะไม่ได้กลายเป็นมาตรฐานใหม่ของอุตสาหกรรม แต่ก็กลายเป็นรากฐานสำหรับวัลแคน ความแตกต่างที่ใหญ่ที่สุดคือ Vulkan จะไม่จำกัดเฉพาะฮาร์ดแวร์ AMD GCN; มันจะทำงานกับ GPU จำนวนมากขึ้นจากผู้ขายหลายราย คุณอาจจะเห็นว่าฉันจะไปกับเรื่องนี้ จะดีกว่าเล็กน้อยที่จะมี API แบบกราฟิกโอเวอร์เฮดเดียวที่ทำงานบนระบบปฏิบัติการและแพลตฟอร์มฮาร์ดแวร์ที่แตกต่างกัน มากกว่าที่จะมี API ที่เป็นกรรมสิทธิ์สำหรับสถาปัตยกรรม GPU ที่แตกต่างกัน ระบบปฏิบัติการ และอื่นๆ

Vulkan API เพียงแค่นำ Mantle pie ชิ้นหนึ่งมาแบ่งปันกับทุกคน โดยไม่คำนึงถึงระบบปฏิบัติการ ฮาร์ดแวร์ เชื้อชาติหรือศาสนา

โอ้และมีอีกสิ่งหนึ่ง: ในที่สุด Mantle ก็บังคับให้ Microsoft และ Khronos ทำอะไรบางอย่างเกี่ยวกับ DirectX และ OpenGL ที่ขยายตัวและไม่มีประสิทธิภาพ มันเป็นลูกเตะที่นุ่มนวลและเป็นมิตรที่ด้านหลังหรือ "ลูกบาดอน" อย่างที่ Toptaler คนหนึ่งชอบพูด

Vulkan เปรียบเทียบกับ OpenGL ได้อย่างไร?

แน่นอน ฉันต้องร่างความแตกต่างพื้นฐานระหว่าง Vulkan และ OpenGL Khronos ได้ภาพประกอบง่ายๆ แสดงให้เห็นว่าคนขับสามารถขจัดปัญหาออกไปได้มากน้อยเพียงใดด้วย API ใหม่

Vulkan อนุญาตให้แอปพลิเคชันเข้าใกล้โลหะมากขึ้น ดังนั้นจึงไม่จำเป็นต้องใช้หน่วยความจำจำนวนมากและการจัดการข้อผิดพลาด ตลอดจนแหล่งที่มาของภาษาแรเงาจำนวนมาก ผู้ขับขี่จะเบาขึ้น เพรียวขึ้น และถ่อมตัวขึ้น Vulkan จะใช้เฉพาะภาษากลาง SPIR-V เท่านั้น และเนื่องจากมี API แบบครบวงจรสำหรับตลาดมือถือ เดสก์ท็อป และคอนโซล จึงควรได้รับความเอาใจใส่จากนักพัฒนาด้วยความรักและอ่อนโยนมากขึ้น

แต่เดี๋ยวก่อน นี่ไม่ใช่แค่การลดภาระงานให้กับนักพัฒนาเกมใช่ไหม แน่นอนว่าพวกเขาจะสามารถใช้ฮาร์ดแวร์ได้อย่างมีประสิทธิภาพมากขึ้น แต่ชั่วโมงการทำงานของพวกเขาเองล่ะ นี่คือจุดที่ระบบนิเวศแบบแบ่งชั้นเข้าสู่การต่อสู้

นักพัฒนาจะสามารถเลือกระดับหรือระดับที่แตกต่างกันสามระดับของระบบนิเวศของ Vulkan

• ใช้ Vulkan โดยตรง เพื่อความยืดหยุ่นและการควบคุมสูงสุด
• ใช้ ไลบรารีและเลเยอร์ ของ Vulkan เพื่อเร่งการพัฒนา
• ใช้ Vulkan ผ่านเอ็นจิ้ นเกมนอกชั้นวางที่ ได้รับการปรับแต่งอย่างเต็มที่เหนือ API ใหม่

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

ตัวเลือกสุดท้ายอาจเป็นตัวเลือกที่ดึงดูดใจมากที่สุด เนื่องจากการยกของหนักได้กระทำโดยบริษัทยักษ์ใหญ่ในอุตสาหกรรม เช่น Unity, Oxide, Blizzard, Epic, EA, Valve และอื่นๆ

นี่คือตาราง OpenGL กับ Vulkan อย่างรวดเร็ว:

พูดตามตรง ฉันไม่คิดว่ามันยุติธรรมเลยที่จะเปรียบเทียบทั้งสองอย่างนี้ Vulkan เป็นอนุพันธ์ของ Mantle ในขณะที่ OpenGL เป็น mastodon ที่มีสัมภาระ 20 ปี วัลแคนควรจะทิ้งสิ่งที่เป็นมรดกไว้มากมาย นั่นคือประเด็นทั้งหมด Vulkan ควรจะปรับปรุงการทดสอบและการใช้งาน ทำให้ไดรเวอร์บางลง และปรับปรุงการพกพาโปรแกรม shader ผ่านภาษาระดับกลาง SPIR-V

สิ่งนี้นำเราไปสู่คำถามต่อไป Vulkan มีความหมายต่อนักพัฒนาอย่างไร?

SPIR-V คาดว่าจะเปลี่ยนระบบนิเวศทางภาษา

SPIR-V เข้ามามีบทบาทที่ไหน และจะเกิดอะไรขึ้นกับ GLSL แบบเก่าที่ดี?

GSLS จะยังคงอยู่ในตอนนี้ และจะเป็นภาษาแรเงาภาษาแรกที่สนับสนุนโดย Vulkan นักแปลจาก GLSL เป็น SPIR-V จะทำงานหนัก และ แย่แล้ว! คุณจะได้ SPIR-V พร้อมที่จะป้อนรันไทม์ของ Vulkan ที่หิวโหย นักพัฒนาเกมจะสามารถใช้ SPIR-V และ Vulkan back-end ได้ ซึ่งอาจต้องอาศัย front-end ของคอมไพเลอร์แบบโอเพนซอร์ส นอกจาก GLSL แล้ว Vulkan สามารถรองรับเคอร์เนล OpenCL C ได้ ในขณะที่กำลังดำเนินการเพิ่มการรองรับสำหรับ C++ ภาษา เฟรมเวิร์ก และเครื่องมือเฉพาะโดเมนในอนาคตเป็นอีกทางเลือกหนึ่ง Khronos กล่าวถึงความเป็นไปได้ในการพัฒนาภาษาทดลองใหม่ๆ

ไม่ว่านักพัฒนาซอฟต์แวร์จะเลือกทำอะไร ถนนทุกสายมุ่งสู่ Vulkan ผ่าน SPIR-V และจากนั้นไปยังอุปกรณ์ต่างๆ มากมาย

SPIR-V ควรปรับปรุงการพกพาในสามวิธี:

• เครื่องมือที่ใช้ร่วมกัน
• ชุดเครื่องมือเดียวสำหรับ ISV . เดียว
• ความเรียบง่าย

เนื่องจากจะไม่มีความจำเป็นที่ทุกแพลตฟอร์มฮาร์ดแวร์จะต้องมีเครื่องมือแปลภาษาระดับสูง นักพัฒนาจึงจะจัดการกับพวกเขาน้อยลง

ISV แต่ละรายการสามารถสร้าง SPIR-V ได้โดยใช้ชุดเครื่องมือเดียว ซึ่งช่วยขจัดปัญหาการพกพาของภาษาระดับสูง

SPIR-V นั้นง่ายกว่าภาษาระดับสูงทั่วไป ทำให้การใช้งานและการประมวลผลง่ายขึ้น

ประสิทธิภาพจะได้รับการปรับปรุงในหลายวิธี ขึ้นอยู่กับวิธีการใช้งาน Vulkan:

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

Khronos ไม่ได้ระบุหมายเลขประสิทธิภาพใด ๆ และหมายเหตุว่า "ระยะทางจะแตกต่างกันไปอย่างแน่นอน" ทุกอย่างจะขึ้นอยู่กับวิธีการใช้วัลแคน หากคุณต้องการตรวจสอบรายละเอียดที่สำคัญ อย่าลืมตรวจสอบเอกสารไวท์เปเปอร์ SPIR-V

Vulkan ดูมีความหวังจากมุมมองของนักพัฒนา

ฉันได้สรุปคุณสมบัติจำนวนหนึ่งที่ควรทำให้ Vulkan และ SPIR-V เป็นที่นิยมในชุมชนนักพัฒนา และ Khronos ก็กระตือรือร้นที่จะเข้าใจประเด็นนี้เช่นกัน โอกาสในการใช้เครื่องมือและทักษะเดียวกันในการพัฒนาหลายแพลตฟอร์มดูน่าสนใจ โดยเฉพาะอย่างยิ่งตอนนี้ที่ช่องว่างด้านประสิทธิภาพระหว่างแพลตฟอร์มต่างๆ กำลังปิดลง

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

Khronos สรุปข้อดีต่อไปนี้ที่เป็นไปได้โดย SPIR-V:

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

ฉันแน่ใจว่าคุณจะเห็นด้วยว่าสิ่งนี้ฟังดูดี แต่ก็ยังมีทางยาวไกล

Vulkan: ใช้งานได้ แต่อยู่ในระหว่างดำเนินการ

อย่างที่ฉันพูดไป Vulkan ยังคงเป็นงานที่กำลังดำเนินการอยู่ และเราควรจะมีสเปกเต็มรูปแบบภายในสิ้นปีนี้ อย่างไรก็ตาม จากสิ่งที่เราได้เห็นจนถึงตอนนี้ API ใหม่สามารถปลดล็อกประสิทธิภาพได้ มากมาย แม้กระทั่งกับฮาร์ดแวร์รุ่นปัจจุบัน

ภาพประกอบที่ดีที่สุดของ Vulkan ที่ฉันเคยเห็นมานั้นมาจาก Imagination Technologies ซึ่งเป็นหนึ่งใน GPU สำหรับอุปกรณ์พกพาชั้นนำ Imagination Technologies GPU IP ใช้ในอุปกรณ์ iOS ทั้งหมด พร้อมกับการออกแบบ System-on-Chip ที่ใช้ ARM อื่นๆ อีกมากมาย และแม้แต่ในชิป Intel x86 แรงดันต่ำบางรุ่น

เมื่อสัปดาห์ที่แล้ว Imagination ได้เผยแพร่บล็อกโพสต์ที่มีรายละเอียดเกี่ยวกับประสิทธิภาพที่เพิ่มขึ้นของ Vulkan การเลือกฮาร์ดแวร์ค่อนข้างแปลก: Google Nexus Player ซึ่งใช้โปรเซสเซอร์ Intel quad-core ที่ไม่ค่อยได้ใช้พร้อม PowerVR G6430 GPU อุปกรณ์ได้รับการทดสอบด้วยไดรเวอร์ Vulkan API ล่าสุดสำหรับ PowerVR GPU ในขณะที่ดำเนินการอ้างอิงบน OpenGL ES 3.0 ช่องว่างด้านประสิทธิภาพนั้นไม่น่าตกใจ

ฉากนี้มีวัตถุทั้งหมด 400,000 ชิ้น โดยมีรายละเอียดระดับต่างๆ ตั้งแต่จุดยอด 13,000 ถึง 300 จุด ภาพมุมกว้างแสดงรูปสามเหลี่ยมประมาณหนึ่งล้านรูป ค่าอัลฟาบางส่วนบนต้นไม้ และพื้นผิวที่แตกต่างกันประมาณสิบแบบสำหรับโนมส์และต้นไม้ แต่ละประเภทวัตถุใช้ shader ที่แตกต่างกัน และ gnomes ไม่ได้ถูกอินสแตนซ์ การเรียกแต่ละครั้งอาจเป็นวัตถุที่แตกต่างกันโดยสิ้นเชิง ด้วยวัสดุที่แตกต่างกัน แต่ผลลัพธ์ที่ได้จะคล้ายกัน

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

Vulkan ลดการใช้ CPU ได้อย่างไร?

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

ด้วยเหตุนี้ OpenGL ES จึงจำเป็นต้องเรียกใช้โหมดเคอร์เนลหลายครั้งเพื่อเปลี่ยนสถานะของไดรเวอร์และตรวจสอบความถูกต้อง วัลแคนไม่ได้ใช้งานเพราะอาศัยคำสั่งที่สร้างไว้ล่วงหน้า (บัฟเฟอร์คำสั่ง) เพื่อลดโอเวอร์เฮดของ CPU และขจัดความจำเป็นในการตรวจสอบหรือคอมไพล์ในระหว่างการวนรอบการแสดงผล ทีม Imagination อธิบายความสามารถในการนำบัฟเฟอร์คำสั่งกลับมาใช้ใหม่ว่า "มีประโยชน์ในบางสถานการณ์" และเป็นไปได้ที่จะใช้ "ในระดับที่ดี" ในเกมและแอปพลิเคชันต่างๆ มากมาย

ตัวเปลี่ยนเกมตัวที่สองคือ การสร้างบัฟเฟอร์คู่ขนาน ซึ่งช่วยให้ Vulkan สามารถควบคุมพลังของคอร์ CPU ทั้งหมดได้ OpenGL ES ได้รับการออกแบบก่อนการมาถึงของชิปมือถือแบบมัลติคอร์ แต่ในช่วงสามปีที่ผ่านมา อุตสาหกรรมได้เปลี่ยนจากสอง ไปสี่ เป็นแปดและสิบคอร์ของ CPU ด้วย SoC ซีรีส์ A ของ Apple และ Nvidia Tegra ในเดนเวอร์ ชิปเป็นข้อยกเว้นที่โดดเด่นเพียงอย่างเดียว ฉันได้พูดคุยเกี่ยวกับแนวโน้ม SoC บนมือถือในหนึ่งในบล็อกก่อนหน้าของฉัน ซึ่งครอบคลุมคอมไพเลอร์ Optimizing Android ที่กำลังจะมีขึ้น เพื่อให้คุณสามารถตรวจสอบข้อมูลเพิ่มเติมได้

มาลองเปรียบเทียบกัน: หาก Vulkan เป็นเครื่องยนต์สันดาปภายใน มันก็จะจัดเก็บและนำกำลังของมันกลับมาใช้ใหม่ เช่นเดียวกับที่เทอร์โบชาร์จเจอร์และอินเตอร์คูลเลอร์ (command buffers) และมันจะสามารถใช้ได้สี่ หก แปดหรือสิบกระบอกสูบโดยไม่สูญเสียประสิทธิภาพ (การสร้างบัฟเฟอร์คู่ขนาน) การเปรียบเทียบ Vulkan กับ OpenGL ES ฟังดูคล้ายกับการเปรียบเทียบเครื่องยนต์เทอร์โบตัวใหม่ที่ลดขนาดลงกับเครื่องยนต์สูบเดียวแบบเก่าใน Triumph Trophy ของคุณปู่ของคุณ

อย่างน้อยคุณปู่ก็เป็นร็อคเกอร์ที่ดี ไม่ใช่ม็อด

ผลลัพธ์ที่ได้คือสภาพแวดล้อมที่มีประสิทธิภาพมากขึ้นอย่างมาก สามารถนำฮาร์ดแวร์ที่มีอยู่ทั้งหมดไปใช้งานได้ดี ซึ่งแตกต่างจาก OpenGL ES ซึ่งผูกกับ CPU ในสถานการณ์ส่วนใหญ่ ซึ่งหมายความว่า Vulkan สามารถส่งมอบประสิทธิภาพในระดับที่ใกล้เคียงกันในขณะที่รักษา CPU ไว้ที่นาฬิกาที่ต่ำกว่า ซึ่งช่วยลดการใช้พลังงานและการควบคุมปริมาณ

ข้อเสียของ Vulkan API ที่เป็นไปได้ (การแจ้งเตือนสปอยเลอร์: มีไม่มากนัก)

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

• เพิ่มความซับซ้อนของโค้ดในบางสถานการณ์
• เวลาไปตลาด
• ระดับการสนับสนุนอุตสาหกรรม
• Vulkan อาจไม่เกี่ยวข้องหรือมีประสิทธิภาพในบางแพลตฟอร์ม (เดสก์ท็อป)
• โน้มน้าวนักพัฒนาให้ใช้ Vulkan บนบางแพลตฟอร์ม
• ความเข้ากันได้จำกัดกับฮาร์ดแวร์รุ่นเก่า

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

เวลาในการออกสู่ตลาดเป็นอีกข้อกังวล เช่นเดียวกับการนำ Vulkan ไปใช้ในแอปและเกมรุ่นเก่า วัลแคนยังคงเป็นตัวอย่างทางเทคนิค คาดว่าข้อกำหนดเบื้องต้นและการใช้งานจริงภายในสิ้นปี 2558 ดังนั้นตามความเป็นจริง เราอาจไม่เห็นการใช้งานจริงจำนวนมากก่อนกลางปี ​​2559

การสนับสนุนอุตสาหกรรมไม่ควรเป็นปัญหา ท้ายที่สุด นี่คือมาตรฐานของโครนอส แต่อาจใช้เวลาสักครู่ นั่นเป็นหนึ่งในเหตุผลที่ฉันเน้นโพสต์นี้ในส่วนอุปกรณ์เคลื่อนที่ ซอฟต์แวร์และฮาร์ดแวร์สำหรับอุปกรณ์พกพามีวิวัฒนาการเร็วขึ้น และอาจต้องใช้เวลาอีกสองสามไตรมาสก่อนที่เราจะเห็น Vulkan สร้างผลกระทบต่อแพลตฟอร์มเดสก์ท็อป นั่นเป็นเพียงวิธีการทำงานของอุตสาหกรรม ยังมีอีกหลายสิ่งที่ต้องกังวลในช่องเดสก์ท็อป: การสนับสนุนแอปพลิเคชันระดับมืออาชีพ ฝูงเกมเมอร์ที่ควงโกยโกยตีกันบนทุกเฟรมที่ขาด และอื่นๆ อย่างไรก็ตาม ข้อเท็จจริงที่ว่า Vulkan ได้มาจาก Mantle ของ AMD นั้นเป็นสิ่งที่น่ายินดี

ในขณะที่ Vulkan สามารถทำสิ่งมหัศจรรย์ในการตั้งค่าที่ผูกกับ CPU โดยเฉพาะอย่างยิ่งกับ SoC มือถือแบบมัลติคอร์ ประสิทธิภาพที่เพิ่มขึ้นเหล่านี้จะถูกจำกัดบนแพลตฟอร์มเดสก์ท็อป เดสก์ท็อปรองรับโปรเซสเซอร์แบบ multi-core ด้วยระดับประสิทธิภาพที่มากขึ้น

นักพัฒนาบางคนอาจไม่เต็มใจที่จะลงมือและยุ่งกับ Vulkan จนกว่าปริศนาทุกชิ้นจะเข้าที่ ผู้คนจำนวนมากไม่มีเวลาทำการทดลอง และพวกเขาเรียนรู้ทักษะใหม่ๆ เมื่อจำเป็นเท่านั้น เสียเงินจำนวนมากและเสียเวลาทำงานเพื่อปรับแต่งเกมมือถือที่มีอยู่เพื่อใช้ Vulkan ในระยะแรกนี้จะไม่เป็นตัวเลือกสำหรับนักพัฒนาและผู้เผยแพร่จำนวนมาก

ความเข้ากันได้กับฮาร์ดแวร์รุ่นเก่าอาจเป็นอีกสาเหตุหนึ่งที่น่ากังวล Vulkan จะต้องใช้ฮาร์ดแวร์ OpenGL ES 3.1 หรือ OpenGL 4.1 พร้อมด้วยไดรเวอร์ใหม่ ตัวอย่างเช่น GPU PowerVR ซีรีส์ 6 ของ Imagination Technologies สามารถรองรับได้ แต่ซีรีส์ 5 ไม่รองรับ Adreno 400 series ของ Qualcomm รองรับ OpenGL ES 3.1 แต่ 300 series ไม่รองรับ Mali T600- และ T700-series ของ ARM รองรับ OpenGL ES 3.1 แต่ขาดการรองรับในการออกแบบ T400-series รุ่นเก่า โชคดีที่เมื่อถึงเวลาที่ Vulkan จะมีความเกี่ยวข้อง อุปกรณ์ส่วนใหญ่ที่มี GPU ที่ไม่รองรับจะไม่ปรากฏให้เห็น ซึ่งรวมถึง iPhone 5/5C, iPad รุ่นที่สี่ และอุปกรณ์ Samsung ที่ใช้ชิป Exynos ซีรีส์ 5000 บางรุ่น อุปกรณ์ที่ใช้ Qualcomm อาจไม่โชคดีเท่า Adreno 300-series GPUs ใช้กับการออกแบบที่ค่อนข้างใหม่และมีประสิทธิผลเช่น Snapdragon 410, Snapdragon 600, Snapdragon 800 และ 801 อย่างไรก็ตามฉันสงสัยว่าส่วนใหญ่จะหายไปตามเวลา วัลแคนมีความเกี่ยวข้องอย่างแท้จริง

อยู่นานและแสดงผล

มันยังเร็วเกินไปที่จะบอกว่า Vulkan จะเป็นผู้เปลี่ยนเกมหรือไม่ แต่ฉันคิดว่าคุณจะเห็นด้วยว่ามันมีศักยภาพมากมาย ฉันคิดว่ามันจะเป็นเรื่องใหญ่ และฉันก็ตั้งสมมติฐานนั้นจากประสบการณ์กว่าทศวรรษที่ครอบคลุมอุตสาหกรรม GPU อย่างไรก็ตาม มันต้องใช้เวลา และฉันสงสัยว่า Vulkan จะแสดงตัวตนของมันในอุปกรณ์พกพาก่อนที่มันจะเริ่มเปลี่ยนแนวเดสก์ท็อป

ในเวลาเดียวกัน ไดรเวอร์ เอ็นจิ้นเกม และเกมที่ปรับให้เหมาะกับ Vulkan เราจะมีฮาร์ดแวร์ใหม่ให้ใช้งาน และฉันไม่ได้หมายถึงแค่การปรับแต่งฮาร์ดแวร์เพียงเล็กน้อยเท่านั้น การพัฒนา Mobile SoC หยุดชะงักด้วยเหตุผลหลายประการที่ฉันจะไม่ลงมือทำในตอนนี้ แต่ปี 2016 จะเป็นปีที่ยิ่งใหญ่สำหรับอุตสาหกรรมนี้ เนื่องจากโหนด FinFET ขนาด 14/16 นาโนเมตรจะพร้อมใช้งานสำหรับผู้ผลิตจำนวนมากขึ้น และกลายเป็นสิ่งที่คุ้มค่าในเชิงเศรษฐกิจสำหรับฮาร์ดแวร์กระแสหลักมากกว่า ชิปเรือธง

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