Nhiều câu trả lời ở đây thực sự, thực sự tốt. Nhưng vấn đề OpenGL và Direct3D (D3D) có lẽ nên được giải quyết. Và điều đó đòi hỏi ... một bài học lịch sử.
Và trước khi chúng tôi bắt đầu, tôi biết nhiều về OpenGL hơn là về Direct3D . Tôi chưa bao giờ viết một dòng mã D3D nào trong đời và tôi đã viết hướng dẫn về OpenGL. Vì vậy, những gì tôi sắp nói không phải là một câu hỏi thiên vị. Nó chỉ đơn giản là một vấn đề của lịch sử.
Sự ra đời của Xung đột
Một ngày nọ, vào đầu những năm 90, Microsoft nhìn quanh. Họ thấy SNES và Sega Genesis thật tuyệt vời, chạy rất nhiều game hành động và như vậy. Và họ đã thấy DOS . Các nhà phát triển mã hóa các trò chơi DOS như trò chơi console: trực tiếp với kim loại. Tuy nhiên, không giống như các máy chơi game, nơi một nhà phát triển tạo ra trò chơi SNES biết người dùng sẽ có phần cứng nào, các nhà phát triển DOS phải viết cho nhiều cấu hình có thể. Và điều này là khá khó khăn hơn nó có vẻ.
Và Microsoft đã có một vấn đề lớn hơn: Windows. Hãy xem, Windows muốn sở hữu phần cứng, không giống như DOS, điều này cho phép các nhà phát triển làm bất cứ điều gì. Việc sở hữu phần cứng là cần thiết để có sự hợp tác giữa các ứng dụng. Hợp tác là chính xác những gì các nhà phát triển trò chơi ghét vì nó chiếm tài nguyên phần cứng quý giá mà họ có thể đang sử dụng để trở nên tuyệt vời.
Để thúc đẩy phát triển trò chơi trên Windows, Microsoft cần một API thống nhất ở mức độ thấp, chạy trên Windows mà không bị làm chậm bởi nó và hầu hết tất cả các phần cứng chéo . Một API duy nhất cho tất cả đồ họa, âm thanh và phần cứng đầu vào.
Do đó, DirectX đã ra đời.
Máy gia tốc 3D đã ra đời một vài tháng sau đó. Và Microsoft gặp phải một rắc rối. Xem, DirectDraw, thành phần đồ họa của DirectX, chỉ xử lý đồ họa 2D: phân bổ bộ nhớ đồ họa và thực hiện các bit-bit giữa các phần bộ nhớ được phân bổ khác nhau.
Vì vậy, Microsoft đã mua một chút phần mềm trung gian và đưa nó vào Direct3D Phiên bản 3. Nó đã bị hủy bỏ trên toàn cầu . Và với lý do chính đáng; nhìn vào mã D3D v3 giống như nhìn chằm chằm vào Ark of the Covenant.
John Carmack cũ tại Id Software đã nhìn vào thùng rác đó và nói, "Bắt vít đi!" và quyết định viết cho một API khác: OpenGL.
Hãy xem, một phần khác của quái thú nhiều người là Microsoft đã bận rộn làm việc với SGI trong việc triển khai OpenGL cho Windows. Ý tưởng ở đây là tòa án các nhà phát triển ứng dụng GL điển hình: ứng dụng máy trạm. Công cụ CAD, mô hình hóa, loại đó. Trò chơi là thứ xa nhất trong tâm trí họ. Đây chủ yếu là một thứ Windows NT, nhưng Microsoft cũng quyết định thêm nó vào Win95.
Như một cách để lôi kéo các nhà phát triển máy trạm vào Windows, Microsoft đã quyết định mua chuộc họ bằng quyền truy cập vào các card đồ họa 3D mới lạ này. Microsoft đã triển khai giao thức Trình điều khiển máy khách có thể cài đặt: nhà sản xuất card đồ họa có thể ghi đè lên phần mềm OpenGL của Microsoft bằng phần mềm dựa trên phần cứng. Mã có thể tự động chỉ cần sử dụng triển khai OpenGL phần cứng nếu có sẵn.
Trong những ngày đầu, các băng video cấp độ người tiêu dùng không có hỗ trợ cho OpenGL. Điều đó đã không ngăn cản Carmack chỉ chuyển Quake sang OpenGL (GLQuake) trên máy trạm SGI của mình. Như chúng ta có thể đọc từ readme GLQuake:
Về mặt lý thuyết, glquake sẽ chạy trên bất kỳ OpenGL tuân thủ nào hỗ trợ các phần mở rộng đối tượng kết cấu, nhưng trừ khi nó là phần cứng rất mạnh giúp tăng tốc mọi thứ cần thiết, chơi trò chơi sẽ không được chấp nhận. Nếu nó phải đi qua bất kỳ đường dẫn mô phỏng phần mềm nào, hiệu suất có thể sẽ chỉ dưới một khung hình mỗi giây.
Vào thời điểm này (tháng ba năm 97), phần cứng opengl tiêu chuẩn duy nhất có thể chơi glquake một cách hợp lý là một thực thể giữa các bản đồ, đó là một thẻ RẤT đắt tiền. 3dlabs đã được cải thiện đáng kể hiệu suất của họ, nhưng với các trình điều khiển có sẵn, nó vẫn không đủ tốt để chơi. Một số trình điều khiển 3dlabs hiện tại cho bảng glint và permedia cũng có thể gặp sự cố NT khi thoát khỏi chế độ chạy toàn màn hình, vì vậy tôi không khuyên bạn nên chạy glquake trên phần cứng 3dlabs.
3dfx đã cung cấp một opengl32.dll thực hiện mọi thứ cần thiết, nhưng nó không phải là một triển khai opengl đầy đủ. Các ứng dụng opengl khác rất khó có thể hoạt động với nó, vì vậy hãy xem xét về cơ bản nó là một trình điều khiển gây chấn động trên YouTube.
Đây là sự ra đời của trình điều khiển miniGL. Cuối cùng, chúng đã phát triển thành các triển khai OpenGL đầy đủ, vì phần cứng đã trở nên đủ mạnh để thực hiện hầu hết các chức năng OpenGL trong phần cứng. nVidia là người đầu tiên cung cấp triển khai OpenGL đầy đủ. Nhiều nhà cung cấp khác vật lộn, đó là một lý do tại sao các nhà phát triển ưa thích Direct3D: họ tương thích trên một phạm vi phần cứng rộng hơn. Cuối cùng, chỉ còn nVidia và ATI (nay là AMD) và cả hai đều có triển khai OpenGL tốt.
OpenGL lên ngôi
Do đó, giai đoạn được đặt: Direct3D so với OpenGL. Đây thực sự là một câu chuyện tuyệt vời, xem xét D3D v3 tệ đến mức nào.
Hội đồng Đánh giá Kiến trúc OpenGL (ARB) là tổ chức chịu trách nhiệm duy trì OpenGL. Họ phát hành một số tiện ích mở rộng, duy trì kho lưu trữ tiện ích mở rộng và tạo các phiên bản mới của API. ARB là một ủy ban gồm nhiều người chơi trong ngành đồ họa, cũng như một số nhà sản xuất hệ điều hành. Apple và Microsoft tại nhiều thời điểm là thành viên của ARB.
3Dfx ra mắt cùng với Voodoo2. Đây là phần cứng đầu tiên có thể thực hiện đa nhiệm, đây là điều mà OpenGL không thể làm trước đây. Trong khi 3Dfx mạnh mẽ chống lại OpenGL, NVIDIA, nhà sản xuất chip đồ họa đa biến tiếp theo (TNT1), lại yêu thích nó. Vì vậy, ARB đã ban hành một phần mở rộng: GL_ARB_multitexture, cho phép truy cập vào đa văn bản.
Trong khi đó, Direct3D v5 ra mắt. Bây giờ, D3D đã trở thành một API thực tế , thay vì một thứ mà một con mèo có thể nôn ra. Vấn đề? Không đa biến.
Úi.
Bây giờ, người ta sẽ không bị tổn thương nhiều như nó nên có, bởi vì mọi người đã không sử dụng đa phương tiện nhiều. Không trực tiếp. Hiệu suất đa điểm bị tổn thương khá nhiều, và trong nhiều trường hợp, nó không xứng đáng so với đa truyền. Và tất nhiên, các nhà phát triển trò chơi thích đảm bảo rằng các trò chơi của họ hoạt động trên phần cứng cũ hơn, không có nhiều tính năng, vì vậy nhiều trò chơi được vận chuyển mà không có nó.
Do đó, D3D đã được đưa ra.
Thời gian trôi qua và NVIDIA triển khai GeForce 256 (không phải GeForce GT-250; GeForce đầu tiên), cuộc cạnh tranh kết thúc khá nhiều về card đồ họa trong hai năm tới. Điểm bán hàng chính là khả năng biến đổi đỉnh và chiếu sáng (T & L) trong phần cứng. Không chỉ vậy, NVIDIA còn yêu thích OpenGL đến nỗi công cụ T & L của họ thực sự là OpenGL. Gần như theo nghĩa đen; theo tôi hiểu, một số thanh ghi của họ thực sự lấy các liệt kê OpenGL trực tiếp làm giá trị.
Direct3D v6 ra đời. Đa điểm cuối cùng nhưng ... không có phần cứng T & L. OpenGL luôn có một đường ống T & L, mặc dù trước 256 nó đã được triển khai trong phần mềm. Vì vậy, NVIDIA đã rất dễ dàng chuyển đổi việc triển khai phần mềm của họ thành một giải pháp phần cứng. Nó sẽ không tồn tại cho đến D3D v7 cho đến khi D3D cuối cùng có hỗ trợ T & L phần cứng.
Bình minh của Shader, Twilight của OpenGL
Sau đó, GeForce 3 xuất hiện. Và rất nhiều điều đã xảy ra cùng một lúc.
Microsoft đã quyết định rằng họ sẽ không bị trễ nữa. Vì vậy, thay vì nhìn vào những gì NVIDIA đang làm và sau đó sao chép nó sau khi thực tế, họ đã có một vị trí đáng kinh ngạc là đến gặp họ và nói chuyện với họ. Và rồi họ yêu nhau và có một bàn điều khiển nhỏ cùng nhau.
Một cuộc ly hôn lộn xộn xảy ra sau đó. Nhưng đó là cho một thời điểm khác.
Điều này có ý nghĩa gì với PC là GeForce 3 xuất hiện đồng thời với D3D v8. Và không khó để thấy GeForce 3 ảnh hưởng đến các shader của D3D 8 như thế nào. Các shader pixel của Shader Model 1.0 cực kỳ đặc trưng cho phần cứng của NVIDIA. Không có nỗ lực nào trong việc trừu tượng hóa phần cứng của NVIDIA; SM 1.0 là bất cứ điều gì GeForce 3 đã làm.
Khi ATI bắt đầu nhảy vào cuộc đua card đồ họa hiệu năng với Radeon 8500, đã có một vấn đề. Đường ống xử lý pixel của 8500 mạnh hơn công cụ của NVIDIA. Vì vậy, Microsoft đã phát hành Shader Model 1.1, về cơ bản là "Dù 8500 có làm gì đi nữa".
Điều đó có vẻ như là một thất bại về phía D3D. Nhưng thất bại và thành công là vấn đề bằng cấp. Và thất bại sử thi đã xảy ra ở vùng đất OpenGL.
NVIDIA yêu thích OpenGL, vì vậy khi GeForce 3 ra mắt, họ đã phát hành một loạt các phần mở rộng OpenGL. Tiện ích mở rộng OpenGL độc quyền : Chỉ dành cho NVIDIA. Đương nhiên, khi 8500 xuất hiện, nó không thể sử dụng bất kỳ cái nào trong số chúng.
Xem, ít nhất là trong vùng đất D3D 8, bạn có thể chạy các trình tạo bóng SM 1.0 trên phần cứng ATI. Chắc chắn, bạn đã phải viết các shader mới để tận dụng sự mát mẻ của 8500, nhưng ít nhất mã của bạn đã hoạt động .
Để có các shader thuộc bất kỳ loại nào trên Radeon 8500 trong OpenGL, ATI đã phải viết một số phần mở rộng OpenGL. Tiện ích mở rộng OpenGL độc quyền : chỉ ATI. Vì vậy, bạn cần một bộ mã NVIDIA và một bộ mã ATI, chỉ để có các shader .
Bây giờ, bạn có thể hỏi, "OpenGL ARB, công việc của ai là giữ cho OpenGL hiện tại?" Trường hợp nhiều ủy ban thường kết thúc: tắt là ngu ngốc.
Xem, tôi đã đề cập đến ARB_multitexture ở trên vì nó ảnh hưởng sâu sắc đến tất cả những điều này. ARB dường như (từ quan điểm của người ngoài cuộc) muốn tránh hoàn toàn ý tưởng về các shader. Họ hình dung rằng nếu họ tát đủ cấu hình vào đường ống chức năng cố định, họ có thể bằng khả năng của đường ống đổ bóng.
Vì vậy, ARB phát hành mở rộng sau khi mở rộng. Mỗi phần mở rộng có dòng chữ "texture_env" trong đó là một nỗ lực khác để vá thiết kế cũ này. Kiểm tra sổ đăng ký: giữa các tiện ích mở rộng ARB và EXT, có tám tiện ích mở rộng được thực hiện. Nhiều người đã được thăng cấp lên các phiên bản lõi OpenGL.
Microsoft là một phần của ARB tại thời điểm này; họ rời đi trong khoảng thời gian D3D 9 đạt được. Vì vậy, hoàn toàn có khả năng họ đã làm việc để phá hoại OpenGL theo một cách nào đó. Cá nhân tôi nghi ngờ lý thuyết này vì hai lý do. Một, họ sẽ phải nhận được sự giúp đỡ từ các thành viên ARB khác để làm điều đó, vì mỗi thành viên chỉ được một phiếu bầu. Và quan trọng nhất là hai, ARB đã không cần sự giúp đỡ của Microsoft để giải quyết mọi thứ. Chúng ta sẽ thấy thêm bằng chứng về điều đó.
Cuối cùng, ARB, có khả năng bị đe dọa từ cả ATI và NVIDIA (cả hai thành viên tích cực) cuối cùng đã rút đầu ra đủ lâu để cung cấp các shader theo kiểu lắp ráp thực tế.
Muốn một cái gì đó thậm chí ngu ngốc?
Phần cứng T & L. Một cái gì đó OpenGL đã có đầu tiên . Chà, thật thú vị. Để có được hiệu suất tối đa có thể từ T & L phần cứng, bạn cần lưu trữ dữ liệu đỉnh của bạn trên GPU. Rốt cuộc, đó là GPU thực sự muốn sử dụng dữ liệu đỉnh của bạn.
Trong D3D v7, Microsoft đã giới thiệu khái niệm về bộ đệm Vertex. Chúng được phân bổ các bộ nhớ GPU để lưu trữ dữ liệu đỉnh.
Bạn muốn biết khi nào OpenGL có tương đương với điều này? Oh, NVIDIA, là người yêu thích tất cả mọi thứ OpenGL (miễn là chúng là các phần mở rộng NVIDIA độc quyền), đã phát hành phần mở rộng phạm vi mảng đỉnh khi GeForce 256 lần đầu tiên ra mắt. Nhưng khi nào thì ARB quyết định cung cấp chức năng tương tự?
Hai năm sau . Điều này là sau khi họ chấp thuận các shader đỉnh và phân đoạn (pixel trong ngôn ngữ D3D). Đó là mất bao lâu để ARB phát triển một giải pháp đa nền tảng để lưu trữ dữ liệu đỉnh trong bộ nhớ GPU. Một lần nữa, một cái gì đó mà T & L phần cứng cần để đạt được hiệu suất tối đa.
Một ngôn ngữ để hủy hoại tất cả
Vì vậy, môi trường phát triển OpenGL đã bị phá vỡ trong một thời gian. Không có shader phần cứng chéo, không lưu trữ đỉnh GPU phần cứng chéo, trong khi người dùng D3D thích cả hai. Nó có thể trở nên tồi tệ hơn?
Bạn ... bạn có thể nói như vậy. Nhập phòng thí nghiệm 3D .
Họ là ai, bạn có thể hỏi? Họ là một công ty không còn tồn tại mà tôi coi là kẻ giết người thực sự của OpenGL. Chắc chắn, sự bất lực chung của ARB khiến OpenGL dễ bị tổn thương khi đáng lẽ phải sở hữu D3D. Nhưng 3D Labs có lẽ là lý do lớn nhất đối với tôi đối với trạng thái thị trường hiện tại của OpenGL. Họ có thể làm gì để gây ra điều đó?
Họ đã thiết kế Ngôn ngữ tạo bóng OpenGL.
Hãy xem, 3D Labs là một công ty đang hấp hối. GPU đắt tiền của họ đã bị thiệt thòi bởi áp lực ngày càng tăng của NVIDIA trên thị trường máy trạm. Và không giống như NVIDIA, 3D Labs không có bất kỳ sự hiện diện nào trên thị trường chính thống; Nếu NVIDIA thắng, họ đã chết.
Mà họ đã làm.
Vì vậy, trong nỗ lực duy trì sự phù hợp trong một thế giới không muốn sản phẩm của họ, Phòng thí nghiệm 3D đã xuất hiện trước Hội nghị nhà phát triển trò chơi với các bài thuyết trình cho thứ mà họ gọi là "OpenGL 2.0". Đây sẽ là bản viết lại hoàn chỉnh, từ đầu của API OpenGL. Và điều đó có ý nghĩa; có rất nhiều hành trình trong API của OpenGL tại thời điểm đó (lưu ý: hành trình đó vẫn tồn tại). Chỉ cần nhìn vào cách tải kết cấu và ràng buộc làm việc; đó là bán hồ quang.
Một phần trong đề xuất của họ là một ngôn ngữ tô bóng. Một cách tự nhiên. Tuy nhiên, không giống như các tiện ích mở rộng ARB đa nền tảng hiện tại, ngôn ngữ tô bóng của chúng là "cấp độ cao" (C là cấp độ cao đối với ngôn ngữ tạo bóng. Có, thực sự).
Bây giờ, Microsoft đang làm việc trên ngôn ngữ tạo bóng cấp cao của riêng họ. Mà họ, trong tất cả trí tưởng tượng tập thể của Microsoft, được gọi là ... Ngôn ngữ tô bóng cấp cao (HLSL). Nhưng chúng là một cách tiếp cận cơ bản khác nhau đối với các ngôn ngữ.
Vấn đề lớn nhất với ngôn ngữ đổ bóng của 3D Labs là nó được tích hợp sẵn. Xem, HLSL là một ngôn ngữ được Microsoft định nghĩa. Họ đã phát hành một trình biên dịch cho nó và nó tạo ra mã lắp ráp Shader Model 2.0 (hoặc các mô hình shader mới hơn) mà bạn sẽ cung cấp cho D3D. Trong D3D v9 ngày, HLSL không bao giờ được D3D chạm trực tiếp. Đó là một sự trừu tượng tốt đẹp, nhưng nó hoàn toàn là tùy chọn. Và một nhà phát triển luôn có cơ hội đi sau trình biên dịch và điều chỉnh đầu ra để có hiệu suất tối đa.
Ngôn ngữ Phòng thí nghiệm 3D không có điều đó. Bạn đã cho trình điều khiển ngôn ngữ giống như C, và nó tạo ra một shader. Kết thúc câu chuyện. Không phải là một shader lắp ráp, không phải thứ bạn cho ăn thứ khác. Đối tượng OpenGL thực tế đại diện cho một shader.
Điều này có nghĩa là người dùng OpenGL đã mở ra cho những nhà phát triển mơ hồ, những người vừa mới bắt đầu biên dịch các ngôn ngữ giống như lắp ráp. Các lỗi trình biên dịch chạy tràn lan trong Ngôn ngữ tạo bóng OpenGL (GLSL) mới được đặt tên. Tệ hơn nữa, nếu bạn quản lý để có được một trình đổ bóng để biên dịch trên nhiều nền tảng một cách chính xác (không có nghĩa là kỳ công), bạn vẫn phải tuân thủ các trình tối ưu hóa trong ngày. Mà không tối ưu như họ có thể.
Mặc dù đó là lỗ hổng lớn nhất trong GLSL, nhưng đó không phải là lỗ hổng duy nhất. Cho đến nay .
Trong D3D và trong các ngôn ngữ lắp ráp cũ hơn trong OpenGL, bạn có thể trộn và khớp các shader đỉnh và phân đoạn (pixel). Vì vậy, miễn là chúng giao tiếp với cùng một giao diện, bạn có thể sử dụng bất kỳ trình tạo bóng đỉnh nào với bất kỳ trình tạo mảnh phân mảnh tương thích nào. Và thậm chí có mức độ không tương thích mà họ có thể chấp nhận; một shader đỉnh có thể viết một đầu ra mà shader mảnh không đọc được. Và kể từ đó trở đi.
GLSL không có bất kỳ thứ gì trong số đó. Vertex và shader mảnh đã được hợp nhất với nhau trong cái mà 3D Labs gọi là "đối tượng chương trình". Vì vậy, nếu bạn muốn chia sẻ các chương trình đỉnh và phân đoạn, bạn phải xây dựng nhiều đối tượng chương trình. Và điều này gây ra vấn đề lớn thứ hai.
Hãy xem, 3D Labs nghĩ rằng họ đang thông minh. Họ dựa trên mô hình biên dịch của GLSL trên C / C ++. Bạn lấy một .c hoặc .cpp và biên dịch nó thành một tệp đối tượng. Sau đó, bạn lấy một hoặc nhiều tệp đối tượng và liên kết chúng vào một chương trình. Vì vậy, đó là cách GLSL biên dịch: bạn biên dịch trình đổ bóng của bạn (đỉnh hoặc đoạn) thành một đối tượng đổ bóng. Sau đó, bạn đặt các đối tượng đổ bóng đó vào một đối tượng chương trình và liên kết chúng lại với nhau để tạo thành chương trình thực tế của bạn.
Mặc dù điều này đã cho phép những ý tưởng tuyệt vời tiềm năng như có các shader "thư viện" có chứa mã bổ sung mà các shader chính có thể gọi, nhưng thực tế nó có nghĩa là các shader đã được biên dịch hai lần . Một lần trong giai đoạn biên dịch và một lần trong giai đoạn liên kết. Trình biên dịch của NVIDIA nói riêng được biết đến về cơ bản là chạy trình biên dịch hai lần. Nó không tạo ra một số loại trung gian mã đối tượng; nó chỉ biên dịch nó một lần và ném đi câu trả lời, sau đó biên dịch lại vào lúc liên kết.
Vì vậy, ngay cả khi bạn muốn liên kết shader đỉnh của mình với hai shader mảnh khác nhau, bạn phải biên dịch nhiều hơn so với trong D3D. Đặc biệt là vì việc biên dịch ngôn ngữ giống như C đã được thực hiện ngoại tuyến , không phải lúc bắt đầu thực hiện chương trình.
Có những vấn đề khác với GLSL. Có lẽ có vẻ sai lầm khi đổ lỗi cho Phòng thí nghiệm 3D, vì ARB cuối cùng đã chấp thuận và kết hợp ngôn ngữ (nhưng không có gì khác trong sáng kiến "OpenGL 2.0" của họ). Nhưng đó là ý tưởng của họ.
Và đây là phần thực sự đáng buồn: 3D Labs đã đúng (hầu hết). GLSL không phải là ngôn ngữ tạo bóng dựa trên vectơ theo cách của HLSL tại thời điểm đó. Điều này là do phần cứng của 3D Labs là phần cứng vô hướng (tương tự phần cứng NVIDIA hiện đại), nhưng cuối cùng họ đã đúng theo hướng mà nhiều nhà sản xuất phần cứng đã đi với phần cứng của họ.
Họ đã đúng khi đi với một mô hình biên dịch trực tuyến cho một ngôn ngữ "cấp cao". D3D thậm chí đã chuyển sang cuối cùng.
Vấn đề là Phòng thí nghiệm 3D đã đúng lúc . Và trong khi cố gắng triệu tập tương lai quá sớm, khi cố gắng trở thành bằng chứng trong tương lai, họ đã gạt bỏ hiện tại . Nghe có vẻ giống như cách OpenGL luôn có khả năng cho chức năng T & L. Ngoại trừ việc đường ống T & L của OpenGL vẫn hữu ích trước T & L phần cứng, trong khi GLSL là trách nhiệm trước khi thế giới bắt kịp nó.
GLSL là một ngôn ngữ tốt bây giờ . Nhưng cho thời gian? Thật là kinh khủng. Và OpenGL phải chịu đựng điều đó.
Rơi về phía Apotheosis
Trong khi tôi duy trì rằng Phòng thí nghiệm 3D đã giáng một đòn chí mạng, thì chính ARB là người sẽ đóng chiếc đinh cuối cùng vào quan tài.
Đây là một câu chuyện mà bạn có thể đã nghe nói. Vào thời điểm OpenGL 2.1, OpenGL đã gặp sự cố. Nó đã có rất nhiều di sản. API không còn dễ sử dụng nữa. Có 5 cách để làm mọi thứ và không có ý tưởng nào là nhanh nhất. Bạn có thể "học" OpenGL bằng các hướng dẫn đơn giản, nhưng bạn không thực sự học API OpenGL mang lại cho bạn hiệu năng thực sự và sức mạnh đồ họa.
Vì vậy, ARB đã quyết định thử phát minh lại OpenGL. Điều này tương tự như "OpenGL 2.0" của 3D Labs, nhưng tốt hơn vì ARB đứng sau nó. Họ gọi nó là "Đỉnh dài".
Điều gì là xấu khi dành một chút thời gian để cải thiện API? Điều này thật tệ vì Microsoft đã để bản thân dễ bị tổn thương. Hãy xem, đây là thời điểm chuyển đổi Vista.
Với Vista, Microsoft quyết định đưa ra một số thay đổi rất cần thiết trong trình điều khiển hiển thị. Họ buộc các trình điều khiển phải nộp lên HĐH để ảo hóa bộ nhớ đồ họa và nhiều thứ khác.
Mặc dù người ta có thể tranh luận về giá trị của điều này hoặc liệu nó có thực sự khả thi hay không, nhưng thực tế vẫn là: Microsoft coi D3D 10 chỉ là Vista (và ở trên). Ngay cả khi bạn có phần cứng có khả năng D3D 10, bạn không thể chạy các ứng dụng D3D 10 mà không chạy Vista.
Bạn cũng có thể nhớ rằng Vista ... ừm, hãy nói rằng nó không hoạt động tốt. Vì vậy, bạn đã có một hệ điều hành hoạt động kém, một API mới chỉ chạy trên HĐH đó và một thế hệ phần cứng mới cần API và HĐH đó để làm bất cứ điều gì nhanh hơn thế hệ trước.
Tuy nhiên, các nhà phát triển có thể truy cập các tính năng của lớp D3D 10 thông qua OpenGL. Chà, họ có thể nếu ARB không bận rộn làm việc trên Longs Peak.
Về cơ bản, ARB đã dành một năm làm việc tốt và một nửa đến hai năm để làm cho API tốt hơn. Vào thời điểm OpenGL 3.0 thực sự ra mắt, việc áp dụng Vista đã hết, Win7 đã sẵn sàng để đặt Vista phía sau họ và hầu hết các nhà phát triển trò chơi không quan tâm đến các tính năng của lớp D3D-10. Rốt cuộc, phần cứng D3D 10 chạy các ứng dụng D3D 9 tốt. Và với sự gia tăng của các cổng PC-to-console (hoặc các nhà phát triển PC chuyển sang phát triển giao diện điều khiển. Hãy lựa chọn), các nhà phát triển không cần các tính năng của lớp D3D 10.
Bây giờ, nếu các nhà phát triển đã truy cập vào các tính năng đó sớm hơn thông qua OpenGL trên các máy WinXP, thì việc phát triển OpenGL có thể đã nhận được một cú đánh rất cần thiết trong tay. Nhưng ARB đã bỏ lỡ cơ hội của họ. Và bạn có muốn biết phần tồi tệ nhất?
Mặc dù đã dành hai năm quý báu để cố gắng xây dựng lại API từ đầu ... họ vẫn thất bại và chỉ quay trở lại hiện trạng (ngoại trừ cơ chế khấu hao).
Vì vậy, ARB không chỉ bỏ lỡ một cửa sổ cơ hội quan trọng , họ thậm chí còn không hoàn thành nhiệm vụ khiến họ bỏ lỡ cơ hội đó. Khá nhiều sử thi thất bại tất cả xung quanh.
Và đó là câu chuyện về OpenGL so với Direct3D. Một câu chuyện về những cơ hội bị bỏ lỡ, sự ngu ngốc thô thiển, sự mù quáng cố ý và sự dại dột đơn giản.