เหตุใดความปลอดภัยของเธรดจึงเป็นเรื่องใหญ่สำหรับ Graphics APIs

ทั้ง Vulkan และ DirectX12 นั้นอ้างว่าใช้ได้ในลักษณะที่ปลอดภัยต่อเธรด คนดูเหมือนจะตื่นเต้นกับเรื่องนี้

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

นอกจากนี้ถ้ามันใหญ่มากทำไมมันไม่ได้จนถึงตอนนี้ที่เธรดกราฟิกปลอดภัย API ออกมา

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

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

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

มีงานจำนวนมากที่จำเป็นสำหรับซีพียูในการตั้งค่าเฟรมสำหรับ GPU และชิ้นงานที่ดีนั้นอยู่ในไดรเวอร์กราฟิก ก่อนหน้าที่จะมีการ DX12 / Vulkan งานกราฟิกไดรเวอร์นั้นถูกบังคับให้ต้องทำงานแบบเธรดเดียวด้วยการออกแบบ API

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

ในการอธิบายรายละเอียดเล็กน้อย: ผลลัพธ์ของตัวสร้างเอ็นจิ้นเกมเป็นสตรีมของการเรียกใช้ DX / GL API ที่อธิบายลำดับของการดำเนินการเพื่อแสดงเฟรม อย่างไรก็ตามมีระยะทางที่ยอดเยี่ยมระหว่างสตรีมการเรียกใช้ API และบัฟเฟอร์คำสั่งไบนารีจริงที่ฮาร์ดแวร์ GPU ใช้ ไดรเวอร์ต้อง "รวบรวม" การเรียก API เป็นภาษาเครื่องของ GPU ดังนั้นเพื่อพูด นั่นไม่ใช่กระบวนการที่ไม่สำคัญ - มันเกี่ยวข้องกับการแปลแนวคิด API จำนวนมากไปสู่ความเป็นจริงของฮาร์ดแวร์ระดับต่ำการตรวจสอบเพื่อให้แน่ใจว่า GPU ไม่เคยถูกตั้งค่าเป็นสถานะที่ไม่ถูกต้องการจัดสรรหน่วยความจำและข้อมูลที่ซ้ำกัน แก้ไขคำสั่งระดับต่ำและอื่น ๆ เรื่อย ๆ ไดรเวอร์กราฟิกรับผิดชอบสำหรับสิ่งนี้ทั้งหมด

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

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

แน่นอนว่ามีการเปลี่ยนแปลงอื่น ๆ อีกมากมายใน APIs ใหม่ แต่ตราบใดที่การมัลติเธรดดำเนินไปนั่นเป็นส่วนที่สำคัญที่สุด

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

โดยทั่วไป GPU สมัยใหม่นั้นมีแบ็กเอนด์รวมที่ยืดหยุ่นมากซึ่งสามารถทำงานกับสิ่งต่าง ๆ มากมายในคราวเดียว โดยทั่วไปแล้ว GPU จะทำงานกับจุดยอดและพิกเซลอย่างละเอียด มีความแตกต่างไม่มากนักระหว่างการประมวลผล GPU 1024 จุดยอดในการวาดหนึ่งครั้งและ 512 + 512 จุดยอดในการจับคู่สองแบบที่แตกต่างกัน

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

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

สิ่งนี้เดือดลงไปคือการที่คุณมีงบประมาณสำหรับการโทรวาดซึ่งจะเรียกเก็บค่าใช้จ่ายโดยสิ้นเชิงของคนขับ (ฉันคิดว่าฉันได้ยินมาว่าทุกวันนี้คุณสามารถหลีกเลี่ยงได้ประมาณ 5,000 ต่อเฟรมสำหรับชื่อเรื่อง 60 FPS) คุณสามารถเพิ่มมันได้ในอัตราร้อยละมากโดยการสร้างสตรีมคำสั่งนี้เป็นชิ้น ๆ แบบขนาน

มีเหตุผลอื่นเช่นกัน (ตัวอย่างเช่น timewarp แบบอะซิงโครนัสสำหรับการปรับปรุงเวลาแฝงของ VR) แต่นี่เป็นเกมที่มีขนาดใหญ่สำหรับเกมที่มีกราฟิคผูกไว้และซอฟต์แวร์ drawcall ที่มีน้ำหนักมากอื่น ๆ