รายการที่แสดงเป็นคุณลักษณะ OpenGL ที่ตามทฤษฎีแล้วสามารถเร่งส่วนใดส่วนหนึ่งของ API โดยการจัดเก็บกลุ่มคำสั่งเพื่อใช้ในภายหลัง ในความเข้าใจของฉันมันมีเหตุผลมากมายเกี่ยวกับความพยายามในปัจจุบันเพื่อลดค่าใช้จ่ายของผู้ขับขี่
รายการที่แสดงถูกคัดค้านในเวอร์ชัน 3.1 แม้ว่า API สมัยใหม่เทียบเท่าอะไรและ DirectX เปิดเผยคุณลักษณะที่คล้ายกัน หากไม่มีฟังก์ชั่นดังกล่าวอีกต่อไปเหตุผลคืออะไร?
คำตอบ:
Nvidia มีส่วนขยายสำหรับการสร้างบัฟเฟอร์คำสั่งใน GL
เหตุผลที่ไม่มีฟังก์ชั่นที่คล้ายกันคือมีสถานะที่เกี่ยวข้องมากมายเกี่ยวกับวิธีการเรนเดอร์และรายการแสดงผลได้รับผลกระทบจากสถานะต่าง ๆ มากมาย ตัวอย่างเช่นการเปลี่ยนสถานะการผสมผสานต้องมีการแพทช์ส่วนย่อยบนฮาร์ดแวร์บางตัว
NVidia แก้ไขได้โดยการจับภาพทุกสถานะและย้ายไปที่สถานะหลังจากส่ง:
1) แรงบันดาลใจในการออกแบบคืออะไร?
เป้าหมายหลักคือเพื่อให้สามารถใช้บัฟเฟอร์คำสั่งที่ได้รับการตรวจสอบล่วงหน้า API และข้อเสนออื่น ๆ ได้กล่าวถึงเรื่องนี้ด้วยการแปลงรายการคำสั่งหรือวัตถุสถานะต่าง ๆ แต่ปัญหาที่เกิดขึ้นซ้ำ ๆ ก็คือการมีปฏิสัมพันธ์ระหว่างขั้นตอนต่าง ๆ ของไปป์ไลน์ป้องกันไม่ให้เกิดการแพร่กระจายและนำกลับมาใช้ซ้ำ การโต้ตอบเหล่านี้มักจะเฉพาะฮาร์ดแวร์ (และแตกต่างจากผู้ขายไปยังผู้ขายหรือแม้กระทั่งรุ่นต่อรุ่น) และการโต้ตอบใหม่ถูกนำเสนอโดยคุณสมบัติใหม่ที่ไม่ได้จินตนาการเมื่อรูปแบบ prevalidation ถูกเสนอ
เราพยายามที่จะแก้ไขปัญหานี้ด้วยการมีวัตถุสถานะเสาหินที่ครอบคลุม (เกือบ) สถานะทั้งหมดของไปป์ไลน์ สิ่งนี้ควรให้ข้อมูลที่เพียงพอสำหรับการนำไปใช้ทั้งหมดเพื่อทำการตรวจสอบข้ามสิ่งที่จำเป็น เราพยายามสร้างสิ่งเหล่านี้ในลักษณะที่ช่วยลดการปล่อย API ใหม่ - เนื่องจากเราต้องการสถานะทั้งหมด (รวมถึงการเพิ่มใด ๆ ในอนาคต) เราเพิ่งจับภาพจากสถานะปัจจุบันของบริบท
[ ... ]
23) สถานะอะไรที่เหลืออยู่ซึ่งแก้ไขโดยโทเค็นหลังจากการเรียกใช้การจัดส่ง
แก้ไขแล้ว: สถานะถูกรีเซ็ต
(จากข้อความส่วนขยายที่ลิงก์ด้านบน)
อย่างไรก็ตามตัวตายตัวแทนที่แท้จริงคือฟังก์ชันบัฟเฟอร์คำสั่งใน DX12 และ vulkan สิ่งเหล่านี้จะดักจับสถานะการเรนเดอร์ทั้งหมดไว้ในวัตถุเดียวที่จะใช้เมื่อสร้างและเติมบัฟเฟอร์คำสั่ง ส่วนขยายของ NVidia นั้นขึ้นอยู่กับสถาปัตยกรรมนั้นอันเป็นผลมาจากการมีส่วนร่วมของ NVidia ในการออกแบบ Vulkan