Haruskah programmer grafis baru belajar Vulkan daripada OpenGL?


53

Dari wiki : "Vulkan API awalnya disebut sebagai 'inisiatif OpenGL generasi berikutnya' oleh Khrono", dan itu adalah "upaya mendesain ulang dasar-dasar untuk menyatukan OpenGL dan OpenGL ES menjadi satu API umum yang tidak akan mundur. kompatibel dengan versi OpenGL yang ada ".

Jadi haruskah mereka yang sekarang masuk ke pemrograman grafis lebih baik dilayani untuk belajar Vulkan daripada OpenGL? Tampaknya mereka akan melayani tujuan yang sama.


1
Jika Anda dapat melakukan sesuatu dalam satu API, Anda dapat melakukannya dengan API lainnya, cara melakukannya tergantung pada API.
A --- B

Jawaban:


33

Sulit!

Ini sepertinya seperti bertanya "Haruskah programmer baru belajar C ++ daripada C," atau "Haruskah seniman baru belajar lukisan digital daripada lukisan fisik."

Terutama karena itu TIDAK kompatibel ke belakang, programmer grafis akan bodoh untuk mengecualikan API grafik yang paling umum di industri, hanya karena ada yang baru. Selain itu, OpenGL melakukan hal yang berbeda secara berbeda. Sangat mungkin bahwa perusahaan akan memilih OpenGL daripada Vulkan, terutama di awal permainan ini, dan perusahaan itu tidak akan tertarik pada seseorang yang tidak mengenal OpenGL, terlepas dari apakah mereka tahu Vulkan atau tidak.

Spesialisasi jarang merupakan keterampilan yang dapat dipasarkan.

Bagi mereka yang tidak perlu memasarkan keterampilan mereka, seperti pengembang indie, itu akan menjadi LEBIH bodoh untuk menghapus alat dari kotak peralatan mereka. Seorang pengembang indie bahkan lebih tergantung pada fleksibilitas dan mampu memilih mana yang berhasil, lebih dari apa yang didanai. Mengkhususkan diri dalam Vulkan hanya membatasi pilihan Anda.

Spesialisasi jarang merupakan paradigma yang efisien.


2
Jawaban yang bagus, ingatkan saya akan hal ini: elise.com/quotes/heinlein_-_specialization_is_for_insects
Will

7
Analogi C ++ ini tidak tepat. Vulkan adalah API generasi baru yang dikembangkan oleh pencipta OpenGL. C ++ adalah pesaing yang mapan, sebagian besar kompatibel dengan C.
Moby Disk

Spesifik tersebut tidak relevan dengan titik analogi.
mHurley

6
Mengklaim spesialisasi tidak efisien atau tidak dapat dipasarkan adalah sangat naif. Seorang penerjemah yang tahu semua lima kata dalam setiap bahasa yang diucapkan tidak berguna, orang-orang akan menyewa penerjemah yang menguasai (alias berspesialisasi dalam) sejumlah kecil bahasa. Sekarang over- spesialisasi adalah masalah. Seorang penerjemah yang sepenuhnya menguasai satu bahasa dan hanya tahu bahasa itu juga bukan penerjemah yang bermanfaat. Dan devs (indie atau lainnya) harus berhati-hati untuk tidak menghabiskan seluruh waktu mereka mempelajari alat-alat baru. Akhirnya mereka harus benar-benar membuat sesuatu untuk dijual, jangan sampai mereka bangkrut
8bittree

Untuk lebih jelasnya, saya tidak perlu tidak setuju dengan Anda dalam hal OpenGL dan Vulkan, Ini sangat mungkin adalah kasus di mana belajar keduanya bukan hanya Vulkan adalah pilihan yang lebih baik.
8bittree

40

Jika Anda memulai sekarang, dan Anda ingin melakukan pekerjaan GPU (sebagai lawan untuk selalu menggunakan mesin permainan seperti Unity), Anda harus memulai dengan mempelajari Vulkan. Mungkin Anda harus belajar GL nanti juga, tetapi ada beberapa alasan untuk berpikir Vulkan-pertama.

  1. GL dan GLES dirancang bertahun-tahun yang lalu, ketika GPU bekerja sangat berbeda. (Perbedaan yang paling jelas adalah panggilan mode-langsung menggambar vs ubin dan perintah antrian.) GL mendorong Anda untuk berpikir dalam gaya mode-langsung, dan memiliki banyak penggerusan warisan. Vulkan menawarkan model pemrograman yang jauh lebih dekat dengan cara kerja GPU kontemporer, jadi jika Anda mempelajari Vulkan, Anda akan memiliki pemahaman yang lebih baik tentang bagaimana teknologi itu benar-benar bekerja, dan apa yang efisien dan apa yang tidak efisien. Saya melihat banyak orang yang sudah mulai dengan GL atau GLES dan segera masuk ke kebiasaan buruk seperti mengeluarkan panggilan undian terpisah per-objek alih-alih menggunakan VBO, atau lebih buruk lagi, menggunakan daftar tampilan. Sulit bagi programmer GL untuk mencari tahu apa yang tidak lagi dianjurkan.

  2. Jauh lebih mudah untuk berpindah dari Vulkan ke GL atau GLES daripada sebaliknya. Vulkan membuat eksplisit banyak hal yang disembunyikan atau tidak dapat diprediksi dalam GL, seperti kontrol concurrency, berbagi, dan rendering state. Ini mendorong banyak kerumitan dari driver ke aplikasi: tetapi dengan melakukan itu, ia memberikan kontrol ke aplikasi, dan membuatnya lebih mudah untuk mendapatkan kinerja yang dapat diprediksi dan kompatibilitas antara vendor GPU yang berbeda. Jika Anda memiliki beberapa kode yang berfungsi di Vulkan, cukup mudah untuk port itu ke GL atau GLES, dan Anda berakhir dengan sesuatu yang menggunakan kebiasaan GL / GLES yang baik. Jika Anda memiliki kode yang berfungsi dalam GL atau GLES, Anda hampir harus mulai lagi untuk membuatnya bekerja secara efisien di Vulkan: terutama jika itu ditulis dalam gaya warisan (lihat poin 1).

Awalnya saya khawatir bahwa Vulkan jauh lebih sulit untuk diprogram untuk melawan, dan bahwa sementara itu tidak apa-apa untuk pengembang berpengalaman di perusahaan besar, itu akan menjadi penghalang besar bagi indie dan penggemar. Saya mengajukan pertanyaan ini kepada beberapa anggota Kelompok Kerja, dan mereka mengatakan mereka memiliki beberapa poin data dari orang-orang yang mereka ajak bicara yang sudah pindah ke Vulkan. Orang-orang ini berkisar dari pengembang di Epic yang bekerja pada integrasi UE4 hingga pengembang game penghobi. Pengalaman mereka adalah bahwa memulai (yaitu mendapatkan satu segitiga di layar) melibatkan mempelajari lebih banyak konsep dan memiliki kode pelat yang lebih panjang, tetapi itu tidak terlalu rumit, bahkan untuk India. Tetapi setelah mencapai tahap itu, mereka merasa jauh lebih mudah untuk membangun aplikasi yang nyata dan dapat dikirim, karena (a) perilaku jauh lebih dapat diprediksi antara implementasi vendor yang berbeda, dan (b) mencapai sesuatu yang berkinerja baik dengan semua efek yang dihidupkan tidak melibatkan banyak trial-and-error. Dengan pengalaman dari pengembang nyata ini, mereka meyakinkan saya bahwa pemrograman melawan Vulkan dapat dilakukan bahkan untuk pemula dalam bidang grafis, dan bahwa keseluruhan kerumitannya kurang setelah Anda melewati tutorial dan mulai membangun demo atau aplikasi yang dapat Anda berikan kepada orang lain.

Seperti yang orang lain katakan: GL tersedia di banyak platform, WebGL adalah mekanisme pengiriman yang bagus, ada banyak perangkat lunak yang ada yang menggunakan GL, dan ada banyak pengusaha yang mempekerjakan untuk keterampilan itu. Akan ada sekitar untuk beberapa tahun ke depan sementara Vulkan landai dan mengembangkan ekosistem. Karena alasan ini, Anda akan bodoh untuk mengesampingkan belajar GL sepenuhnya. Meski begitu, Anda akan memiliki waktu yang lebih mudah dengannya, dan menjadi pemrogram GL yang lebih baik (dan pemrogram GPU yang lebih baik secara umum), jika Anda memulai dengan sesuatu yang membantu Anda memahami GPU, alih-alih memahami cara kerjanya 20 tahun yang lalu.

Tentu saja, ada satu opsi lagi. Saya tidak tahu apakah ini relevan bagi Anda secara khusus, tetapi saya merasa saya harus mengatakannya untuk pengunjung lain.

Untuk menjadi pengembang game indie, atau desainer game, atau untuk membuat pengalaman VR, Anda tidak perlu belajar Vulkan atau GL. Banyak orang memulai dengan mesin permainan (Unity atau UE4 sedang populer saat ini). Menggunakan mesin seperti itu akan membuat Anda fokus pada pengalaman yang ingin Anda ciptakan, alih-alih teknologi di belakangnya. Ini akan menyembunyikan perbedaan antara GL dan Vulkan dari Anda, dan Anda tidak perlu khawatir tentang yang didukung pada platform Anda. Ini akan membuat Anda belajar tentang koordinat 3D, transformasi, pencahayaan, dan animasi tanpa harus berurusan dengan semua detail kasar sekaligus. Beberapa game atau studio VR hanya bekerja di mesin, dan mereka tidak memiliki ahli GL penuh waktu sama sekali. Bahkan di studio yang lebih besar yang menulis mesin sendiri, orang-orang yang melakukan pemrograman grafis adalah minoritas,

Mempelajari detail cara berinteraksi dengan GPU tentu saja merupakan keterampilan yang berguna, dan keterampilan yang akan dihargai banyak pengusaha, tetapi Anda seharusnya tidak merasa harus belajar untuk masuk ke pemrograman 3D; dan bahkan jika Anda mengetahuinya, itu tidak selalu menjadi sesuatu yang Anda gunakan setiap hari.


2
Saya agak tidak setuju. Vulkan (dan DX12) telah terbukti sangat sulit diimplementasikan, untuk pengembang yang berpengalaman . Dengan semua kekuatan yang diberikan Vulkan kepada Anda, sangat mudah untuk menembak diri sendiri di kaki. Selain itu, Vulkan membutuhkan kode boilerplate lebih banyak. Untuk seseorang yang baru belajar tentang pemrograman GPU, saya cenderung berpikir bahwa Vulkan akan sangat luar biasa.
RichieSams

2
@RichieSams Saya tidak berpikir Anda bermaksud "menerapkan". Hanya vendor GPU yang harus mengimplementasikan Vulkan, dan ini jauh lebih mudah daripada menerapkan OpenGL. (Percayalah, saya sudah melakukannya!) Tetapi dengan asumsi Anda bermaksud sulit untuk diintegrasikan atau diprogram melawan, saya telah menambahkan paragraf dengan beberapa informasi yang saya pelajari dari Vulkan WG.
Dan Hulme

Benar. Implement mungkin merupakan pilihan kata yang buruk. Maksud saya 'menggunakan' dalam program Anda. Tapi saya suka hasil edit Anda. Baiklah
RichieSams

@DanHulme - Saya terkejut dengan komentar Anda "GL mendorong Anda untuk berpikir dalam gaya mode langsung". Saya pikir itu hanya berlaku untuk versi OpenGL awal ?
ToolmakerSteve

1
@ToolmakerSteve OpenGL WG telah melakukan banyak pekerjaan untuk menambahkan concurrency dan batched wrote, sehingga Anda dapat mengekspresikan program Anda dengan cara yang cocok untuk penerapan tiling / deferred Tapi itu masih fondasi yang ditetapkan pada zaman mode segera, itulah sebabnya orang-orang memutuskan awal yang baru di Vulkan diperlukan. Dan saya masih melihat banyak pengguna baru mulai dengan GL dan membentuk model mental mode langsung tentang bagaimana implementasi bekerja.
Dan Hulme

26

Mempelajari pemrograman grafis lebih dari sekadar mempelajari API. Ini tentang mempelajari cara kerja grafik. Transformasi vertex, model pencahayaan, teknik bayangan, pemetaan tekstur, rendering yang ditangguhkan, dan sebagainya. Ini sama sekali tidak ada hubungannya dengan API yang Anda gunakan untuk mengimplementasikannya.

Jadi pertanyaannya adalah ini: apakah Anda ingin belajar cara menggunakan API? Atau Anda ingin belajar grafik ?

Untuk melakukan hal-hal dengan grafik akselerasi perangkat keras, Anda harus belajar cara menggunakan API untuk mengakses perangkat keras itu. Tetapi begitu Anda memiliki kemampuan untuk berinteraksi dengan sistem, pembelajaran grafik Anda berhenti berfokus pada apa yang dilakukan API untuk Anda dan sebaliknya berfokus pada konsep grafis. Pencahayaan, bayangan, pemetaan benjolan, dll.

Jika tujuan Anda adalah mempelajari konsep grafik, waktu yang Anda habiskan bersama API adalah waktu Anda tidak menghabiskan belajar konsep grafik . Cara mengompilasi shader tidak ada hubungannya dengan grafik. Tidak juga cara mengirim seragam, cara mengunggah data titik ke buffer, dll. Ini adalah alat, dan alat penting untuk melakukan pekerjaan grafis.

Tapi mereka sebenarnya bukan konsep grafis. Mereka adalah sarana untuk mencapai tujuan.

Dibutuhkan banyak pekerjaan dan pembelajaran dengan Vulkan sebelum Anda dapat mencapai titik di mana Anda siap untuk mulai belajar konsep grafis. Melewati data ke shader memerlukan manajemen memori eksplisit dan sinkronisasi akses secara eksplisit. Dan seterusnya.

Sebaliknya, mencapai titik itu dengan OpenGL membutuhkan lebih sedikit pekerjaan. Dan ya, saya sedang berbicara tentang OpenGL profil inti berbasis shader yang modern.

Bandingkan saja apa yang diperlukan untuk melakukan sesuatu yang sederhana seperti membersihkan layar. Dalam Vulkan, ini membutuhkan setidaknya beberapa pemahaman tentang sejumlah besar konsep: buffer perintah, antrian perangkat, objek memori, gambar, dan berbagai konstruksi WSI.

Dalam OpenGL ... itu tiga fungsi: glClearColor, glClear, dan platform-spesifik pertukaran buffer panggilan. Jika Anda menggunakan OpenGL yang lebih modern, Anda bisa mendapatkannya menjadi dua: glClearBufferuivdan menukar buffer. Anda tidak perlu tahu apa itu framebuffer atau dari mana gambar itu berasal. Anda menghapusnya dan menukar buffer.

Karena OpenGL menyembunyikan banyak hal dari Anda, dibutuhkan usaha yang jauh lebih sedikit untuk sampai ke titik di mana Anda sebenarnya belajar grafis daripada belajar antarmuka ke perangkat keras grafis.

Lebih jauh, OpenGL adalah (relatif) API yang aman. Ini akan mengeluarkan kesalahan ketika Anda melakukan sesuatu yang salah, biasanya. Vulkan tidak. Meskipun ada lapisan debugging yang dapat Anda gunakan untuk membantu, inti Vulkan API tidak akan memberi tahu Anda apa-apa kecuali ada kesalahan perangkat keras. Jika Anda melakukan kesalahan, Anda bisa mendapatkan rendering sampah atau merusak GPU.

Ditambah dengan kompleksitas Vulkan, menjadi sangat mudah untuk secara tidak sengaja melakukan hal yang salah. Lupa untuk mengatur tekstur ke tata letak yang tepat dapat bekerja di bawah satu implementasi, tetapi tidak yang lain. Melupakan titik sinkronisasi mungkin kadang-kadang berhasil, tetapi kemudian tiba-tiba gagal tanpa alasan. Dan seterusnya.


Semua yang dikatakan, ada lebih banyak belajar grafik daripada belajar teknik grafis. Ada satu area khusus di mana Vulkan menang.

Kinerja grafis .

Menjadi seorang programmer grafis 3D biasanya memerlukan beberapa ide tentang bagaimana mengoptimalkan kode Anda. Dan di sinilah OpenGL menyembunyikan informasi dan melakukan hal-hal di belakang Anda menjadi masalah.

Model memori OpenGL sinkron. Implementasi diizinkan untuk mengeluarkan perintah secara asinkron selama pengguna tidak dapat membedakannya. Jadi, jika Anda merender ke beberapa gambar, lalu mencoba membaca darinya, implementasinya harus mengeluarkan peristiwa sinkronisasi eksplisit antara dua tugas ini.

Tetapi untuk mencapai kinerja di OpenGL, Anda harus tahu bahwa implementasi melakukan ini, sehingga Anda dapat menghindarinya . Anda harus menyadari di mana implementasinya diam-diam mengeluarkan peristiwa sinkronisasi, dan kemudian menulis ulang kode Anda untuk menghindarinya sebanyak mungkin. Tetapi API itu sendiri tidak membuat ini jelas; Anda harus mendapatkan pengetahuan ini dari suatu tempat.

Dengan Vulkan ... Anda yang harus mengeluarkan acara sinkronisasi itu. Oleh karena itu, Anda harus menyadari fakta bahwa perangkat keras tidak menjalankan perintah secara serempak. Anda harus tahu kapan Anda perlu mengeluarkan acara-acara itu, dan karena itu Anda harus sadar bahwa mereka mungkin akan memperlambat program Anda. Jadi Anda melakukan semua yang Anda bisa untuk menghindarinya.

API eksplisit seperti Vulkan memaksa Anda untuk membuat keputusan kinerja semacam ini. Dan karena itu, jika Anda mempelajari Vulkan API, Anda sudah memiliki ide bagus tentang hal-hal apa yang akan lambat dan hal-hal apa yang akan cepat.

Jika Anda harus melakukan pekerjaan framebuffer yang memaksa Anda untuk membuat renderpass baru ... kemungkinannya bagus bahwa ini akan lebih lambat daripada jika Anda bisa memasangnya menjadi subpass terpisah dari renderpass. Itu tidak berarti Anda tidak dapat melakukan itu, tetapi API memberi tahu Anda di muka bahwa itu dapat menyebabkan masalah kinerja.

Di OpenGL, API pada dasarnya mengundang Anda untuk mengubah lampiran framebuffer Anda mau tak mau. Tidak ada panduan untuk perubahan mana yang cepat atau lambat.

Jadi dalam hal itu, belajar Vulkan dapat membantu Anda belajar lebih baik tentang cara membuat grafik lebih cepat. Dan itu pasti akan membantu Anda mengurangi overhead CPU.

Masih perlu waktu lebih lama sebelum Anda bisa sampai pada titik di mana Anda dapat mempelajari teknik rendering grafis.


1
Saya senang Anda memposting ini, karena itu membuat beberapa ide yang sangat jelas bahwa saya ragu-ragu untuk mengungkapkan dalam jawaban saya: bahwa mempelajari konsep adalah yang paling penting. Saya pikir di mana kami berbeda adalah Anda mendorong GL karena lebih mudah untuk memulai, sementara saya pikir kemudahan memulai membawa risiko melakukan sesuatu dengan cara lama. Cukup sulit untuk mengetahui dalam GL apa "idiom GL modern", dibandingkan dengan pemrograman dalam gaya lama. Jika tidak ada yang memberitahu Anda untuk menggunakan VAO alih-alih panggilan undian terpisah per primitif, jauh lebih sulit untuk melepaskan kesalahan itu nanti.
Dan Hulme

1
@DanHulme: Ini semua masalah menggunakan materi pembelajaran yang tepat. Ada banyak materi online yang menggunakan idiom modern. Tidak seorang pun boleh mencoba mempelajari grafik hanya dengan membaca referensi manual atau spesifikasi.
Nicol Bolas

Anda membuatnya terdengar sangat mudah! Meski begitu, saya masih melihat pemrogram memulai dalam grafik - beberapa dari mereka sangat kompeten di bidang lain - dan menggunakan fitur warisan dan belajar apa-apa tentang karakteristik kinerja. Sangat sulit untuk membuat kesalahan di Vulkan, karena itu membuat barang-barang mahal terlihat mahal. Bagaimanapun, kita tidak perlu berdebat. Saya setuju dengan poin utama Anda: mempelajari konsep adalah yang paling penting, dan Anda dapat melakukannya tanpa Vulkan atau GL.
Dan Hulme

@DanHulme: " Ini benar-benar sulit untuk mendapatkan salah bahwa dalam Vulkan " Karena Anda terlalu sibuk mendapatkan segala sesuatu yang lain yang salah;) Juga, itu masih cukup mudah untuk mendapatkan kinerja salah dalam Vulkan. Sinkronisasi yang tidak perlu. Hanya menggunakan tata letak gambar "umum". Tidak memanfaatkan subpass. Perubahan pipa yang sering. Dan seterusnya. Belum lagi, vendor yang berbeda bahkan tidak sepakat tentang cara terbaik untuk menggunakan Vulkan.
Nicol Bolas

2
@DanHulme: Adapun betapa mudahnya menggunakan OpenGL modern, saya melakukan yang terbaik untuk membuatnya mudah . Jika orang bersikeras belajar dari situs sampah seperti NeHe, atau dengan membaca dokumentasi acak, itu bukan sesuatu yang bisa dilakukan oleh siapa pun. Anda bisa menuntun kuda ke air, tetapi Anda tidak bisa membuat mereka minum.
Nicol Bolas

7

Daya tarik utama OpenGL (setidaknya bagi saya) adalah ia bekerja pada banyak platform. Saat ini, Vulkan tidak berfungsi di OSX, dan Apple memiliki API yang bersaing bernama Metal. Sangat mungkin bahwa itu akan memakan waktu sebelum Apple mendukung Vulkan, dan ketika mereka melakukannya, dukungan Vulkan hanya dapat sampai pada perangkat keras terbaru mereka. OpenGL sudah mendukung sebagian besar perangkat keras, dan akan terus melakukannya.


Saya berani bertaruh bahwa jika OSX akan mendukung Vulkan hanya akan mendukung sebagian kecil dari itu, dan itu juga akan menjadi api grafis Next Generation untuk browser web, OpenGL masih cara yang lebih mudah untuk digunakan (untuk tingkat tertentu tentu saja) daripada Vulkan, apa yang diperoleh vulkan dalam kesederhanaan dari render pipeline, kehilangan itu dalam penanganan eksplisit banyak hal lainnya
GameDeveloper

1
@DarioOO OpenGL mode langsung adalah cara yang lebih mudah digunakan daripada apa pun yang Anda panggil-hal-itu-tidak-langsung-mode, namun itu tidak disarankan.
user253751

1
@ Gavin: Perlu dicatat bahwa OpenGL versi 4.2 atau lebih tinggi juga tidak didukung di OSX. Jadi jika Anda ingin menggunakan sesuatu yang baru dari OpenGL di OSX, Anda tidak bisa. Dan Apple sangat tidak mungkin untuk mengadopsi versi OpenGL nanti. Platform Apple adalah all-in di Metal, jadi cross-platform adalah cara yang baik.
Nicol Bolas

Apple tidak akan pernah mendukung Vulkan kecuali mereka dipaksa, dan ekonomi itu cukup sederhana. Dengan masuk ke dalam Metal, mereka berharap dapat mengunci pengembang game mobile yang membutuhkan lebih dari yang bisa ditawarkan GLES2 tetapi tidak memiliki sumber daya untuk menulis game mereka untuk Vulkan dan Metal. Mereka siap mengorbankan ekosistem game Mac yang kecil untuk ini, terutama jika pengembang dev iOS juga merilis di Mac App Store.
Jonathan Baldwin

Vulkan sekarang berfungsi di macOS (sebelumnya OS X): moltengl.com
Alexander

4

Itu tergantung pada apa yang ingin Anda lakukan. Jika Anda ingin mempelajari pemrograman grafis hanya untuk diri Anda sendiri, tidak masalah apa yang Anda pilih.

Jika Anda berpikir tentang pekerjaan profesional, saya sarankan Vulkan. Ini lebih dekat ke perangkat keras dan saya pikir pengetahuan tentang apa yang dilakukan perangkat keras penting bagi programmer grafis.

Vulkan lebih dekat ke perangkat keras karena OpenGL melakukan banyak hal di bawah kap yang di Vulkan Anda lakukan secara manual, seperti mengeksekusi perintah antrian. Juga manajemen memori hingga aplikasi bukan driver. Anda perlu khawatir tentang mengalokasikan memori untuk uniforms(variabel yang Anda berikan dari CPU ke GPU), tentang pelacakan mereka. Anda memiliki lebih banyak hal yang perlu dikhawatirkan tetapi juga memberikan lebih banyak kebebasan dalam penggunaan memori. Ini bisa terdengar menakutkan dan luar biasa tetapi sebenarnya tidak. Hanya API berikutnya yang perlu Anda pelajari.

Memahami hal-hal ini juga akan membantu dalam memahami cara kerja GPU. Apa yang memungkinkan Anda melakukan beberapa optimasi baik pada Vulkan dan OpenGL.

Dan satu hal lagi yang muncul di benak saya, jika Anda mulai belajar pemrograman grafis mungkin ketika Anda mencari pekerjaan sebagai salah satu Vulkan akan lebih populer (mungkin lebih populer daripada OpenGL). Juga, sejauh yang saya tahu sebagian besar perusahaan yang menggunakan beberapa grafik API menulis fungsi sendiri di sekitarnya sehingga ada kemungkinan bahwa pada pekerjaan Anda tidak akan menulis di OpenGL atau di Vulkan tetapi pengetahuan tentang GPU akan selalu berguna.


2

Saya telah "masuk ke" pemrograman grafis selama beberapa bulan sekarang.

Saat ini saya masih berada di Sekolah Menengah, dan saya dapat memberi tahu Anda bahwa saya hampir selalu ingin mengembangkan aplikasi lintas platform. Ini sebenarnya masalah nomor satu saya dengan Vulkan - Tidak dikembangkan untuk bekerja pada semua platform. Saya bekerja dengan OpenGL di Jawa dan memiliki lebih dari 6 bulan.

Masalah lain yang saya miliki adalah dengan klaim Vulkan adalah bagaimana klaimnya menjadi lebih baik. Sementara OpenGL tentu tidak terlalu sering memperbarui situs web mereka. Mereka terus-menerus merilis pembaruan dan saya selalu menantikan pembaruan baru yang berjalan lebih cepat atau bekerja lebih baik dengan perangkat keras baru.

Yang sedang berkata, sementara saya kebanyakan bekerja dengan OpenGL saya mengerti prinsip-prinsip dasar DirectX dan Vulkan. Walaupun saya tidak bekerja dengan mereka secara luas, terutama Vulkan karena sangat sulit untuk dipelajari dan tidak terstruktur dengan baik untuk pemrograman seperti OpenGl dan DirectX.

Terakhir, saya ingin menambahkan bahwa mengkhususkan diri dalam satu bidang seperti kebanyakan saya menggunakan Java dan OpenGL tidak standalone yang luar biasa berharga. Jika saya ingin mendapatkan pekerjaan di perusahaan yang membuat game, sebagian besar OpenGL hanya akan digunakan untuk membuat game untuk pengembangan Linux dan Android dan mungkin OSX. DirectX untuk Windows dan Konsol <Yang Vulkan dapat ganti dalam beberapa kasus.

Saya tidak bisa menunggu pembaruan OpenGL selamanya, dan saya tidak mau. Tapi itu pilihan saya untuk berkembang.


" Masalah lain yang saya miliki adalah dengan klaim Vulkan adalah bagaimana klaimnya menjadi lebih baik. " Vulkan tidak mengklaim sebagai apa pun. Itu hanya API; itu tidak bisa membuat klaim.
Nicol Bolas

Anda sadar bahwa Vulkan dan GL dibuat oleh sebagian besar orang yang sama?
Dan Hulme

Ya saya lakukan. Saya masih lebih suka GL
Winter Roberts

2

Saya ingin memberi Anda perspektif pemula grafis saya pada subjek. Apa yang saya sadari (bertahun-tahun bekerja sebagai insinyur di bidang lain) adalah bahwa konsep dasar adalah bagian terpenting. Setelah Anda memiliki pemahaman yang kuat tentang hal itu, mempelajari API baru yang mengkilap terakhir adalah bagian yang paling sulit. Saya tidak tahu apakah Anda seorang hobbiest muda yang mencoba memprogram Skyrim baru atau jika Anda mencari pekerjaan di bidang CG.

Saya memberi tahu Anda apa yang saya pikir itu pendekatan terbaik menurut saya untuk belajar grafik komputer "seperti pro".

  1. Pelajari Aljabar Linier dan geometri seperti pro. Tanpa ini, lupakan API atau gambar mewah
  2. Beli buku bagus tentang grafik komputer (mis. Dasar-dasar grafik komputer )
  3. Saat Anda mempelajari buku ini, atur lingkungan pemrograman dengan sesuatu yang memungkinkan Anda menggambar pada gambar dan mengimplementasikan algoritme! Itu bisa Java 2D atau C ++ dan SDL atau bahkan Python dan Pygame untuk hal yang penting. Pada tahap ini Anda perlu membuat roda gigi bertekstur berputar Anda dengan beberapa tampilan kamera dan berjalan sebelum mencoba untuk mendapatkan 10.000 FPS
  4. Sekarang ambil OpenGL, Vulkan atau DirectX dan ulangi contoh mewah Anda (lihat di atas).

Mulai khawatir tentang kinerja sebelum memahami cara menggambar garis seperti mengkhawatirkan aerodinamika mobil Anda sebelum mendapatkan SIM.


0

Saya belajar sendiri dalam bahasa C ++ tanpa pendidikan formal dan selama 15 tahun terakhir saya telah mempelajari OpenGL 1.0 hingga Modern OpenGL dan DirectX 9c, 10 dan 11. Saya belum masuk ke DirectX 12 dan saya ingin coba tanganku di Vulkan. Saya hanya menyelesaikan beberapa tutorial dasar untuk menggambar segitiga sederhana atau kubus pemintalan sederhana dengan Vulkan. Seperti halnya DirectX 11 dan OpenGL 3.3+, saya telah menulis Mesin Game 3D yang berfungsi penuh dan bahkan menggunakannya untuk membangun game sederhana.

Saya harus mengatakan bahwa itu tergantung pada lingkungan keseluruhan dari orang yang belajar. Jika Anda baru saja memasuki Pemrograman Grafik 3D, saya akan mengatakan bagi pemula untuk beralih ke OpenGL atau DirectX 11 karena ada banyak tutorial, sumber daya, contoh dan aplikasi yang sudah berfungsi di luar sana. Mempelajari Grafik 3D bukanlah subjek yang mudah.

Jika kita abstrak dari aspek pemrograman itu dan hanya fokus pada gagasan tentang teknik apa yang digunakan yang melibatkan berbagai tingkat matematika yang mengarah ke set data dan struktur data dan algoritma; ada banyak yang harus Anda ketahui dan pahami terlebih dahulu sebelum Anda bahkan dapat mencoba membangun Mesin Game 3D atau menggunakan yang sudah ada secara efektif.

Sekarang jika Anda sudah memahami semua teori dan matematika di baliknya dan Anda memiliki pengalaman pemrograman, Anda dapat menggunakan API, Perpustakaan, dan Aplikasi yang sudah ada seperti Unity atau Unreal Engine dan cukup tulis kode sumber dan skrip yang Anda perlukan agar aplikasi Anda berfungsi. .

Jadi dari pemahaman saya sendiri dan cara saya melihatnya adalah ini jika Anda mencari untuk membangun permainan cepat hanya demi membangun permainan; pergi dengan kerangka yang sudah ada yang akan membuat waktu produksi Anda jauh lebih kecil. Di sisi lain, jika Anda ingin memahami cara kerja bagian dalam tentang bagaimana Mesin Game / Mesin Fisika / Mesin Animasi dan Simulator dirancang dan ingin membangunnya sendiri, maka di sinilah Anda memiliki pilihan untuk memilih API seperti DirectX, OpenGL atau Vulkan. Salah satu faktor penentu di sini juga akan menjadi pengetahuan pemrograman Anda saat ini. Yang saya maksud dengan ini adalah jika Anda tidak tahu apa-apa tentang panggilan multi-threading, sinkron dan asinkron, pagar memori, ras data, semaphore, dan paralelisme (pemrograman paralel),

Saya menyebutkan ini karena jika Anda tidak tahu cara mengelola memori dengan benar bersama dengan utas dan waktu akses Anda; Vulkan akan menggigitmu! Di mana OpenGL dan DirectX akan memegang tangan Anda sepenuhnya melalui konsumsi daya CPU yang jauh lebih besar.

Sekarang jika tingkat pengetahuan pemrograman Anda layak, dan Anda memiliki latar belakang matematika berikut yang melibatkan semua tingkat Aljabar, Geometri, Trigonometri, Aljabar Boolean, Probabilitas, Statistik, Vektor - Aljabar berbasis Matriks, Kalkulus I, II, .... Infinty (lol). Vektor Kalkulus, Aljabar Linier, Sistem Persamaan Linier, Geometri Analitik dengan Kalkulus Vektor dari kalkulasi multi-variabel, Teori Angka dan Kumpulan, Kumpulan Data dan Struktur, Analisis Komputasi, Komputasi dan Desain Algoritma. Kemudian Anda dapat masuk ke konsep apa yang diperlukan untuk membuat mesin gim yang sebenarnya dan ini tanpa Matematika Terapan atau persamaan Fisika apa pun yang Anda perlukan. Setelah Anda memiliki latar belakang dan pengalaman pemrograman yang cukup terutama manajemen memori dan aritmatika pointer maka Anda dapat mulai membangun Mesin Game Anda.

Jadi masalahnya di sini adalah Anda harus memahami semua aspek yang diperlukan untuk membuat Mesin Game untuk Melakukan Pemrograman Grafis Tingkat Lanjut. Jika Anda hanya melakukan grafik 2D maka hidup tidak terlalu sulit karena Anda dapat melakukannya dengan Python tanpa API yang disebutkan di atas! Tetapi jika Anda ingin serius dan merancang pembangkit tenaga penuh Game Engine yang kuat dengan banyak set fitur, maka pilihan di sini adalah C atau C ++ dan menggunakan OpenGL, Direct X atau Vulkan. Salah satu dari mereka akan baik-baik saja. Sekarang jika Anda sedang membangun Engine dari Scratch dan Anda sedang mencari Engine yang berjalan paling efisien dengan biaya overhead sumber daya paling sedikit, maka Anda ingin memilih Vulkan. Tetapi jika Anda menempuh rute ini, Anda setidaknya harus tahu semua yang telah saya sebutkan di atas dan beberapa di antaranya!

Jadi seperti yang Anda lihat, Vulkan tidak benar-benar diarahkan untuk programmer pemula di bidang ini. Anda harus memiliki pengetahuan luas tentang semua matematika, paradigma pemrograman, semua jenis set data dan algoritma yang berbeda termasuk threading, sinkronisasi memori, pemrograman paralel. Itupun hanya untuk mendapatkan aplikasi memuat segitiga 2D sederhana ke layar. Apa yang dapat dilakukan di sekitar 100 baris kode di OpenGL atau 250 baris kode di DirectX mengambil hampir 1.000 baris Kode di Vulkan!

Vulkan menyerahkan semuanya kepada Anda karena Anda bertanggung jawab atas semua aspek tentang bagaimana Anda menggunakan Vulkan dalam aplikasi Anda. Tidak ada pegangan tangan, itu tidak menghalangi Anda, itu akan memungkinkan Anda untuk menembak diri Anda sendiri atau membiarkan Anda menggantung diri Anda membeli jeratan rekursif!

Sekarang ini bukan untuk mengatakan bahwa pemula atau mereka yang baru di bidang ini seharusnya tidak belajar Vulkan, tetapi apa yang akan saya sarankan untuk mereka adalah ini: Pertama Pelajari cukup OpenGL dan atau DirectX untuk membuat kaki Anda basah untuk melihat bagaimana aplikasi dasar disusun hanya untuk membuat segitiga sederhana atau kubus pemintalan. Biasakan diri dengan API dan pola strukturnya yang berulang. Sambil belajar bahwa Anda bisa belajar Vulkan di sisi dalam Paralel maka dengan cara ini Anda dapat melihat bagaimana masing-masing dari ketiganya menyelesaikan tugas yang sama, tetapi tahu bagaimana mereka melakukannya secara berbeda, maka Anda juga dapat membandingkan hasil antara API yang berbeda dan dari di sana Anda kemudian dapat membuat pilihan yang disukai Anda. Metode ini juga akan memberi Anda alat lain di kotak alat Anda, dan Anda bahkan dapat menulis aplikasi Anda untuk mendukung ketiganya dan memiliki "

Pada akhirnya tergantung pada orang itu untuk memilih rute mana yang ingin mereka turuni, dan dari sana kesuksesan mereka akan ditentukan oleh dedikasi, studi terus-menerus, kerja keras, coba-coba, dan yang paling penting kegagalan mereka. Jika Anda tidak gagal maka Anda tidak berhasil! Anda hanya berhasil jika Anda gagal, menemukan kesalahan Anda, memperbaikinya, pindah dan bangkit kembali dan melakukannya lagi!


-1

Anda harus mempelajari OpenGL terlebih dahulu, karena itu adalah standar untuk Grafik, di banyak platform.

Bahkan jika ada perpustakaan yang lebih baru, memahami dasar-dasarnya, dan bekerja dengan bahasa yang digunakan di seluruh industri, sangat penting ... Terutama karena Vulkan tidak akan digunakan di Perusahaan Besar untuk sementara waktu.

  1. Tidak ada yang ingin langsung beradaptasi dan akhirnya mengacaukan diri mereka dengan Kerangka / Perpustakaan yang tidak stabil.

  2. Mereka perlu merekrut / melatih ulang programmer Open-GL mereka saat ini, dan tidak perlu.


Juga, saya pernah mendengar bahwa OpenGL, dan Vulkan, tidak persis sama. Saya mendengar Vulkan adalah API tingkat lebih rendah, dan lebih dekat ke kode mesin, daripada OpenGL.

Jawaban yang saya temukan ini sepertinya memiliki banyak info hebat

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


Hal lain yang perlu dipertimbangkan adalah masalah yang terjadi kembali dengan OpenGL 1.

OpenGL 1 ke OpenGL 2 memiliki perubahan besar, dan karena banyak orang menggunakan OpenGL1, dan perangkat keras mendukungnya, ada kompatibilitas mundur yang sangat besar yang perlu diimplementasikan dalam beberapa aplikasi / mesin, dan kadang-kadang sangat menyakitkan bagi para dev untuk tetap mendukungnya .

Selain dukungan, bahasanya banyak berubah, sehingga Anda harus belajar hal baru.

Ini terjadi dengan kerangka kerja seperti JavaFX (dari 1.x ke 2.x) dan Play! Kerangka Kerja (Juga 1.x ke 2.x). Selesaikan perubahan pada kerangka kerja, artinya kita harus mempelajari kembali ... semuanya ...


Jadi intinya yang harus Anda lakukan adalah menunggu sampai Vulkan STABIL. Itu berarti menunggu hingga patch 2.0. Bukan berarti Anda tidak bisa belajar tentang dasar-dasar Vulkan, tetapi ketahuilah ini mungkin berubah. Saya akan berasumsi bahwa kelompok seperti Kronos akan menyediakan API yang sangat stabil sejak awal, terutama karena ada beberapa insinyur Nvidia dan AMD yang bekerja di Vulkan, termasuk orang Nvidia yang lebih tinggi yang mengawasi proyek, dan juga Pangkalan Mantle; Namun, seperti perangkat lunak apa pun, kami para pembuat kode akan melihat seberapa baik kerjanya dari awal, tetapi banyak yang waspada dan menunggu untuk melihat apa yang terjadi.


Vulkan stabil sekarang. Analogi GL 1.0 vs 2.0 Anda tepat. Mulai dengan GL sekarang akan seperti memulai belajar GL 1.0 enam bulan setelah GL 2.0 keluar.
Dan Hulme

1
Vulkan mungkin "stabil" bukan berarti hal-hal tidak akan berubah, ini adalah sifat bahasa, yang saya sajikan 2 perubahan terbaru untuk bahasa dalam beberapa tahun terakhir, jadi bagaimana kita tahu ini tidak akan terjadi pada Vulkan? Anda pada dasarnya mengatakan bahwa belajar OpenGL adalah pemborosan, dan itu salah. Membuatnya seperti OpenGL sudah mati, dan tidak akan digunakan lagi ... Juga salah. Selain itu, saya bukan satu-satunya yang percaya bahwa Vulkan dapat memiliki masalah stabilitas. Mungkin tidak, tetapi dengan bahasa baru, itulah yang Anda cari.
XaolingBao

1
Tentu saja hal-hal akan berubah, dan kelompok kerja sudah bekerja menuju fitur-fitur baru untuk versi spesifikasi berikutnya (ssh, Anda tidak mendengarnya dari saya). Stabil berarti bahwa hal-hal itu akan menambah spesifikasi, dan hal-hal yang Anda pelajari hari ini masih berlaku dua tahun dari sekarang. OTOH, hal-hal yang Anda pelajari tentang GL saat ini sudah merupakan kecocokan yang buruk untuk cara kerja GPU: sama seperti belajar tentang saluran pipa fungsi tetap di dunia shader yang dapat diprogram. Jika Anda membaca jawaban saya, Anda tahu saya pikir belajar GL sekarang tidak berguna. Tetapi "Vulkan terlalu baru" bukanlah alasan yang baik untuk mengabaikannya.
Dan Hulme

1
@Lasagna: " Ini bisa berubah, tidak banyak perusahaan yang langsung beradaptasi untuk menggunakannya " Valve. Epik. Kesatuan. Mereka semua sangat berinvestasi dalam membuat mesin mereka bekerja di Vulkan. CryTech dan Id juga tidak mengabaikannya. Jadi pernyataan Anda tidak sepadan dengan fakta.
Nicol Bolas

2
@Lasagna: " Hanya karena diadaptasi menjadi Mesin 3D, bukan berarti perusahaan menginvestasikan proyek mereka ke dalamnya " ... Jadi mesin 3D tidak memenuhi syarat sebagai "proyek"? Apakah DOTA2 dianggap sebagai "proyek"? Karena itu mendapat dukungan untuk Vulkan sekarang . Apakah lini ponsel pintar dan tablet Samsung dianggap sebagai "proyek"? Karena mereka ingin menggabungkannya ke UI. Kenyataannya adalah bahwa banyak orang bersedia "menjadi orang yang menguji platform baru", jika platform itu memberi mereka apa yang mereka butuhkan.
Nicol Bolas
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.