Các lập trình viên đồ họa mới có nên học Vulkan thay vì OpenGL không?

Từ wiki : "API Vulkan ban đầu được gọi là" sáng kiến ​​OpenGL thế hệ tiếp theo "của Khrono" và đó là "nỗ lực thiết kế lại cơ sở để hợp nhất OpenGL và OpenGL ES thành một API chung sẽ không bị ngược. tương thích với các phiên bản OpenGL hiện có ".

Vì vậy, những người bây giờ có thể tham gia vào lập trình đồ họa sẽ được phục vụ tốt hơn để học Vulkan thay vì OpenGL không? Có vẻ như họ sẽ phục vụ cùng một mục đích.

Khó khăn!

Điều này có vẻ giống như hỏi "Các lập trình viên mới nên học C ++ thay vì C" hay "Các nghệ sĩ mới nên học vẽ kỹ thuật số thay vì vẽ tranh vật lý".

Đặc biệt là vì nó không tương thích ngược, các lập trình viên đồ họa sẽ thật ngu ngốc khi loại trừ API đồ họa phổ biến nhất trong ngành, đơn giản chỉ vì có một cái mới. Ngoài ra, OpenGL làm những việc khác nhau một cách khác nhau. Hoàn toàn có khả năng một công ty sẽ chọn OpenGL thay vì Vulkan, đặc biệt là vào đầu trò chơi này và công ty đó sẽ không quan tâm đến ai đó không biết OpenGL, bất kể họ có biết Vulkan hay không.

Chuyên môn hiếm khi là một kỹ năng thị trường.

Đối với những người không cần phải tiếp thị các kỹ năng của mình như vậy, như các nhà phát triển độc lập, sẽ còn ngu ngốc hơn khi xóa một công cụ khỏi hộp công cụ của họ. Một nhà phát triển độc lập thậm chí còn phụ thuộc nhiều hơn vào tính linh hoạt và có thể chọn những gì hoạt động, hơn những gì được tài trợ. Chuyên về Vulkan chỉ giới hạn các lựa chọn của bạn.

Chuyên môn hóa hiếm khi là một mô hình hiệu quả.

Nếu bạn đang bắt đầu ngay bây giờ và bạn muốn thực hiện công việc GPU (trái ngược với việc luôn sử dụng công cụ trò chơi như Unity), bạn chắc chắn nên bắt đầu bằng cách học Vulkan. Có lẽ bạn cũng nên học GL sau, nhưng có một vài lý do để nghĩ Vulkan trước.

1. GL và GLES đã được thiết kế từ nhiều năm trước, khi GPU hoạt động hoàn toàn khác nhau. (Sự khác biệt rõ ràng nhất là các cuộc gọi rút thăm chế độ ngay lập tức so với xếp hàng và xếp hàng lệnh.) GL khuyến khích bạn suy nghĩ theo kiểu chế độ ngay lập tức và có rất nhiều hành trình kế thừa. Vulkan cung cấp các mô hình lập trình gần với cách thức hoạt động của GPU hiện đại, vì vậy nếu bạn học Vulkan, bạn sẽ hiểu rõ hơn về cách thức công nghệ thực sự hoạt động, về những gì hiệu quả và không hiệu quả. Tôi thấy nhiều người đã bắt đầu với GL hoặc GLES và ngay lập tức có thói quen xấu như phát hành các cuộc gọi rút thăm riêng cho từng đối tượng thay vì sử dụng VBO, hoặc thậm chí tệ hơn, sử dụng danh sách hiển thị. Các lập trình viên GL rất khó để tìm ra những gì không còn được khuyến khích.

2. Việc chuyển từ Vulkan sang GL hoặc GLES dễ dàng hơn nhiều so với ngược lại. Vulkan làm cho rõ ràng rất nhiều điều bị ẩn hoặc không thể đoán trước trong GL, chẳng hạn như kiểm soát đồng thời, chia sẻ và trạng thái kết xuất. Nó đẩy rất nhiều sự phức tạp từ trình điều khiển lên ứng dụng: nhưng bằng cách đó, nó mang lại quyền kiểm soát cho ứng dụng và giúp đơn giản hơn để có được hiệu suất và khả năng tương thích giữa các nhà cung cấp GPU khác nhau. Nếu bạn có một số mã hoạt động trong Vulkan, thay vào đó, việc chuyển mã đó sang GL hoặc GLES khá dễ dàng và bạn kết thúc bằng một thứ sử dụng thói quen GL / GLES tốt. Nếu bạn có mã hoạt động trong GL hoặc GLES, bạn gần như phải bắt đầu lại để làm cho nó hoạt động hiệu quả trong Vulkan: đặc biệt nếu nó được viết theo kiểu kế thừa (xem điểm 1).

Lúc đầu tôi lo ngại rằng Vulkan khó lập trình hơn rất nhiều, và mặc dù điều đó sẽ ổn đối với các nhà phát triển có kinh nghiệm tại các công ty lớn hơn, nó sẽ là một rào cản rất lớn đối với các nhà đầu tư và sở thích. Tôi đã đặt câu hỏi này cho một số thành viên của Nhóm làm việc và họ nói rằng họ có một số điểm dữ liệu từ những người mà họ đã nói chuyện với những người đã chuyển đến Vulkan. Những người này bao gồm từ các nhà phát triển tại Epic làm việc về tích hợp UE4 đến các nhà phát triển trò chơi có sở thích. Kinh nghiệm của họ là bắt đầu (tức là có một hình tam giác trên màn hình) liên quan đến việc tìm hiểu thêm các khái niệm và có mã soạn sẵn dài hơn, nhưng nó không quá phức tạp, ngay cả đối với các nhà đầu tư. Nhưng sau khi đến giai đoạn đó, họ thấy việc xây dựng một ứng dụng thực sự có thể thay đổi được dễ dàng hơn nhiều, bởi vì (a) hành vi có thể dự đoán được nhiều hơn giữa các triển khai của các nhà cung cấp khác nhau và (b) nhận được một thứ gì đó hoạt động tốt với tất cả các hiệu ứng được bật không liên quan đến nhiều lỗi và thử. Với những kinh nghiệm từ các nhà phát triển thực sự, họ đã thuyết phục tôi rằng lập trình chống lại Vulkan là khả thi ngay cả đối với người mới bắt đầu về đồ họa, và sự phức tạp nói chung sẽ ít hơn một khi bạn vượt qua hướng dẫn và bắt đầu xây dựng các bản demo hoặc ứng dụng mà bạn có thể cung cấp cho người khác.

Như những người khác đã nói: GL có sẵn trên nhiều nền tảng, WebGL là một cơ chế phân phối tốt, có rất nhiều phần mềm hiện có sử dụng GL và có nhiều nhà tuyển dụng tuyển dụng cho kỹ năng đó. Nó sẽ xuất hiện trong vài năm tới trong khi Vulkan tăng tốc và phát triển một hệ sinh thái. Vì những lý do này, bạn sẽ thật ngu ngốc khi loại bỏ việc học GL hoàn toàn. Mặc dù vậy, bạn sẽ có thời gian dễ dàng hơn với nó và trở thành một lập trình viên GL tốt hơn (và nói chung là một lập trình viên GPU tốt hơn), nếu bạn bắt đầu với thứ gì đó giúp bạn hiểu GPU, thay vì hiểu cách họ làm việc 20 năm trước.

Tất nhiên, có thêm một lựa chọn. Tôi không biết điều này có liên quan đến bạn hay không, nhưng tôi cảm thấy tôi nên nói điều đó cho những khách truy cập khác.

Để trở thành nhà phát triển trò chơi độc lập, hoặc nhà thiết kế trò chơi hoặc tạo trải nghiệm VR, bạn không cần phải học Vulkan hoặc GL. Nhiều người bắt đầu với một công cụ trò chơi (Unity hoặc UE4 là phổ biến tại thời điểm này). Sử dụng một công cụ như thế sẽ cho phép bạn tập trung vào trải nghiệm bạn muốn tạo, thay vì công nghệ đằng sau nó. Nó sẽ che giấu sự khác biệt giữa GL và Vulkan với bạn và bạn không cần phải lo lắng về những gì được hỗ trợ trên nền tảng của bạn. Nó sẽ cho phép bạn tìm hiểu về tọa độ 3D, biến đổi, ánh sáng và hoạt hình mà không phải xử lý tất cả các chi tiết nghiệt ngã cùng một lúc. Một số studio trò chơi hoặc VR chỉ hoạt động trong một công cụ và họ không có chuyên gia GL toàn thời gian. Ngay cả trong các studio lớn hơn viết động cơ của riêng họ, những người làm lập trình đồ họa là thiểu số,

Tìm hiểu về các chi tiết về cách tương tác với GPU chắc chắn là một kỹ năng hữu ích và là điều mà nhiều nhà tuyển dụng sẽ đánh giá cao, nhưng bạn không nên cảm thấy mình phải học điều đó để tham gia lập trình 3D; và ngay cả khi bạn biết điều đó, nó sẽ không nhất thiết là thứ bạn sử dụng hàng ngày.

Học lập trình đồ họa không chỉ là học API. Đó là về cách học đồ họa hoạt động. Biến đổi Vertex, mô hình chiếu sáng, kỹ thuật bóng, ánh xạ kết cấu, kết xuất hoãn lại, v.v. Chúng hoàn toàn không liên quan gì đến API bạn sử dụng để triển khai chúng.

Vì vậy, câu hỏi là: bạn có muốn tìm hiểu cách sử dụng API không? Hay bạn muốn học đồ họa ?

Để thực hiện công cụ với đồ họa được tăng tốc phần cứng, bạn phải học cách sử dụng API để truy cập phần cứng đó. Nhưng một khi bạn có khả năng giao tiếp với hệ thống, việc học đồ họa của bạn sẽ ngừng tập trung vào những gì API làm cho bạn và thay vào đó tập trung vào các khái niệm đồ họa. Ánh sáng, bóng tối, bản đồ, vv

Nếu mục tiêu của bạn là tìm hiểu các khái niệm đồ họa, thời gian bạn dành cho API là thời gian bạn không dành thời gian để học các khái niệm đồ họa . Làm thế nào để biên dịch shader không liên quan gì đến đồ họa. Cũng không làm thế nào để gửi cho họ đồng phục, làm thế nào để tải dữ liệu đỉnh vào bộ đệm, v.v ... Đây là những công cụ và công cụ quan trọng để thực hiện công việc đồ họa.

Nhưng chúng không thực sự là khái niệm đồ họa. Họ là một phương tiện để kết thúc.

Nó mất rất nhiều công sức và học tập với Vulkan trước khi bạn có thể đạt đến điểm mà bạn đã sẵn sàng để bắt đầu học các khái niệm đồ họa. Truyền dữ liệu cho các shader yêu cầu quản lý bộ nhớ rõ ràng và đồng bộ hóa truy cập rõ ràng. Và kể từ đó trở đi.

Ngược lại, đến thời điểm đó với OpenGL đòi hỏi ít công việc hơn. Và vâng, tôi đang nói về OpenGL cấu hình lõi dựa trên shader hiện đại.

Chỉ cần so sánh những gì nó cần để làm một cái gì đó đơn giản như xóa màn hình. Trong Vulkan, điều này đòi hỏi ít nhất một số hiểu biết về một số lượng lớn các khái niệm: bộ đệm lệnh, hàng đợi thiết bị, đối tượng bộ nhớ, hình ảnh và các cấu trúc WSI khác nhau.

Trong OpenGL ... đó là ba chức năng: glClearColor, glClear, và hoán đổi nền tảng cụ thể đệm gọi. Nếu bạn đang sử dụng OpenGL hiện đại hơn, bạn có thể giảm xuống còn hai: glClearBufferuivvà trao đổi bộ đệm. Bạn không cần phải biết bộ đệm khung là gì hoặc hình ảnh của nó đến từ đâu. Bạn xóa nó và trao đổi bộ đệm.

Vì OpenGL che giấu bạn rất nhiều, nên mất ít công sức hơn để đi đến điểm bạn thực sự học đồ họa thay vì học giao diện với phần cứng đồ họa.

Hơn nữa, OpenGL là một API (tương đối) an toàn. Nó sẽ phát sinh lỗi khi bạn làm điều gì đó sai, thường. Vulkan thì không. Mặc dù có các lớp gỡ lỗi mà bạn có thể sử dụng để trợ giúp, API Vulkan lõi sẽ cho bạn biết hầu như không có gì trừ khi có lỗi phần cứng. Nếu bạn làm điều gì đó sai, bạn có thể nhận được kết xuất rác hoặc làm hỏng GPU.

Cùng với sự phức tạp của Vulkan, việc vô tình làm điều sai trái trở nên rất dễ dàng. Việc quên đặt kết cấu theo bố cục phù hợp có thể hoạt động theo một cách thực hiện, nhưng không phải là khác. Việc quên một điểm đồng bộ hóa đôi khi có thể hoạt động, nhưng sau đó đột nhiên thất bại mà dường như không có lý do. Và kể từ đó trở đi.

Tất cả những gì đang được nói, có nhiều thứ để học đồ họa hơn là học các kỹ thuật đồ họa. Có một khu vực đặc biệt nơi Vulkan chiến thắng.

Hiệu suất đồ họa .

Trở thành một lập trình viên đồ họa 3D thường đòi hỏi một số ý tưởng về cách tối ưu hóa mã của bạn. Và đây là nơi mà việc che giấu thông tin và làm những việc sau lưng của OpenGL trở thành một vấn đề.

Mô hình bộ nhớ OpenGL là đồng bộ. Việc triển khai được phép đưa ra các lệnh không đồng bộ miễn là người dùng không thể biết được sự khác biệt. Vì vậy, nếu bạn kết xuất với một số hình ảnh, sau đó thử đọc từ nó, việc triển khai phải đưa ra một sự kiện đồng bộ hóa rõ ràng giữa hai tác vụ này.

Nhưng để đạt được hiệu suất trong OpenGL, bạn phải biết rằng việc triển khai thực hiện điều này, để bạn có thể tránh nó . Bạn phải nhận ra nơi triển khai đang bí mật phát hành các sự kiện đồng bộ hóa, sau đó viết lại mã của bạn để tránh chúng càng nhiều càng tốt. Nhưng chính API không làm cho điều này trở nên rõ ràng; bạn phải có được kiến ​​thức này từ một nơi nào đó.

Với Vulkan ... bạn là người phải đưa ra các sự kiện đồng bộ hóa đó. Do đó, bạn phải nhận thức được thực tế rằng phần cứng không thực thi các lệnh một cách đồng bộ. Bạn phải biết khi nào bạn cần đưa ra những sự kiện đó, và do đó bạn phải biết rằng họ có thể sẽ làm chậm chương trình của bạn. Vì vậy, bạn làm mọi thứ bạn có thể để tránh chúng.

Một API rõ ràng như Vulkan buộc bạn phải đưa ra các loại quyết định hiệu suất. Và do đó, nếu bạn học API Vulkan, bạn đã có một ý tưởng tốt về những gì sẽ diễn ra chậm và những gì sẽ diễn ra nhanh chóng.

Nếu bạn phải thực hiện một số công việc bộ đệm khung buộc bạn phải tạo một kết xuất đồ họa mới ... tỷ lệ cược là điều này sẽ chậm hơn nếu bạn có thể đặt nó vào một đường dẫn riêng biệt của một đường dẫn kết xuất. Điều đó không có nghĩa là bạn không thể làm điều đó, nhưng API cho bạn biết trước rằng nó có thể gây ra vấn đề về hiệu suất.

Trong OpenGL, API về cơ bản mời bạn thay đổi tệp đính kèm bộ đệm khung của bạn willy-nilly. Không có hướng dẫn về những thay đổi sẽ nhanh hay chậm.

Vì vậy, trong trường hợp đó, học Vulkan có thể giúp bạn học tốt hơn về cách làm cho đồ họa nhanh hơn. Và nó chắc chắn sẽ giúp bạn giảm chi phí CPU.

Sẽ vẫn còn nhiều thời gian nữa trước khi bạn có thể đi đến điểm mà bạn có thể học các kỹ thuật kết xuất đồ họa.

Sức hấp dẫn chính của OpenGL (ít nhất là với tôi) là nó hoạt động trên nhiều nền tảng. Hiện tại, Vulkan không hoạt động trên OSX và Apple có API cạnh tranh có tên Metal. Rất có thể sẽ mất một thời gian trước khi Apple hỗ trợ Vulkan và khi họ làm vậy, hỗ trợ Vulkan chỉ có thể đến với phần cứng mới nhất của họ. OpenGL đã hỗ trợ hầu hết các phần cứng và sẽ tiếp tục làm như vậy.

Nó phụ thuộc vào những gì bạn muốn làm. Nếu bạn muốn học lập trình đồ họa chỉ cho bản thân mình, thực sự không có vấn đề gì bạn chọn.

Nếu bạn đang nghĩ về công việc chuyên nghiệp, tôi khuyên bạn nên Vulkan. Nó gần với phần cứng hơn và tôi nghĩ kiến ​​thức về những gì phần cứng làm là quan trọng đối với các lập trình viên đồ họa.

Vulkan gần với phần cứng hơn vì OpenGL thực hiện rất nhiều thứ trong phần mềm mà trong Vulkan bạn làm thủ công, như thực hiện hàng đợi lệnh. Ngoài ra quản lý bộ nhớ là ứng dụng không phải trình điều khiển. Bạn cần lo lắng về việc phân bổ bộ nhớ cho uniforms(biến mà bạn chuyển từ CPU sang GPU), về việc theo dõi chúng. Bạn có nhiều thứ để lo lắng hơn nhưng nó cũng giúp bạn tự do hơn trong việc sử dụng bộ nhớ. Nghe có vẻ đáng sợ và áp đảo nhưng thực sự không phải vậy. Đây chỉ là API tiếp theo mà bạn cần học.

Hiểu những điều này cũng sẽ giúp hiểu được cách thức hoạt động của GPU. Điều gì sẽ cho phép bạn thực hiện một số tối ưu hóa cả trên Vulkan và OpenGL.

Và một điều nữa xuất hiện trong đầu tôi, nếu bạn bắt đầu học lập trình đồ họa có lẽ khi bạn tìm việc vì một Vulkan sẽ phổ biến hơn (có thể phổ biến hơn OpenGL). Ngoài ra, theo như tôi biết, hầu hết các công ty đang sử dụng một số API đồ họa đều tự viết các hàm xung quanh nó, vì vậy có khả năng trong công việc bạn sẽ không viết bằng OpenGL cũng như Vulkan nhưng kiến ​​thức về GPU sẽ luôn hữu ích.

Tôi đã "bắt đầu" lập trình đồ họa được vài tháng rồi.

Hiện tại tôi vẫn đang học trung học và tôi có thể nói với bạn rằng tôi hầu như luôn tìm cách phát triển các ứng dụng đa nền tảng. Thực tế đây là vấn đề số một của tôi với Vulkan - Nó không được phát triển để hoạt động trên tất cả các nền tảng. Tôi làm việc với OpenGL trong Java và có hơn 6 tháng.

Một vấn đề khác mà tôi có là với tuyên bố của Vulkan là cách nó tuyên bố là tốt hơn. Mặc dù OpenGL chắc chắn không cập nhật trang web của họ rất thường xuyên. Họ tiếp tục liên tục phát hành các bản cập nhật và tôi luôn mong đợi các bản cập nhật mới chạy nhanh hơn hoặc hoạt động tốt hơn với phần cứng mới.

Điều đó đang được nói, trong khi tôi chủ yếu làm việc với OpenGL, tôi hiểu các nguyên tắc cơ bản của DirectX và Vulkan. Mặc dù tôi không làm việc với họ nhiều, đặc biệt là Vulkan vì nó rất khó học và không có cấu trúc tốt để lập trình như OpenGl và DirectX.

Cuối cùng, tôi muốn thêm rằng chuyên về một lĩnh vực như tôi chủ yếu sử dụng Java và OpenGL không phải là sản phẩm độc lập đáng kinh ngạc. Nếu tôi muốn có một công việc tại một công ty sản xuất trò chơi, phần lớn OpenGL sẽ chỉ được sử dụng để tạo trò chơi cho phát triển Linux và Android và có thể cả OSX. DirectX cho Windows và bảng điều khiển <Mà Vulkan có thể thay thế trong một số trường hợp.

Tôi không thể giữ các bản cập nhật OpenGL mãi mãi và tôi sẽ không làm thế. Nhưng đó là sở thích của tôi để phát triển.

Tôi muốn cung cấp cho bạn quan điểm người mới bắt đầu đồ họa của tôi về chủ đề này. Điều tôi nhận ra (trong nhiều năm làm kỹ sư trong lĩnh vực khác) là các khái niệm cơ bản là phần quan trọng nhất. Khi bạn đã hiểu rõ về những điều đó, việc học API mới sáng bóng cuối cùng là phần khó nhất. Tôi không biết nếu bạn là một người trẻ tuổi cố gắng lập trình Skyrim mới hoặc nếu bạn đang tìm kiếm một công việc trong lĩnh vực CG.

Tôi nói với bạn những gì tôi nghĩ rằng đó là cách tiếp cận tốt nhất theo quan điểm của tôi để học đồ họa máy tính "như một chuyên gia".

1. Tìm hiểu Đại số tuyến tính và hình học như một pro. Nếu không có điều này, hãy quên bất kỳ API hoặc đồ họa ưa thích nào
2. Mua một cuốn sách hay về đồ họa máy tính (ví dụ: Nguyên tắc cơ bản của đồ họa máy tính )
3. Trong khi bạn nghiên cứu cuốn sách, hãy thiết lập một môi trường lập trình với thứ gì đó cho phép bạn vẽ lên một hình ảnh và thực hiện các thuật toán! Nó có thể là Java 2D hoặc C ++ và SDL hoặc thậm chí Python và Pygame cho những gì nó quan trọng. Ở giai đoạn này, bạn cần có được các bánh răng có kết cấu xoay tròn với nhiều chế độ xem camera và chạy trước khi cố gắng để có được 10000 FPS
4. Bây giờ hãy dùng OpenGL, Vulkan hoặc DirectX và lặp lại ví dụ ưa thích của bạn (xem bên trên).

Bắt đầu lo lắng về hiệu suất trước khi hiểu làm thế nào để vẽ một đường cũng giống như lo lắng về tính khí động học của chiếc xe của bạn trước khi có giấy phép lái xe.

Tôi tự học trong C ++ mà không có sự giáo dục chính thức nào và trong suốt 15 năm qua tôi đã học cả OpenGL 1.0 cho đến OpenGL hiện đại và DirectX 9c, 10 và 11. Tôi chưa tham gia DirectX 12 và tôi muốn hãy thử tay của tôi tại Vulkan. Tôi chỉ hoàn thành một vài hướng dẫn cơ bản để vẽ một hình tam giác đơn giản hoặc một khối xoay đơn giản với Vulkan. Như với DirectX 11 và OpenGL 3.3+, tôi đã viết Công cụ trò chơi 3D hoạt động hoàn toàn và thậm chí sử dụng chúng Công cụ để xây dựng các trò chơi đơn giản.

Tôi sẽ phải nói rằng nó phụ thuộc vào môi trường chung của người đang học. Nếu bạn mới tham gia vào Lập trình đồ họa 3D, tôi sẽ nói rằng những người mới bắt đầu nhảy vào OpenGL hoặc DirectX 11 vì có rất nhiều hướng dẫn, tài nguyên, ví dụ và các ứng dụng đang hoạt động ngoài kia. Học đồ họa 3D không có nghĩa là một môn học dễ dàng.

Nếu chúng ta trừu tượng ra khỏi khía cạnh lập trình của nó và chỉ tập trung vào khái niệm loại kỹ thuật nào được sử dụng liên quan đến các cấp độ toán học khác nhau dẫn đến các tập dữ liệu và cấu trúc dữ liệu và thuật toán; có rất nhiều điều mà bạn phải biết và hiểu trước tiên trước khi bạn thậm chí có thể cố gắng xây dựng Công cụ trò chơi 3D hoặc sử dụng một công cụ hiện có một cách hiệu quả.

Bây giờ nếu bạn đã hiểu tất cả toán học và lý thuyết đằng sau nó và bạn có một số kinh nghiệm lập trình, bạn có thể sử dụng các API, Thư viện và Ứng dụng đã có như Unity hoặc Unreal Engine và chỉ cần viết mã nguồn và tập lệnh bạn cần để ứng dụng của bạn hoạt động. .

Vì vậy, từ sự hiểu biết của riêng tôi và cách mà tôi thấy nó là thế này nếu bạn đang muốn xây dựng một trò chơi nhanh chỉ vì mục đích xây dựng một trò chơi; đi với các công việc khung đã có sẵn sẽ làm cho thời gian sản xuất của bạn nhỏ hơn nhiều. Mặt khác, nếu bạn muốn hiểu hoạt động bên trong về cách thức Công cụ trò chơi / Công cụ vật lý / Công cụ hoạt hình và mô phỏng trò chơi được thiết kế và muốn tự xây dựng, thì đây là nơi bạn có thể lựa chọn giữa việc chọn API như DirectX, OpenGL hoặc Vulkan. Một trong những yếu tố quyết định ở đây cũng sẽ là kiến ​​thức lập trình hiện có của bạn. Ý tôi là điều này là nếu bạn không biết gì về các cuộc gọi đa luồng, cuộc gọi đồng bộ và cuộc gọi không đồng bộ, hàng rào bộ nhớ, cuộc đua dữ liệu, ngữ nghĩa và song song (lập trình song song),

Tôi đề cập đến điều này bởi vì nếu bạn không biết cách quản lý bộ nhớ của mình cùng với các luồng và thời gian truy cập; Vulkan sẽ cắn bạn trong ass! Trong đó OpenGL và DirectX sẽ nắm trong tay bạn thông qua việc tiêu thụ nhiều năng lượng CPU hơn.

Bây giờ nếu trình độ kiến ​​thức lập trình của bạn ở mức khá, và bạn có các nền tảng toán học sau đây bao gồm tất cả các cấp độ Đại số, Hình học, Lượng giác, Đại số Boolean, Xác suất, Thống kê, Đại số dựa trên Ma trận, Ma trận I, II, .... Infinty (lol). Phép tính véc tơ, Đại số tuyến tính, Hệ thống phương trình tuyến tính, Hình học phân tích với Phép tính véc tơ tính toán đa biến, Lý thuyết số và tập hợp, Tập dữ liệu và cấu trúc, Phân tích tính toán, Thiết kế tính toán và thuật toán. Sau đó, bạn có thể đi vào các khái niệm về những gì nó cần để tạo ra một công cụ trò chơi thực tế và điều này là không có bất kỳ phương pháp Toán học ứng dụng hoặc bất kỳ phương trình Vật lý nào bạn cần. Khi bạn có nền tảng đó và đủ kinh nghiệm lập trình, đặc biệt là quản lý bộ nhớ và số học con trỏ, bạn có thể bắt đầu xây dựng Công cụ trò chơi của mình.

Vì vậy, vấn đề ở đây là bạn phải hiểu tất cả các khía cạnh của những gì nó cần để tạo ra một Game Engine để thực hiện lập trình đồ họa nâng cao. Nếu bạn chỉ làm đồ họa 2D thì cuộc sống không quá khó vì bạn có thể làm điều đó trong Python mà không cần bất kỳ API nào đã nói ở trên! Nhưng nếu bạn muốn nghiêm túc và thiết kế một Game Engine đầy sức mạnh, mạnh mẽ với nhiều bộ tính năng, thì lựa chọn ở đây sẽ là C hoặc C ++ và sử dụng OpenGL, Direct X hoặc Vulkan. Bất cứ ai trong số họ sẽ tốt thôi. Bây giờ nếu bạn đang xây dựng Engine từ Scratch và bạn đang tìm kiếm Engine chạy "hiệu quả" nhất với ít chi phí tài nguyên nhất thì bạn sẽ muốn chọn Vulkan. Nhưng nếu bạn đi theo con đường này, ít nhất bạn nên biết tất cả mọi thứ mà tôi đã đề cập ở trên và một số!

Vì vậy, như bạn có thể thấy Vulkan không thực sự hướng đến các lập trình viên mới bắt đầu trong lĩnh vực này. Bạn phải có kiến ​​thức sâu rộng về tất cả các toán học, mô hình lập trình, tất cả các loại tập dữ liệu và thuật toán khác nhau bao gồm phân luồng, đồng bộ hóa bộ nhớ, lập trình song song. Và thậm chí sau đó chỉ để ứng dụng tải một hình tam giác 2D đơn giản lên màn hình. Những gì có thể được thực hiện trong khoảng 100 dòng mã trong OpenGL hoặc 250 dòng mã trong DirectX cần gần 1.000 dòng mã trong Vulkan!

Vulkan để mọi thứ tùy thuộc vào bạn vì bạn chịu trách nhiệm cho tất cả các khía cạnh về cách bạn đang sử dụng Vulkan trong ứng dụng của mình. Không có nắm tay, nó không cản trở bạn, nó sẽ cho phép bạn tự bắn vào chân mình hoặc cho phép bạn treo cổ tự mua một chiếc thòng lọng đệ quy!

Bây giờ điều này không có nghĩa là những người mới bắt đầu hoặc những người chưa quen với lĩnh vực này không nên học Vulkan, nhưng điều tôi muốn gợi ý cho họ là: Trước tiên hãy tìm hiểu đủ về OpenGL và DirectX để làm ướt chân bạn để xem cách ứng dụng cơ bản được cấu trúc chỉ để hiển thị một hình tam giác đơn giản hoặc khối xoay. Làm quen với API của họ và các mẫu cấu trúc định kỳ của họ. Trong khi biết rằng bạn có thể học Vulkan ở bên cạnh Song song thì bằng cách này bạn có thể thấy cách ba người thực hiện cùng một nhiệm vụ, nhưng biết cách họ thực hiện khác nhau, sau đó bạn cũng có thể so sánh kết quả giữa các API khác nhau và từ ở đó bạn có thể đưa ra lựa chọn ưu tiên cho bạn. Phương pháp này cũng sẽ cung cấp cho bạn một công cụ khác trong hộp công cụ của bạn và thậm chí bạn có thể viết ứng dụng của mình để hỗ trợ cả 3 và có "

Cuối cùng, tất cả tùy thuộc vào người đó để chọn con đường nào họ muốn đi, và từ đó thành công của họ sẽ được quyết định bởi sự cống hiến, học tập không ngừng, làm việc chăm chỉ, thử nghiệm và sai lầm, và quan trọng nhất là thất bại của họ. Nếu bạn không thất bại thì bạn không thành công! Bạn chỉ thành công nếu bạn thất bại, tìm thấy (các) lỗi của mình, sửa chúng, tiếp tục và nhận lại và làm lại từ đầu!

Trước tiên, bạn nên học OpenGL, vì đó là tiêu chuẩn cho Đồ họa, trên rất nhiều nền tảng.

Ngay cả khi có một thư viện mới hơn, hiểu những điều cơ bản và làm việc với một ngôn ngữ được sử dụng trên toàn ngành, thì rất quan trọng ... Đặc biệt là vì Vulkan sẽ không được sử dụng trong các Công ty lớn trong một thời gian.

1. Không ai muốn thích nghi ngay lập tức và kết thúc với một Thư viện / Khung không ổn định.

2. Họ sẽ cần phải thuê / đào tạo lại các lập trình viên Open-GL hiện tại của họ và không cần phải làm vậy.

Ngoài ra, tôi đã nghe nói rằng OpenGL và Vulkan, không hoàn toàn giống nhau. Tôi nghe Vulkan là một API cấp thấp hơn và gần với mã máy hơn OpenGL.

Câu trả lời này tôi vừa tìm thấy dường như có rất nhiều thông tin tuyệt vời

https://gamedev.stackexchange.com/questions/96014/what-is-vulkan-and-how-does-it-differ-from-opengl

Một điều khác cần xem xét là vấn đề xảy ra với OpenGL 1.

OpenGL 1 thành OpenGL 2 có những thay đổi CHÍNH và vì nhiều người đang sử dụng OpenGL1 và phần cứng hỗ trợ nó, nên cần phải thực hiện tính tương thích ngược nặng nề trong một số ứng dụng / công cụ và đôi khi các nhà phát triển thực sự đau đớn khi tiếp tục hỗ trợ nó. .

Bên cạnh sự hỗ trợ, ngôn ngữ thay đổi rất nhiều, đến nỗi bạn phải học những thứ mới.

Điều này đã xảy ra với các khung như JavaFX (từ 1.x đến 2.x) và Play! Khung (Cũng 1.x đến 2.x). Hoàn thành các thay đổi đối với khung, nghĩa là chúng ta phải học lại ... mọi thứ ...

Vì vậy, về cơ bản những gì bạn nên làm là đợi cho đến khi Vulkan ổn định. Điều đó có nghĩa là chờ cho đến khi có lẽ là bản vá 2.0. CNTT không có nghĩa là bạn không thể tìm hiểu về những điều cơ bản của Vulkan, nhưng chỉ cần biết điều này có thể thay đổi. Tôi cho rằng một nhóm như Kronos sẽ cung cấp API rất ổn định ngay từ đầu, đặc biệt là vì có nhiều kỹ sư Nvidia và AMD làm việc trên Vulkan, bao gồm một người Nvidia cao cấp giám sát dự án rõ ràng, cũng như Cơ sở của Mantle; tuy nhiên, giống như bất kỳ phần mềm nào, chúng tôi, các lập trình viên sẽ thấy nó hoạt động tốt như thế nào ngay từ đầu, nhưng nhiều người cảnh giác và chờ đợi xem điều gì sẽ xảy ra.