Tại sao OpenGL> = 3 chỉ cho phép VBO?


21

Tôi thấy rằng OpenGL phiên bản 3 trở lên loại bỏ việc sử dụng kết xuất phía máy khách. Chế độ ngay lập tức đã bị loại bỏ và các mảng đỉnh dường như không được chấp nhận. Thay vào đó, nếu tôi hiểu chính xác, VBO là cách chính để kết xuất các đỉnh.

Mặc dù tôi thấy logic đằng sau việc có một cách thống nhất để hiển thị mọi thứ, nhưng đó có phải là trường hợp VBO không có nhược điểm lớn so với mảng đỉnh? Tôi nghĩ rằng VBO được cho là bộ đệm lớn chứa> 1 MB dữ liệu, nói chung. Nếu tôi có một cảnh có nhiều hình học nhỏ hơn thì sao? Tôi có một biểu đồ cảnh với số lượng lớn các nút, mỗi nút cần biến đổi riêng, v.v ... Mỗi nút cũng có thể được xóa riêng, thêm vào riêng, v.v. Tôi đã sử dụng mảng đỉnh trước đó. Vì vậy, câu hỏi đầu tiên của tôi là liệu, nếu tôi chuyển sang VBO, sẽ có một chi phí lớn hơn cho các đối tượng biểu đồ cảnh của tôi bây giờ vì VBO cần được phân bổ cho từng đối tượng.

Một mối quan tâm khác là hình học mà tôi kết xuất có thể rất năng động. Trong trường hợp xấu nhất, có thể đôi khi tất cả hình học cần phải bực bội mọi khung hình trong một khoảng thời gian. Các VBO sẽ có hiệu suất kém hơn các mảng đỉnh trong trường hợp sử dụng này hay các VBO tồi tệ nhất có hoạt động nhiều như các mảng đỉnh nhưng không còn nữa không?

Vì vậy, trong định dạng ngắn gọn hơn, câu hỏi của tôi là:

1) Có chi phí đáng kể để phân bổ / phân bổ VBO không (ý tôi là hành động đơn thuần là thiết lập bộ đệm)?

2) Nếu tôi đang cập nhật dữ liệu từ CPU mọi khung hình, điều này có thể tệ hơn đáng kể so với việc tôi đã sử dụng mảng đỉnh không?

Và cuối cùng, tôi muốn biết:

3) Nếu câu trả lời cho một trong các câu hỏi trên là "có", tại sao lại từ chối các chế độ kết xuất khác có thể có lợi thế hơn VBO? Có điều gì tôi đang thiếu ở đây, như các kỹ thuật tôi phải sử dụng để giảm thiểu một số chi phí phân bổ tiềm năng này, v.v.?

4) Các câu trả lời cho bất kỳ câu hỏi nào trong số này có thay đổi đáng kể tùy thuộc vào phiên bản OpenGL nào tôi đang sử dụng không? Nếu tôi cấu trúc lại mã của mình để tương thích với OpenGL 3 hoặc 4 bằng cách sử dụng VBO theo cách hiệu quả, thì các kỹ thuật tương tự sẽ có khả năng hoạt động tốt với OpenGL 2 hoặc có khả năng các kỹ thuật nhất định nhanh hơn nhiều với OpenGL 3 + và những người khác với OpenGL 2?

Tôi đã hỏi câu hỏi này về stack overflow, nhưng tôi đang đăng lại ở đây vì tôi nhận ra trang web này có thể phù hợp hơn cho câu hỏi của tôi.


1
Tại sao một cuộc bỏ phiếu để đóng cửa? Có phải là một bản sao? Nếu vậy, tôi có thể thấy một liên kết để tôi có thể hưởng lợi từ nó không?
Trọng lực

Câu trả lời:


23

Có một chi phí đáng kể để phân bổ / phân bổ VBO (ý tôi là hành động đơn thuần là thiết lập bộ đệm)?

Xác định "đáng kể." Nói chung là không nên tạo ra chúng ở giữa các khung; chúng nên được thiết lập trong quá trình khởi tạo hoặc bất cứ nơi nào. Nhưng điều này đúng với hầu hết các đối tượng OpenGL, như kết cấu, kết xuất đồ họa hoặc trình đổ bóng.

Nếu tôi đang cập nhật dữ liệu từ CPU mọi khung hình, điều này có thể tệ hơn đáng kể so với việc tôi đã sử dụng mảng đỉnh không?

Có thể không Vâng. OpenGL xác định chức năng, không phải hiệu suất . Bạn thực sự có thể làm cho mọi thứ chậm hơn nhiều. Hoặc bạn có thể làm mọi thứ nhanh hơn. Tất cả phụ thuộc vào cách bạn sử dụng nó.

OpenGL Wiki có một bài viết hay về cách truyền dữ liệu đúng cách .

Nếu câu trả lời cho một trong những câu hỏi trên là "có", tại sao lại từ chối các chế độ kết xuất khác có thể có lợi thế hơn VBO? Có điều gì tôi đang thiếu ở đây, như các kỹ thuật tôi phải sử dụng để giảm thiểu một số chi phí phân bổ tiềm năng này, v.v.?

Đầu tiên, họ không bị phản đối. Khấu hao có nghĩa là đánh dấu một cái gì đó là "sẽ được loại bỏ" trong các phiên bản trong tương lai. Chúng không được dùng nữa trong 3.0 và được loại bỏ trong lõi 3.1 trở lên.

Thứ hai, ARB thường giải thích lý do họ xóa nội dung khỏi OpenGL. Nó làm cho thông số kỹ thuật nhỏ hơn và đơn giản hơn. Nó làm cho API nhỏ hơn và hợp lý hơn. Nó giúp dễ dàng hơn để biết những API nào bạn nên sử dụng; 2.1 có 4 cách để cung cấp dữ liệu đỉnh; 3.1+ có 1. Nó được loại bỏ rất nhiều hành trình. V.v.

Các câu trả lời cho bất kỳ câu hỏi nào trong số này có thay đổi đáng kể tùy thuộc vào phiên bản OpenGL nào tôi đang sử dụng không? Nếu tôi cấu trúc lại mã của mình để tương thích với OpenGL 3 hoặc 4 bằng cách sử dụng VBO theo cách hiệu quả, thì các kỹ thuật tương tự sẽ có khả năng hoạt động tốt với OpenGL 2 hoặc có khả năng các kỹ thuật nhất định nhanh hơn nhiều với OpenGL 3 + và những người khác với OpenGL 2?

Nhiều hay ít không. Chỉ có trên MacOSX là sự khác biệt giữa phiên bản 3.1 + core và pre-3.0 thực sự rõ ràng. Cấu hình tương thích được triển khai bởi tất cả các trình điều khiển cho Linux và Windows, vì vậy bạn có thể giả sử rằng cấu hình cốt lõi từ các trình điều khiển này thực sự chỉ là thêm kiểm tra để ngăn bạn gọi các chức năng tương thích.

Trong Mac OSX 10.7, lõi GL 3.2 có sẵn, nhưng không có cấu hình tương thích. Điều đó không nhất thiết có nghĩa là bất cứ điều gì cho các kỹ thuật hiệu suất trên một so với nhau. Nhưng nó có nghĩa là nếu có sự khác biệt, đó là nền tảng bạn sẽ thấy chúng trên.


1
Vì bạn vừa đăng chéo câu hỏi này , tôi sẽ chỉ đăng chéo câu trả lời của tôi.
Nicol Bolas

Một ưu điểm khác của việc giữ cho API ngắn gọn là nó giúp API OpenGL dễ thực hiện hơn. Đây là một sự cân nhắc lớn trong thông số kỹ thuật OpenGL ES ban đầu.
thịt

@stephelton: Làm cho ý nghĩa. Câu hỏi "tại sao không tán thành tất cả mọi thứ trừ VBO" của tôi dựa trên suy nghĩ rằng mặc dù nó hoàn toàn hợp lý để giữ cho API gọn gàng, nhưng không có ý nghĩa gì để loại bỏ các tính năng có thể tốt hơn VBO cho nhiều trường hợp sử dụng. Từ những gì tôi nghe được, có vẻ như không có bất lợi nào khi sử dụng VBO, do đó, nó hoàn toàn hợp lý để loại bỏ mọi thứ khác.
Trọng lực

@gravity Bạn không cần phải sử dụng VBO. Bạn có thể sử dụng một loạt các đỉnh là tốt.
thịt

18

Cách OpenGL hoạt động, bất cứ khi nào bạn sử dụng dữ liệu không phải VBO, trình điều khiển phải tạo một bản sao của dữ liệu đó - thực tế là tạo VBO tạm thời - vì không có gì ngăn cản bạn sửa đổi mảng trần trong không gian người dùng giữa các cuộc gọi thành OpenGL.

Có thể có một số mánh khóe phía trình điều khiển để phân bổ tạm thời nhanh hơn, nhưng bạn không thể làm gì để tránh sao chép.

Vì vậy, miễn là bạn - và các nhà phát triển trình điều khiển - làm mọi thứ đúng, VBO nên (tm) luôn luôn tăng tốc mọi thứ.


6
Tôi thích câu trả lời này tốt hơn. Nó ngắn hơn và đi sâu hơn vào vấn đề, imo.
TravisG

@JariKomppa: Nghe có vẻ như là một lời giải thích rất hợp lý. Tôi vẫn có một mối quan tâm: VBO được cho là các đối tượng lớn một cách hợp lý, thường được phân bổ là bộ đệm 1MB - 4MB lần trước tôi đã kiểm tra. Điều gì xảy ra nếu các đối tượng hình học của tôi không lớn như vậy, nhưng tôi vẫn quan tâm đến hiệu suất vì tôi có nhiều đối tượng? Tôi lo lắng VBO có thể chỉ dành cho một trường hợp sử dụng khác với những gì tôi có. Tôi có nên gộp nhiều đối tượng lại với nhau trong một VBO đơn và sau đó sử dụng glDrawRangeElementsđể vẽ từng đối tượng riêng lẻ không, hay nó không hiệu quả giống như các mảng đỉnh?
Trọng lực

Tôi nghi ngờ điều đó sẽ làm cho bất kỳ sự khác biệt, nhưng nếu bạn cảm thấy đó là một mối quan tâm, điểm chuẩn nó.
Jari Komppa

@JariKomppa: Bạn nghi ngờ điều gì sẽ tạo nên sự khác biệt? Sử dụng glDrawRangeElementsnhiều lần trên mỗi VBO với một vài VBO thay vì cho mỗi đối tượng VBO của riêng mình?
Trọng lực

1
Chính xác. Tôi nghi ngờ bạn sẽ thấy nhiều sự khác biệt ở đó, nhưng hồ sơ một số trường hợp thử nghiệm sẽ cung cấp cho bạn thêm thông tin. Bây giờ tôi cũng không lo lắng về điều đó, vì một sự thay đổi như thế có thể được áp dụng sau này nếu cần.
Jari Komppa

9

và mảng đỉnh dường như không được dùng nữa. Thay vào đó, nếu tôi hiểu chính xác,

Không hẳn. Mảng Vertex là nền tảng cho các đối tượng bộ đệm đỉnh. Chỉ lưu trữ được chuyển từ máy khách sang phía máy chủ.

Nếu tôi có một cảnh có nhiều hình học nhỏ hơn thì sao?

Hợp nhất các bộ hình học nhỏ hơn thành các VBO lớn hơn. Không cần phải có một VBO cho mỗi lô hình học. Bạn hoàn toàn có thể giải quyết các tập hợp con của VBO để kết xuất. Sử dụng phần bù nonz bd cho tham số dữ liệu con trỏ gl.

2) Nếu tôi đang cập nhật dữ liệu từ CPU mọi khung hình, điều này có thể tệ hơn đáng kể so với việc tôi đã sử dụng mảng đỉnh không?

Đối với điều này, có các cờ sử dụng bộ đệm GL_DYNAMIC_DRAW và GL_STREAM_DRAW.

Nếu câu trả lời cho một trong những câu hỏi trên là "có", tại sao lại từ chối các chế độ kết xuất khác có thể có lợi thế hơn VBO?

Vì không có lợi thế. Dữ liệu hình học phải được chuyển đến GPU trong mọi trường hợp. Sử dụng mảng đỉnh phía máy khách thông thường vẫn sẽ gây ra chuyển DMA sang GPU và chế độ ngay lập tức sẽ tạo một lô để chuyển trước.

Hoàn toàn không có lợi ích gì khi không sử dụng VBO.


Vì vậy, hiệu suất của tôi thường không tệ hơn với các VBO so với các mảng đỉnh, nhưng chỉ khi tôi đặt chính xác chế độ thành GL_STREAM_DRAW?
Trọng lực

@Gravity: Thật vậy. Tuy nhiên, chế độ bộ đệm chỉ là một gợi ý về việc sử dụng được mong đợi, nhưng tất nhiên gợi ý đó phải đúng với những gì bạn sẽ làm. Cũng đừng quên rằng bạn có thể ánh xạ bộ đệm vào không gian địa chỉ quy trình của mình để cập nhật (glMapBuffer, glUnmapBuffer).
datenwolf

Nhưng sau đó, bộ đệm không thể có trong VRAM, phải không? Hoặc nó vẫn sẽ ở trong VRAM nhưng chỉ có thể truy cập thông qua các địa chỉ không gian quy trình? Truy cập ngẫu nhiên sẽ rẻ với kỹ thuật này, hay tôi vẫn nên cố gắng cập nhật chỉ một số lượng nhỏ các phạm vi tiếp giáp?
Trọng lực

@Gravity: một bộ đệm có thể được ánh xạ chỉ đọc, chỉ viết hoặc đọc ghi. Để cập nhật, bạn chỉ chọn viết. Bây giờ điều quan trọng là phải biết cách hệ điều hành hiện đại quản lý không gian địa chỉ ảo, cụ thể là thông qua bộ nhớ phân trang. Trong trường hợp bản đồ chỉ ghi, bạn đã ánh xạ một phần bộ nhớ chuyển DMA và ghi của bạn vào phạm vi được ánh xạ đó sẽ chuyển trực tiếp đến bộ nhớ GPU (nội dung được ghi vào RAM CPU trước, nhưng sau đó được DMA chuyển sang GPU chuyển khoản). Điều quan trọng là đây là đường dẫn trực tiếp hơn so với khi dữ liệu đi qua mảng đỉnh của máy khách: Bộ nhớ quy trình thông thường không phù hợp với DMA
datenwolf
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.