OpenGL/Vulkanスレ Part22©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
クロスプラットフォームの3D API OpenGL 及び次世代のローレベルAPI Vulkan に関する話題を扱うスレッド。
現在の最新バージョンは4.5
https://www.opengl.org/
https://www.khronos.org/vulkan
== OpenGLと一緒に使われるツール&ライブラリ ==
苦労したくなかったらとりあえず入れとけ。
・glx: XからOpenGLを使うためのライブラリ。普通は直接は使わず意識する事はない
・glut: クロスプラットフォームなツールキット。でもさすがに古くさい
・GLFW より新しいマルチプラットフォームなツールキット
・glew: これを入れないと拡張機能が使えないor使いにくい
・glxgears: 歯車が回るベンチマーク。-infoでOpenGLのバージョンが見られる。OpenGLの動作確認はこれで
・glxinfo: 自分の使っているカードのOpenGLの機能が全てリストアップされる。
・OpenTK C#からOpenGLを簡単に使えるようになる。VC#の強力なIntellisenseとあわせてサクサク開発可能。
・OpenSceneGraph: OpenGL を高度に抽象化し、利便性を高めたラッパー。C++ ライブラリ
・OpenGL Mathematics (GLM): GLSL 文法ライクの C++ 数学ライブラリ
== チュートリアルサイト ==
床井研究室: http://marina.sys.wakayama-u.ac.jp/~tokoi/oglarticles.html
OpenGL de プログラミング: http://wiki.livedoor.jp/mikk_ni3_92/
NeHe: http://nehe.gamedev.net/
Tutorials for OpenGL 3.3 and later http://www.opengl-tutorial.org/
Learning Modern 3D Graphics Programming http://www.arcsynthesis.org/gltut/
== 前スレ ==
OpenGLスレ Part21
http://peace.2ch.net/test/read.cgi/tech/1409581958/
== 関連スレ ==
【O3D】HTML5用 3D API WebGL 【Canvas:3D】
http://peace.2ch.net/test/read.cgi/tech/1308761577/
OpenGL 2.0 専用スレ
http://peace.2ch.net/test/read.cgi/tech/1126268759/ VulkanのアプリをMetalで動かすレイヤーはある
Metalは絶対消え去る運命にあるのは間違いない OpenGLでガンヴァロウ
そんなAPIやってられん >>306
なんか勘違いしてそうだけど、環境作る側の「環境」って組み込み機器とかの事だぞ
GPUは無いけどOpenGL ESを動かしたいとかの特殊な状況で役に立つだろう ラッパーライブラリを作る側はアプリを作る側とOpenGLからしてみれば同じだよ >>311
そのOpenGLの中身をVulkanにしよう動きが既に出ている
効率を上げないとしんどいインディーがすごく増えたし
スマホゲームにおいてVulkanを積極的にやらんとMetal持ってるiOSに負ける >>312
それと、搭載予定のGPUが開発中で実物が無い時に、すでに開発はスタートしてるとかね。 >>314
OpenGLをVulkanで実装したところで効率が良くなるとは思えんが…
むしろ間接的になるから効率は悪くなるだろ
OpenGLは仕様上色々ドライバがチェックすべき事が多いからDrawコールが重いんだろう
Vulkanで実装したところでやるべき事は一緒だ OpenGLはまずコマンドバッファの管理がドライバ任せなのが良くない感じ?
テクスチャや頂点バッファ用のメモリ確保とか転送をどうやるかもドライバ次第だしな
モバイルでglTexSubImage2dがやたら遅いとかよくあった
モバイルだと殆どのGPUがタイルベースだけど
この処理もドライバ任せだし
処理結果を取っておいたりも出来ない >>317
コンテキストが一つってのが問題点じゃなかったでしたっけ? コード量が増えるってことはバグも人件費も増えるってことじゃないの
普及するのかね >>318
コンテキストは複数持てるけど
MakeCurrentが同時に一つのスレッドからしか出来なくて
1つのスレッドからしかコマンドを送れないのが問題では
このマルチコアCPUの時代に どうせ使われてないんだから過去の互換性なんか切り捨ててくればよかったのに
使われまくってるDirectXでもやってんのに >>320
結局実行速度が厳しいスマホだからこそ急いで開発しないとマジでiOSに人取られるからなあ
より負荷の高いゲームでどっちが快適に動くかってのを見せられてしまうとなおさら Vulkanは最近のGPUの仕様に合わせて策定されてんだから今後は普通に使われるようになるだろ
時代はどんどん先へ進んでんだよ
プログラマが追い付かなきゃいかんよ >>326
そう思うなら直接使うの諦めてゲームエンジンとかのミドルウェア使えばいいじゃん。それらが対応してれば恩恵受けれるんだし OpenGLもミドルウェア的な物を通じて使う物じゃないのか コード的には退化とか言って
ハードの進化がPGのオナニーに帳消しにされてるのが我慢ならない。
クソみたいに遅いなスクリプト言語は禁止せよ 高級言語のFORTRANから低級言語のCに「退化」したようなもんだろ。 今まで抽象化されてドライバ任せだったメモリ管理とかが、今後はソフトやプログラマが直接管理しなきゃならないから、
直にはついて行けない奴も大勢いるだろ
というか、エンジンや環境自体を開発しているようなハイエンドな連中以外は環境が整うまで待ちだろ つうか赤本早くしてくれ…(一応10月発売予定にはなってる) そこだよね
どこまで対応したドライバが普及するのか 今は泥でGLつついてるんだがjavaでVulkanAPIとかパフォーマンス出なそう
まあ遅い言語でチューニングした方が感コツ掴めそうだから完成したらC++に清書か Intel内蔵GPUでもLinuxだったらIvy Bridge(2012年発売)から対応してるぞ
Windows版だと最近のしか対応しないようだが
NVIDIAも2012年製のから対応してる
↓詳しいことはこれ見れば分かる
https://en.wikipedia.org/wiki/Vulkan_(API) AndroidはAdreno一強だけど500からしか対応しないから今年の最新モデルからだね
PowerVRはかなり古いのから対応してるけどこっちはほぼApple専用だしな… intelの対応が遅いのがな
Macの少し前のでは動かないの確定か・・・ >>339
ハードウェア的にはそこそこ古いものでも対応出来るんだろうがAndroidのSoCベンダーは一度出した製品のドライバー絶対更新しないからな…
Googleすらドライバーのバグを回避するworkaround書いてる程だから グラフィック周りの更新は特に文鎮化の危険あるからな >>337
そもそもAndroidのVulkan APIってNDK前提じゃ? 幸いな事にVulkanはモバイルとデスクトップでAPIに差がないからとりあえずデスクトップで組んでおくのがいいだろうね VulkanのAPIがローレベル過ぎてJavaバインディングを作るのは難しいのかも OpenGLを蹴ってまでのAPIでJava使ったら速度でなくて意味ないじゃん 流れを見るとJava+OpenGL→Java+Vulkanって話でしょ
当然意味はある
あとバインディングもOpenGLより簡単だろう
VulkanAPIは全てXMLで定義されてるからツールに通して作れるはず OpenGLでもややこしいのにこれ以上ややこしくするなよ よくわからないけど
GPUのこと詳しくなればVulkanのほうがわかりやすくなるんじゃね
よくわからないけど 実際そうだと思う。OpenCLを先にやってたらOpenGLは暗黙の了解みたいなのが多くてわけわからなかった。 VulkanをJavaに持っていこうとしても
JNIでやり取りする時のコストがでかくて
低オーバーヘッドの意味がなくなるとかない? SDKサンプルが上がってこないとわかんないな最初に描画手順のコード?渡して
後は頂点渡すだけみたいな感じなら普通に恩恵あるだろうし 複雑なアプリを作ってるとOpenGLはステートを内部でもってるから整合性を保つのが滅茶苦茶面倒になる
Vulkanは外部に置いておけるからその辺は簡単になるだろう
OpenGL→最初簡単だけど後が大変
Vulkan→最初大変だけど後が楽
じゃないか? nvidiaはPCで不利になるから裏でVulkanを普及させたくない意図が見え隠れしてるけど
OpenGLはいい加減古い NVIDIAは無理してVulkanに移行しなくてもOpenGLだけでCPU負荷を減らせる拡張を用意してるだけだ
デベロッパーに優しいんだよ
それとゲームはDirectX12の速度の方が重要じゃないか? Steamの調査だとWindowsが95%以上だけどな スマホは電池の問題があるから意図的に遅くても消費電力少ないCPU使ってるから
PCを超えることはないんだよバーカ 逆にAndroidがWindowsを置き換える
MS帝国の終焉 それ言うならChromeOS(Chromebook)だな
もはやAndroidも包含してんだから AndroidのOpenGLESは正直無茶苦茶で完全にiOSに敗北してるからさっさとVulkanラッパーに移行したい ChromeOSを電話に乗せればよかったんじゃと思う泥は急こしらえっていうか雑だね嫌いじゃないが >>368
Vulkanの薄いAPIすら心配なレベルだからなぁ… AndroidのOpenGLESが無茶苦茶に思えるのは腐ってるドライバのせいだろ
しかもアップデートもされない
Vulkanではそうならないことを願う >>369
ChromeOSに限らずGoogleの出すものは全部雑な感じする vulkanってHLSL使えるらしいからGLSLいらないね ていうか特定のシェーダー言語に捕らわれる必要は無くなったわけだし なんにしろそんな最新ハードまだ持ってないし日本語本もないしOpenGL ES3の方が覚えたい Vulkan実行すると、OSいきなり落ちたりしない?
コーディングしてて即落ちして萎える。 OpenGLみたいにドライバーが実行時エラーを補足しないからな DirectXじゃなくてOpenGL使う意味ってある?OpenGLは研究に使われてるイメージ >>382
DirectXの方が速いはず
やってることは同じ DirectXで書くといずれ動く環境が無くなる可能性があるが
OpenGLはいまだにドライバが1.0のコードが動くように対応している
その違い
だからといって今更begin,end,vertexを使ったコードを書くべきでは全くない
たまに質問見かけたりするけどな >>383-385
使えるAPIもOpenGLの方が少ないイメージあったんだけどあまり変わらないってことか 1から勉強する場合はDirectXとOpenGLとVulkan、どれがいいのん? dxは日本語リファレンスが神
3dに対する情報も多く含み大変勉強になる
俺もdx11を勧める >>388,389
レスありがとう
やっぱ日本語の情報が沢山ある方がやる気にも繋がるよね つうか3DAPIに安定を求めても無駄だ
OpenGLは比較的安定してるから研究目的で使われてるだけだ
それと最先端の情報は間違いなく日本語ではない OpenGLとD3D9は古い手法が混ざっていて混乱の元
VulkanとD3D12は周辺知識が余計に要る WindowsだけならDirectXで良いけど、スマフォとかMacとかマルチを考えるならOpenGL 1から勉強するならWebGLが最適
最新のブラウザには良く出来たデバッガとプロファイラが備わってるし
コンソールにはご丁寧に実行時エラーを表示してくれる
どうせお前ら実行時エラー出しまくりなんだろうからこれが滅茶苦茶役に立つ
で、基礎を身に着けたらC++とかでやればいい >>385
ES2.0はプログラマブルシェーダーあるGPUが前提になって
それに要らん機能は削除されてる
Coreプロファイルもなんか色々削除されてるはず 2.xまでにあった要らん機能まで思い切って削っちゃったバージョン? directx周りのossのライブラリは軒並み微妙な印象 >>365
電池も再来年に革新が起こりそうだけどね
まあVulkanに取り組んどいた方が後々楽だと思うよ >>400
違うスレでも見た気がするけど、その電池の革新って何だ?
ソースプリーズ 日経エレクトロニクスでも記事になってた全固体電池じゃね?
安全で容量が数倍になるうえに寿命も長く、さらに充電時間も短縮するとか。 固体電池が実用になるのは早くても2020年頃になると思うけどね
で、容量が大きくなったからと言ってGPUをブン回すことが出来るかって言うとそうじゃないな
電池の持ちは良くなるだろうけど現状でもスマホで3Dゲームやると
持ってられなくなるぐらい熱くなるから、結局GPUの省電力化が全てだろう >>405
本当に永遠と言い切れるか?
電力を無線で飛ばす時代だ
普通に持ってるだけでスマホに500W以上の大電力が供給される可能性だってゼロとは言えない
そうなるとPCを超えられる 物理的なサイズの問題はどこいったのかな。
小型で高性能化したスマホの技術を結局デスクトップに応用できるんだからでかいほうが強いのはずっとかわらん。 >>408
PC用にボードを販売しても儲からないからスマホに最先端GPUを供給するようになったら立場が逆転する
経済的に立場が逆転する事は十分考えられる
よって永遠とは言い難い ■ このスレッドは過去ログ倉庫に格納されています