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/ こっちがソースか
http://gamingbolt.com/ps4-should-support-vulkan-ps4s-api-not-completely-native-for-current-gen-yet-brad-wardell
> their low-level API is still lower level than Mantle and Vulkan
って明確にVulkanよりローレベルって言ってる
GNMはハード直叩きに限り無く近いからな >>477
なんだ、そういうことかw
ローレベルって言えば通じるのかな?日本語って難しいなw つーか素人うぜえよ
テメエで使ったこともねえくせに
良いだの悪いだの
アホじゃねーの? 手続きの手順が違うから
まっさらからVulkanに合わせて作るならともかく
既存のOpenGLベースのコードの中身を入れ替えたり拡張するような使い方じゃ性能でないよって話だよね? 質問です
画像を描画する際、配列を渡して一斉に描画するほうが高速だと聞きました
ですが渡す配列が固定長だと描画枚数が増えた時に柔軟に対応できない気がします
皆さんはそういった場合、毎フレーム動的配列を生成・削除してるのでしょうか? 前回と同じサイズのものは使いまわす
っていうかそんなことより0で埋めるとか馬鹿な初期化する方が無駄 前回と同じサイズのものは使いまわせばいいことは分かっています
描画する数が毎回変わるならどうすれば・・・って話です 描画したくないものまで描画されるじゃないですか
画面外に描画する。それでいいんですかね
めんどくさいので配列として扱わないことにしました みんなマルチスレッド化されたOpenGLが欲しかったんだよね? >>488
OpenGLは必ず配列内の有効な個数を指定する必要がある
余計に描画されるとかしょうもない推測をするな >>488
なんで必ず最大数描画するだよ、描画個数決めれるだろ
必要な分だけ先頭に詰めれ 縦横の慣習が違うのは
民族性とか文化の違いから来てるんですか >>467
お前らが叩くから記事消えちゃったじゃん > 描画したくないものまで描画されるじゃないですか
?
頂点数指定するだろ。
ていうか配列でというのは連続したメモリ領域をという意味だから、常にプログラミング言語仕様で言うところの配列の先頭からでなくともよい。
でかい固定配列をリングバッファとして使っても良い。
> 配列を渡して一斉に描画するほうが高速だと聞きました
これを言った人が何を意味していたのか分からないが、
・4頂点ずつ描画キックするよりはまとめてキックした方が良い
・glVertex や glColor の類を使うよりはglVertexPointerを使う方が良い
・VBO を使うとより良い
と言える。
素人は何を聞いているのか分からないことが良くある。もっと謙虚になるといい。 >>495
クソワロタww
消すような記事最初から書くなよw Vulkanってローレベル過ぎて使いづらそう
なんかこう
OpenGLとVulkanの中間みたいのが欲しい 最近になってOpenGLを触ったんだけど凄く使い辛いと思った
元がとても昔に作られたものだからこんなものかとも考えたが
これかDirectXを最下層として多くのゲーム等が作られているのかと正直驚いた 掲示板と日記帳の使い分けもできないリテラシーのひくそうな人には
いろいろと不便でしょうね(´・ω・`) オブジェクト指向マンセーで
ステートマシンを知らないひとには使えない そのせいでマルチスレッドに対応しづらいのもまた事実 なんでステートマシンになってるのかなと思った
ハードウェアチップをI/O経由でたたくイメージなのかなこれ?
描画ソフトウェアライブラリーというよりSGIのGPUを制御するためのツールとしてデザインしたらこうなったのかな >>504
CoreProfileになればだいぶ違うぞ。
そもそも便利機能は全部拡張機能だ。 何bindしたかで関数の動作や引数の意味が変わってしまうのには嵌るわ。
バッファ関連そんなんばっかし。 そりゃそうだ
Cで構造体をVOID*にするようなもん >>508
今のようなメモリ上に分散したデータをまとめてDMAでゴソッとGPUに渡すようなハードじゃなくて
ハードウェア上に1つだけステートがあって、それこそI/OポートとかメモリマップドIOとかで
GPUのレジスタを一つずつ設定してdrawするんであれば、初期のOpenGLの実装は理にかなってると言えるかも
想像で言ってるだけだが >>512
それがどう解釈されるかが関数のインターフェースに現れないのが問題。
どっかのグローバル変数の値によってint*かdouble*かが決まるような糞仕様。 オートマトンじゃないものをステートマシンと呼ぶ分野があるのか。 bind , unbindのタイミングの定義がなんかもやもやしてるよね githubに中国語でコード書いている中国人もいるし
多少はね? Vulkanで実装されたOpenGLみたいのを使えば
苦労しなくても既存のアプリが少しは早くなるかもって思ったけどそれは無いか
Vulkanの大きなメリットの一つはレンダリングステートやコマンドバッファを再利用できる事みたいだが
ゲームエンジン側は毎回OpenGLのAPIを呼ぶような構造になってて
再利用する前提になってないから無意味そう
OpenGLの仕様に合わせようとするとエラーチェックも必須でさらにオーバーヘッドが 赤本も出た事だし猿でも分かるVulakanブログを始めようかと思ってるけどね
理解さえすれば偏見もなくなるはずだ >>519
ゲームエンジンはレンダリング部分をもっと高レベルの所で抽象化してるから意味あるよ。
余程糞設計のゲームエンジンでないかぎりな Vulkanは今までドライバが勝手にやってくれてたメモリ確保や
コマンドバッファに入れたコマンドの送信も手動っぽいのも面倒くさい
OpenGLとNV_command_listのVulkan版みたいの欲しいな
あれVulkanで出来る事に近いんでしょ?
ANGLEのVulkanバックエンドのコードは見てみたが
まだ何も実装されていなかった >>519
エラーチェックとかステートの一貫性チェックとかは開発時だけに必要なんだよ
リリースビルド時はバッサリ削除するのが普通
リリース版実行時にOpenGLエラーが発生したらそれは単にバグを残したままリリースしちゃったってことだ >>523
それアプリ側でglGetError使うかどうかって話じゃないの?
もしかしたらglGetErrorが使われるかもしれないし
エラー発生時もGPUによって違う結果になったりしないように
OpenGLドライバは常にエラーチェックをしてる
そのせいでオーバーヘッドが大きいとか聞く
これ無視してエラーチェックの無いOpenGL実装を作ったら
それはもはや規格外OpenGLだと思う 将来的にGPUメーカーの提供するドライバーがVulkanのみになってOpenGLを切り捨てるとかにならない限り
Vulkanで実装したOpenGL APIとか作っても無意味そうだよね >>525
GPUメーカーがそれを使えばドライバーがまともになる それはVulkanドライバーがまともならって前提だな https://www.khronos.org/vulkan/faq#web-vulkan
WebVulkanは出ないけど
Vulkanっぽい機能を追加したWebGL3は有り得る感じ? >>524
話の前提が違ってるな
>>519はゲームエンジンはOpenGLを呼ぶように設計されてるからVulkanにしたところで速くならないみたいなことでしょ
で、OpenGLのエラーチェックは開発時だけに必要な機能だからそれをバッサリやらなければ速くなると言ったんだ >>527
Vulkanドライバーは薄いレイヤーだしコンフォーマンステストも充実してるからドライバーの質が良い可能性は高い
ちなみにOpenGL on Vulkanは既にあるぞ
Khronos謹製じゃないがな OpenGLをMFCのシングルフォームビューで使用しています。
ピクチャーコントロールをOpenGLで描画しているのですが、他のウィンドウがかぶっていると描画されません。
何か解決策ないでしょうか? >>529
WebGL3があるならES4.0が実装されるはずだけどそもそもリリースされるのかね?
もはやES3.2で完成してんじゃないかとすら思えるけどね >>533
OpenGLそのままでもVulkanそのままでも無い何かが作られるなら
WebGL3って言い方は適切じゃなかったな
実装にはVulkan使えば良いだろう >>534
それ言ったらWindows版ブラウザのWebGL実装は全部DirectXを呼び出してるよ
それがVulkanになるのは時間の問題だろうね
WebGL→DirectXは右手系左手系とかシェーダーの違いとか苦労してるみたいだからVulkanの方が親和性は高いはず
上っ面のAPIはずっとWebGLのままだと思う そろそろデフォで有効になるWebGL2はPS3以上PS4未満の能力があるから、それで十分だと思うけどね
限界までパフォーマンスを追求するようなプラットフォームじゃないし http://floooh.github.io/2016/08/13/webgl-next.html
VulkanをそのままWebに持っていけない理由が色々挙げられてる
セキュリティとか性能の問題とかAPIの複雑さとか色々
それでもWebGLは普通にOpenGLを使うのと比べて遥かにオーバーヘッドがでかいようなので
その辺を改善した後継は出るんなら欲しい
この人によると良くできたOpenGLドライバでネイティブだと60fpsで100kのドローコールが出来るけど
WebGLだと60fpsで出来るのは5,000程度らしい
オンボードのGPU(Intel?)の出来の悪いドライバだと10k程度 Javascriptとかwebassemblyがネイティブコード並に速くならないとwebvulkanがあってもJavascriptの実行自体がボトルネックになって速くならない。
セキュリティチェックが必要だからネイティブコード並に早くするのは無理。
なのでAPI呼び出しを減らせるようにwebglを設計しようということか。 >>532
今時MFC?
ウィンドウ被ったら描画されないってWM_PAINTイベントで描画してないとか?
でも最近のWindowsってウィンドウが被っていても消えたりしないよな
デスクトップコンポジションがあるから >>538
JavaScriptとWebAssemblyは同じじゃない
WebAssemblyは遅くてもせいぜいネイティブコードの1.5倍以内の遅さに収まってる
いずれオンゲーはWebAssembly+WebGL2な環境で動かすのが普通になるだろうね そもそもJSじゃ速度が測定時の状況でかなり変わるし
C++じゃ実行時にプロファイリングして得た情報で高速化なんて出来ないし
参照カウントとかで手動でメモリ管理する方がGCより速いとも言えないらしい
APIコールには一定のオーバーヘッドがあるので
それはC++より不利 >>542
手動でメモリ管理するのは速度の為じゃなくて、適切なタイミングでメモリの取得解放を行う為だ
あとプロファイリングは開発時に散々してチューニングすれば問題無い
実行時にプロファイリングしてC++よりも高速なコードを生成するなんてほとんど幻想に近いが有り得ないことはない
ただそれもあてにならないわけだし、安定したフレームレートが必要なゲームには全く向かない そもそも実行時プロファイリングは最適化に手間(実行時間)をかける価値のある部分を見つけるためのものだよね?
本当なら全部を最適化をしたいけど、実行時コンパイルでそれやると最適化にかかる時間でかえって遅くなるから最適化処理を必要最小限にしたい
→もっとも効果がある部分をプロファイリングで探す…って
C/C++はピックアップせず全てを最適化するからプロファイリングは不要だし
最適化にかかる時間をプログラムの実行時間外(事前)にまわせるから
これより速く動作させる事なんて不可能でしょ そういうベンチ結果ならあるから絶対ないって事は無いだろう
実際にどんなパターンで実行されるかって情報だけはAOTじゃ分からないからな
それを加味して最適化するとデメリットがメリットが上回り速くなることは有り得る
あまり頻繁に実行しない部分を時間を掛けて最適化してもあまり速度は速くならないし
https://en.wikipedia.org/wiki/Adaptive_optimization 実行結果から最適化した方が良いコードを生成できる可能性高いしな。
エラー処理とかまず通らないコードをインライン展開してもコード密度悪くなって逆に性能悪くなるし。
(コンパイラ拡張で最適化のために殆ど通らないって属性付け出来たりするけど)
VC++2017には実行した結果から最適化させる機能が入った
https://msdn.microsoft.com/ja-jp/library/e7k32f4k.aspx 「Rubyのしくみ」に載っているベンチマークでは、
JRubyのループ回数が10万回(0.3秒)から、100万回でも0.3秒なんだよね。
このタイミングでさらに、コンパイルして加速していく
最終的には、1,000万回(1秒)で、CRubyよりも速くなる。
CPUセントリックな処理、つまりI/Oが無い場合、
予測分岐とか最適化技術では、Javaが、Cよりも勝る プロファイルベースの最適化は開発時にプロファイリングして
AOTコンパイル時のヒントとするやり方はかなり効果あるだろう
実際chromeが起動時間が20%速くなったとかあったな
それとJITコンパイラする実行しながらプロファイリングするのと一緒にしてはいけない DX11はDX12の機能ほしくなる
あとはいまだにCPUにフレームレート引っ張られるのがいらっとくる glmapbufferrangeってglbindsubdataで代用できるよね? >>535
横からだが、座標系の違いはシェーダ時代だと存在自体がユーザの好みじゃないかな
GLとXの座標系の違いは固定機能が原因で、
シェーダだと座標系変換行列が吸収する。
少なくとも、俺が書いたDirectXのシェーダは、右手座標のモデルを入力して実現できている。 変換行列は一緒だぞ
右座標だろうが左座標だろうが関係ない Zを+にするか-にするかはアプリがどういう行列を作るかで決めることでグラフィックのAPIレベルでは関係ないぞ。
実際にUnityはGL、Metal、DirectXのどれを使っても左手座標だぞっと。 多分固定機能時代はそれぞれが内部的に決まってたからそういう風に思ってる人が多いんだと思うが でもzの範囲の問題でprojectionは互換なかったりするよね? >>560
それはプロジェクション行列に下駄はかせるか頂点シェーダーで変換すればいいし、右左とは関係ないわな。 ttp://glslsandbox.com/
ここにglslのサンプルがいっぱいあるけど
ここのglslをコピペして自分のpcで動かしたいけどそういうのってできます? DirectXは左手系と言ってるみたいだけど、多分サンプルとかがそういう風に
実装されてるだけで、実際にはアプリが自由に決めていい
ただANGLEの実装ドキュメントによると最後のウィンドウ座標だけはY軸の向きが
OpenGLとDirectXで逆になってて変換する必要があると書いてあった
Y軸逆なのはテクスチャ座標もそうだな 同じ座標指定したら右手と左手じゃおかれる位置が明らかに変わるんだから
自由じゃない >>542
jsみたいな高級言語だと、言語自体に予め遊びをいれておき、そこから適切なアルゴリズムを内側で変更するってことは可能じゃないかな
例えば、配列の探索。
シーケンシャルに読むコードであれば、ワークスレッドに分散して速度を稼ぐといった高速化ができる余地がある。
言語にスレッドがないからね
これはcでも可能だが、最適化より予めOpenCLだったかの言語拡張で教え込むことができるから、そのプロファイル自体が要らない。
JavaScriptはよく知らんが、GCと同じでプロセスが落ちたら最適解を忘れそう てか、配列探索の説明になってなかった。
配列の場合、言語では配列にみせるが、アクセスがシーケンシャルかインデックス単一要素アクセスのどちらが多いか、要素の削除やクリアの頻度を計るとかがあるような。
それによって内部の変数管理をリストに変更したりベクターにしたりという最適化があり得そう。
だが、実際は予めデザインで決定出来るのだが、そこをダイナミックオプティマイズで設計時間省略!てかはできるかな。
特に素人や頻繁にコードを変えるシーンだと好まれるかもしれない。
スレ違いすまん。 >>565
お前は…
カメラの位置とかデータの内容が全て左手系や右手系を前提に構築されてれば
まったく同じ見栄えのゲームが作れんだよ
だからどっちを選択するのかはアプリの自由という事が理解できないのか? レンダリングエンジンを抽象化するという発想がないんでしょ 座標データのZのプラスマイナス逆に刷りゃ同じになるけどそれって自由な選択じゃなくて座標系に合わせてデータ差し変えてるわけで 意味合いが違うな ああ右手用データを左手座標にぶちこんでも全部逆になるから結局見た目は同じになるって言いたいわけ? 左手系の為に左手系のデータを用意するのも含めてアプリの自由だと言ってんだよ
やたら頭堅いやつが紛れてるな 左手系の為に左手系のデータやプログラムを用意する
右手系の為に右手系のデータやプログラムを用意する
どっちかを決定するのはDirectXが決める事じゃなくてアプリの自由だという単純な事だぞ? >>570
座標系に縛られるから不自由とかはグラフィックス計算の話題じゃないな
計算するのが不自由って意味になる… それよりボトムアップなのがややこしい
FBOでテクスチャに描いたときに上下が逆になってしまう
対策は頂点シェーダーで座標を逆転させるか
普通のテクスチャを逆転させるか Aという行列があるとして
→X=(x,y,z)というベクトルを用意して
→Y = →XA という掛け算をするのが「いわゆる左手系と呼ばれる操作」
↑X'=(
x',
y',
z')
というベクトルを用意して
↑Y' = A↑X' という掛け算をするのが「いわゆる右手系と呼ばれる操作」
の違いでしかない
(要するにどちらも本質的には同じ) >>575
アプリ内で反転したテクスチャをレンダラに渡すって手もあるが猛烈にメモリーの無駄
うちはGIMPでエクスポートするとき上下の鏡像反転だね ■ このスレッドは過去ログ倉庫に格納されています