2009-08-02 30 views
5

OpenGL 3.0 và 3.1 đã không dùng nữa một số tính năng mà tôi thấy cần thiết. Đặc biệt, việc sử dụng chức năng cố định trong trình đổ bóng.OpenGL: Thỏa thuận không dùng nữa là gì?

Có ai có thể giải thích thỏa thuận thực sự với điều đó không?

Tại sao họ thấy cần phải từ bỏ tính năng hữu ích như vậy mà mọi người rõ ràng đều sử dụng và không có công ty phần cứng lành mạnh nào sẽ loại bỏ hỗ trợ?

Trả lời

6

Như bạn đã nói, không có công ty phần cứng nào sẽ xóa hỗ trợ cho trình đổ bóng chức năng cố định, bởi vì có quá nhiều ứng dụng hiện có sử dụng chúng. Tuy nhiên, những gì họ không muốn làm là tìm ra cách xác định các tương tác giữa các bộ đổ bóng FF và mọi phần mở rộng trong tương lai mà chúng thêm vào. Những tương tác này rất phức tạp (một phần vì các trình che lấp FF quá phức tạp), dẫn đến các lỗi và việc triển khai không nhất quán giữa các nhà cung cấp - cả hai đều xấu cho các nhà phát triển và người dùng cuối.

Vì vậy, họ đang vẽ một dòng: nếu bạn muốn sử dụng trình tạo bóng mờ FF, bạn không nhận được bất kỳ chức năng mới nào. Nếu bạn muốn có chức năng mới, bạn không thể sử dụng bộ đổ bóng FF. Điều này rất giống với những gì Microsoft đã làm trong D3D10: nó bổ sung thêm một loạt các chức năng mới, nhưng đồng thời loại bỏ hoàn toàn các chức năng đổ bóng cố định. Niềm tin là tập hợp các nhà phát triển cần chức năng không đổ bóng mới nhưng những người không cần các trình tạo bóng lập trình là rất nhỏ.

1

Công cụ đổ bóng chức năng cố định khá dễ dàng được thay thế bằng trình đổ bóng GLSL tiêu chuẩn, do đó rất khó để xem tại sao chúng không được sử dụng một cách hợp lý.

Tôi ít chắc chắn hơn bạn rằng họ sẽ không bị giảm nhiều phần cứng trong tương lai gần vì OpenGL ES 2.0 không hỗ trợ đường ống FF (và do đó không tương thích ngược với OpenGL ES 1.x). Dường như với tôi rằng nhiều động lực với OpenGL những ngày này đến từ việc áp dụng rộng rãi OpenGL ES trên nền tảng di động và với chức năng FF đi từ đó sẽ có một số áp lực đáng kể để tránh xa việc sử dụng nó. Thật vậy, tôi mong đợi việc triển khai OpenGL ES gọn hơn để thay thế OpenGL tiêu chuẩn khá rộng rãi trong vài năm tới, và chức năng FF có thể biến mất nhiều hơn vì phần lớn phần cứng sẽ triển khai OpenGL ES thay vì nó bị loại bỏ khỏi phần cứng thực hiện OpenGL đầy đủ

2

Cần làm rõ rằng một đối tượng địa lý được đánh dấu là "không dùng nữa" sẽ không thực sự bị xóa. Ví dụ: ngữ cảnh OpenGL 3.0 có tất cả các tính năng - không có gì biến mất. Hơn nữa, một số nhà cung cấp sẽ gửi các trình điều khiển có thể tạo ra các bối cảnh 3.1 và 3.2 bằng cách sử dụng hồ sơ tương thích cũng sẽ bật các tính năng không dùng nữa. Vì vậy, hãy xem xét kỹ phần cứng của nhà cung cấp mà bạn sẽ hỗ trợ và hỏi về chế độ tương thích ARB cho các tính năng cũ. (Cũng có cấu hình "cốt lõi" là 3.2, cho phép các nhà cung cấp tạo ra một trình điều khiển gọn gàng và có ý nghĩa hơn nếu họ muốn tạo ra một thứ như vậy)

Lưu ý rằng bất kỳ thẻ hiện tại nào thực sự không có phần cứng FF phần nữa - chúng chỉ chạy trình đổ bóng. Khi bạn yêu cầu hành vi FF, thời gian chạy GL là tác giả tạo bóng đổ thay cho bạn ..

+0

"thời gian chạy GL là tác giả tạo bóng đổ thay mặt bạn." .... Bạn có bất kỳ tham chiếu nào về điều đó không? – shoosh

+0

Không tắt đầu của tôi. Chỉ cần nói chuyện với những người lái xe IHV. –

+0

Xem thêm: http://developer.nvidia.com/object/opengl_driver.html – Stringer

2

Tại sao họ thấy cần phải từ bỏ tính năng hữu ích như vậy mà mọi người rõ ràng sử dụng và không có công ty phần cứng lành mạnh nào sẽ loại bỏ hỗ trợ cho?

Tôi cho rằng Apple phải điên, vì MacOSX 10.7 chỉ hỗ trợ 3.2 lõi. Không hỗ trợ đặc điểm kỹ thuật tương thích, không có tiện ích mở rộng ARB_compatibility, không có gì. Bạn có thể tạo ngữ cảnh 2.1 hoặc ngữ cảnh lõi 3.2.

Tuy nhiên, nếu bạn muốn lý do:

  1. Vì lợi ích của sự hoàn chỉnh: những gì Jesse Hall nói. ARB không còn phải xem xét sự tương tác giữa chức năng cố định và các tính năng mới. Toán số nguyên, kết cấu mảng và nhiều tính năng khác được xác định là không thể sử dụng được với đường ống chức năng cố định. OpenGL đã thực sự cải thiện trong 3 năm qua kể từ khi GL 3.0 ra mắt; tốc độ thay đổi của ARB là khá đáng kể. Liệu điều đó có khả thi nếu họ phải tìm cách để làm cho tất cả các tính năng đó tương tác với chức năng cố định? Và nếu họ không có các tương tác chức năng cố định, thì bạn sẽ không phàn nàn về cách bạn không thể truy cập các tính năng mới từ mã cũ của mình? Điều gì dẫn tuyệt vời vào:

  2. Nó hoạt động như một dấu hiệu mạnh mẽ về việc một trong những nên sử dụng nào để sử dụng. Ngay cả khi ngữ cảnh tương thích luôn có sẵn, bạn có thể xem xét OpenGL cốt lõi để xem cách người dùng phải tiếp cận giải quyết vấn đề.

  3. Điều này khiến cho việc hợp nhất GL và GL ES sắp tới hợp lý hơn nhiều. ES 2.0 đã tung ra tất cả các công cụ cũ và chỉ áp dụng những gì bạn có thể nghĩ là lõi GL 2.1. Mục tiêu cuối cùng sẽ là chỉ có một OpenGL. Để làm điều đó, bạn phải có khả năng loại bỏ GL của tất cả các tàu tuần dương.

0

OpenGL cho phép cả hồ sơ 'cốt lõi' và hồ sơ 'tương thích'. Vì vậy, đối với hầu hết các hệ thống, bạn sẽ không mất bất kỳ loại quyền truy cập nào vào các chức năng không được chấp nhận hoặc bị loại bỏ.

Nhưng nếu bạn muốn đảm bảo tính tương thích, tốt nhất là hãy gắn bó với nội dung cốt lõi. Bạn sẽ không được đảm bảo một hồ sơ tương thích (ngay cả khi hầu hết phần cứng có một và ở trạng thái hiện tại thì nhiều khả năng bạn sẽ gặp phải một OpenGL lỗi thời hơn là chỉ một lõi). Ngoài ra OpenGL ES bây giờ là một tập hợp con của OpenGL, có thể viết một chương trình OpenGL ES 2.x/3.x và có nó chạy trong OpenGL 4.3 với hầu như không có thay đổi.

Bảng điều khiển trò chơi như PlayStations và Nintendo được vận chuyển bằng thư viện đồ họa của riêng họ thay vì sử dụng OpenGL.

Chúng được dựa trên OpenGL nhưng ở đây bị loại bỏ theo cách tương tự là ES (Tôi không nghĩ ES 2.0 đã ra sau đó). Những hệ thống này cần phải viết các trình điều khiển đồ họa và thư viện riêng của họ, yêu cầu một nhà cung cấp phần cứng viết một cái gì đó về cơ bản toàn bộ các thư viện gói cũ là một chút (tất cả các công cụ chức năng cố định sẽ chỉ được thực hiện trong shaders ở một số giai đoạn) có khả năng là glBegin/glEnd sẽ tự động trở thành một VBO).

Tôi nghĩ rằng điều quan trọng là phải đảm bảo rằng các nhà phát triển được biết về cách thức hiện tại họ nên lập trình. Trong nhiều thập kỷ, mọi người đã được dạy cách 'sai' để làm những việc theo mặc định và các đối tượng đệm đỉnh đã được dạy như một sự bổ sung.

Các vấn đề liên quan