ทำไม OpenGL> = 3 อนุญาตให้ VBO เท่านั้น


21

ฉันเห็นว่า OpenGL เวอร์ชัน 3 ขึ้นไปกำจัดการใช้การเรนเดอร์ฝั่งไคลเอ็นต์ โหมดทันทีถูกตัดออกและดูเหมือนว่าจุดสุดยอดจะถูกยกเลิก แต่ถ้าฉันเข้าใจถูกต้อง VBOs เป็นวิธีหลักในการแสดงจุดยอด

ในขณะที่ฉันเห็นตรรกะเบื้องหลังการมีวิธีที่เหมือนกันในการเรนเดอร์ทุกอย่างมันเป็นกรณีที่ VBOs ไม่มีข้อเสียอย่างใหญ่หลวงในอาร์เรย์ของจุดยอดหรือไม่? ฉันคิดว่า VBO ควรจะเป็นบัฟเฟอร์ขนาดใหญ่ที่มีข้อมูล> 1MB โดยทั่วไป ถ้าฉันมีฉากที่มีรูปทรงเรขาคณิตขนาดเล็กกว่ามาก ฉันมีกราฟฉากที่มีโหนดจำนวนมากโดยแต่ละโหนดต้องการการแปลงของตัวเอง ฯลฯ แต่ละโหนดควรสามารถลบแยกต่างหากเพิ่มลงในแบบแยกต่างหากเป็นต้นฉันใช้อาร์เรย์จุดยอดมาก่อน ดังนั้นคำถามแรกของฉันคือถ้าฉันเปลี่ยนเป็น VBOs จะมีค่าใช้จ่ายมากขึ้นในวัตถุกราฟฉากของฉันตอนนี้เพราะ VBO จำเป็นต้องจัดสรรให้กับแต่ละวัตถุ

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

ดังนั้นในรูปแบบที่กระชับยิ่งขึ้นคำถามของฉันคือ:

1) มีค่าใช้จ่ายจำนวนมากในการจัดสรร / ยกเลิกการจัดสรร VBOs (ฉันหมายถึงการตั้งค่าบัฟเฟอร์)

2) ถ้าฉันอัปเดตข้อมูลจากซีพียูทุกเฟรมสิ่งนี้จะแย่กว่าถ้าฉันใช้อาร์เรย์จุดยอดหรือไม่?

และสุดท้ายฉันอยากรู้ว่า:

3) หากคำตอบของคำถามใดคำถามหนึ่งข้างต้นคือ "ใช่" ทำไมเลิกใช้โหมดการแสดงผลอื่นที่อาจมีข้อได้เปรียบเหนือ VBOs มีบางอย่างที่ฉันขาดไปเช่นเทคนิคที่ฉันควรจะใช้เพื่อลดต้นทุนการจัดสรรที่อาจเกิดขึ้นเหล่านี้หรือไม่?

4) คำตอบของคำถามเหล่านี้มีการเปลี่ยนแปลงอย่างมากหรือไม่ขึ้นอยู่กับรุ่น OpenGL ที่ฉันใช้ ถ้าฉัน refactor รหัสของฉันเป็น OpenGL 3 หรือ 4 ไปข้างหน้าเข้ากันได้โดยใช้ VBOs ในทางที่เป็นนักแสดงเทคนิคเดียวกันน่าจะทำงานได้ดีกับ OpenGL 2 หรือเป็นไปได้ว่าเทคนิคบางอย่างเร็วกว่า OpenGL 3 มาก + และอื่น ๆ ด้วย OpenGL 2

ฉันถามคำถามนี้เกี่ยวกับการล้นสแต็ก แต่ฉันกำลังโพสต์ที่นี่อีกครั้งเพราะฉันรู้ว่าไซต์นี้อาจเหมาะสมกว่าสำหรับคำถามของฉัน


1
ทำไมการโหวตปิด มันเป็นงานซ้ำหรือเปล่า? ถ้าเป็นเช่นนั้นฉันจะเห็นลิงค์เพื่อที่จะได้ประโยชน์จากมันได้หรือไม่
Gravity

คำตอบ:


23

มีค่าใช้จ่ายมากมายในการจัดสรร / ยกเลิกการจัดสรร VBOs (ฉันหมายถึงการตั้งค่าบัฟเฟอร์)?

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

หากฉันอัปเดตข้อมูลจาก CPU ทุกเฟรมสิ่งนี้จะแย่กว่าถ้าฉันใช้อาร์เรย์จุดยอดหรือไม่?

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

OpenGL วิกิพีเดียมีบทความดีดีเกี่ยวกับวิธีการสตรีมข้อมูล

หากคำตอบของคำถามข้างต้นคือ "ใช่" ทำไมเลิกใช้โหมดการแสดงผลอื่น ๆ ที่อาจมีข้อได้เปรียบเหนือ VBOs มีบางอย่างที่ฉันขาดไปเช่นเทคนิคที่ฉันควรจะใช้เพื่อลดต้นทุนการจัดสรรที่อาจเกิดขึ้นเหล่านี้หรือไม่?

ครั้งแรกพวกเขาไม่ได้คัดค้าน การเลิกใช้หมายถึงการทำเครื่องหมายสิ่งที่ "จะถูกลบ" ในรุ่นอนาคต พวกเขาถูกคัดค้านใน 3.0 และลบออกใน 3.1 หลักและสูงกว่า

ประการที่สอง ARB ได้อธิบายถึงเหตุผลที่พวกเขานำสิ่งต่าง ๆ ออกจาก OpenGL มันทำให้สเป็คเล็กลงและเรียบง่ายขึ้น มันทำให้ API เล็กลงและคล่องตัวขึ้น มันทำให้การรู้ API ที่คุณควรใช้ง่ายขึ้น 2.1 มี 4 วิธีในการให้ข้อมูลจุดสุดยอด; 3.1+ มี 1. มันกำจัด cruft มากมาย เป็นต้น

คำตอบของคำถามเหล่านี้มีการเปลี่ยนแปลงอย่างมีนัยสำคัญหรือไม่ขึ้นอยู่กับรุ่น OpenGL ที่ฉันใช้ ถ้าฉัน refactor รหัสของฉันเป็น OpenGL 3 หรือ 4 ไปข้างหน้าเข้ากันได้โดยใช้ VBOs ในทางที่เป็นนักแสดงเทคนิคเดียวกันน่าจะทำงานได้ดีกับ OpenGL 2 หรือเป็นไปได้ว่าเทคนิคบางอย่างเร็วกว่า OpenGL 3 มาก + และอื่น ๆ ด้วย OpenGL 2

ไม่มากก็น้อย เฉพาะใน MacOSX คือความแตกต่างระหว่าง 3.1 + แกนและรุ่นก่อน 3.0 อย่างเห็นได้ชัด โปรไฟล์ความเข้ากันได้นั้นมีการใช้งานโดยไดรเวอร์ทั้งหมดสำหรับ Linux และ Windows ดังนั้นคุณสามารถสันนิษฐานได้ว่าโปรไฟล์หลักจากไดรเวอร์เหล่านี้เป็นเพียงการเพิ่มการตรวจสอบเพื่อป้องกันไม่ให้คุณเรียกฟังก์ชั่นความเข้ากันได้

ภายใต้ Mac OSX 10.7 แกน GL 3.2 จะพร้อมใช้งาน แต่ไม่ใช่โปรไฟล์ความเข้ากันได้ ไม่ได้หมายความว่าจะมีความหมายอะไรสำหรับเทคนิคการปฏิบัติงานในที่หนึ่งเทียบกับที่อื่น ๆ แต่หมายความว่าหากมีความแตกต่างนั่นคือแพลตฟอร์มคุณจะเห็นพวกเขา


1
เมื่อคุณเพิ่งโพสต์ข้ามคำถามนี้ฉันจะแค่โพสต์คำตอบของฉัน
Nicol Bolas

ข้อดีอีกประการของการรักษาความรัดกุมของ API คือทำให้ OpenGL API ง่ายต่อการใช้งาน นี่เป็นการพิจารณาครั้งใหญ่ในสเป็คดั้งเดิมของ OpenGL ES
notlesh

@stephelton: เข้าท่า คำถาม "ทำไมถึงคัดค้านทุกอย่าง แต่ VBOs" ของฉันนั้นขึ้นอยู่กับการคิดว่าในขณะที่มันใช้งานได้อย่างสมบูรณ์แบบในการรักษา API แบบลีน แต่ก็ไม่สมเหตุสมผลที่จะเลิกใช้คุณสมบัติที่อาจดีกว่า VBOs สำหรับกรณีการใช้งานหลายกรณี จากสิ่งที่ฉันได้ยินดูเหมือนว่าไม่มีข้อเสียในการใช้ VBOs ดังนั้นจึงเหมาะสมอย่างยิ่งที่จะคัดค้านทุกสิ่ง
แรงดึงดูด

@ แรงโน้มถ่วงคุณไม่จำเป็นต้องใช้ VBO คุณสามารถใช้อาร์เรย์ของจุดยอดเช่นกัน
notlesh

18

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

อาจมีกลอุบายด้านคนขับเพื่อทำให้การจัดสรร temp เร็วขึ้น แต่ไม่มีสิ่งใดที่คุณสามารถทำได้เพื่อหลีกเลี่ยงการคัดลอก

ดังนั้นใช่ตราบใดที่คุณ - และนักพัฒนาโปรแกรมควบคุม - ทำทุกอย่างถูกต้อง VBOs (tm) ควรเร่งความเร็วสิ่งต่าง ๆ เสมอ


6
ฉันชอบคำตอบนี้ดีกว่า มันสั้นลงเรื่อย ๆ จนถึงจุด Imo
TravisG

@JariKomppa: นั่นดูเหมือนคำอธิบายที่สมเหตุสมผลมาก ฉันยังมีข้อกังวลหนึ่งข้อ: VBO ควรจะเป็นวัตถุที่มีขนาดใหญ่พอสมควรซึ่งมักจะจัดสรรเป็นบัฟเฟอร์ขนาด 1MB - 4MB ในครั้งสุดท้ายที่ฉันตรวจสอบ ถ้าวัตถุรูปทรงของฉันไม่ใหญ่ขนาดนั้น แต่ฉันยังคงกังวลเกี่ยวกับประสิทธิภาพเพราะฉันมีวัตถุมากมาย ฉันกังวลว่า VBOs อาจจะเป็นกรณีการใช้งานที่แตกต่างจากที่ฉันมี ฉันควรรวมหลาย ๆ วัตถุเข้าด้วยกันใน VBO เดียวแล้วใช้glDrawRangeElementsในการวาดแต่ละวัตถุหรือว่าไม่มีประสิทธิภาพเช่นเดียวกับจุดสุดยอดอาร์เรย์?
แรงดึงดูด

ฉันสงสัยว่าจะสร้างความแตกต่าง แต่ถ้าคุณรู้สึกว่ามันเป็นความกังวล
Jari Komppa

@JariKomppa: คุณสงสัยในสิ่งที่จะสร้างความแตกต่าง? การใช้glDrawRangeElementsVBO หลายครั้งกับ VBO สองสามตัวแทนที่จะให้แต่ละ VBO เป็นของตัวเอง
แรงดึงดูด

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

9

และอาร์เรย์จุดสุดยอดดูเหมือนจะเลิก แต่ถ้าฉันเข้าใจถูกต้อง

ไม่มาก อาร์เรย์เท็กซ์เป็นรากฐานสำหรับวัตถุบัฟเฟอร์เท็กซ์ เฉพาะที่จัดเก็บข้อมูลที่ถูกย้ายจากไคลเอนต์ไปยังฝั่งเซิร์ฟเวอร์

ถ้าฉันมีฉากที่มีรูปทรงเรขาคณิตขนาดเล็กกว่ามาก

ผสานรูปทรงเรขาคณิตที่เล็กลงให้เป็น VBO ที่ใหญ่ขึ้น ไม่จำเป็นต้องมี VBO หนึ่งชุดต่อชุดรูปทรงเรขาคณิต คุณสามารถระบุส่วนย่อยของ VBO ได้อย่างสมบูรณ์แบบสำหรับการเรนเดอร์ ใช้อ็อฟเซ็ต nonzereo สำหรับพารามิเตอร์ gl … Pointer data

2) ถ้าฉันอัปเดตข้อมูลจากซีพียูทุกเฟรมสิ่งนี้จะแย่กว่าถ้าฉันใช้อาร์เรย์จุดยอดหรือไม่?

สำหรับสิ่งนี้มีการตั้งค่าสถานะการใช้บัฟเฟอร์ GL_DYNAMIC_DRAW และ GL_STREAM_DRAW

หากคำตอบของคำถามข้างต้นคือ "ใช่" ทำไมเลิกใช้โหมดการแสดงผลอื่น ๆ ที่อาจมีข้อได้เปรียบเหนือ VBOs

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

ไม่มีประโยชน์อย่างแน่นอนในการไม่ใช้ VBOs


ดังนั้นโดยทั่วไปแล้วประสิทธิภาพของฉันไม่ควรแย่กว่า VBOs มากกว่ากับอาร์เรย์จุดยอด แต่เฉพาะถ้าฉันตั้งค่าโหมดเป็น GL_STREAM_DRAW อย่างถูกต้องหรือไม่
แรงดึงดูด

@ Gravity: แน่นอน อย่างไรก็ตามโหมดบัฟเฟอร์เป็นเพียงคำใบ้เกี่ยวกับการใช้ที่คาดหวัง แต่แน่นอนว่าคำใบ้ควรเป็นจริงกับสิ่งที่คุณกำลังจะทำ นอกจากนี้อย่าลืมว่าคุณสามารถแมปบัฟเฟอร์ลงในพื้นที่ที่อยู่กระบวนการของคุณสำหรับการอัปเดต (glMapBuffer, glUnmapBuffer)
datenwolf

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

@ Gravity: บัฟเฟอร์สามารถแมปแบบอ่านอย่างเดียวเขียนอย่างเดียวหรืออ่านเขียน สำหรับการอัปเดตที่คุณเลือกเขียนเท่านั้น ตอนนี้มันสำคัญที่ต้องรู้ว่าระบบปฏิบัติการสมัยใหม่จัดการพื้นที่ที่อยู่เสมือนผ่านหน่วยความจำแบบเพจได้อย่างไร ในกรณีของแผนที่เขียนอย่างเดียวคุณจะทำการแมปหน่วยความจำการถ่ายโอน DMA และการเขียนไปยังช่วงที่แมปนั้นจะไปที่หน่วยความจำ GPU โดยตรงหรือมากไปกว่านั้น (เนื้อหาจะถูกเขียนลงใน CPU RAM ก่อน โอน). สิ่งสำคัญคือนี่เป็นเส้นทางโดยตรงมากกว่าถ้าข้อมูลผ่านอาเรย์จุดสุดยอดฝั่งไคลเอ็นต์: หน่วยความจำกระบวนการปกติไม่เหมาะสำหรับ DMA
datenwolf
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.