[過去ﾛｸﾞ] OpenGL/Vulkanスレ Part22©2ch.net (1002ﾚｽ)
上下前次1-新
抽出解除 必死ﾁｪｯｶｰ(本家) (べ) 自ID ﾚｽ栞 あぼーん

---

このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ

---

ﾘﾛｰﾄﾞ規制です｡10分ほどで解除するので､他のﾌﾞﾗｳｻﾞへ避難してください｡

---

80(1): デフォルトの名無しさん [sage] 2015/10/31(土)18:10 ID:2qMna6cK(1)
こんな事書いてあるけどOpenGLのコマンドがすぐに戻って来ないって事は良くあんの？glReadPixelsみたいな結果を得る必要があるコマンドでなくても？

Chromeだと複数のプロセスからのOpenGLコマンドを一つのプロセスでまとめて実行してるようだ

http://www.chromium.org/developers/design-documents/gpu-command-buffer

The #3 goal is speed. Speed is why a command buffer implementation was chosen.
The client can write commands very quickly with little or no communication with the service and only once in a while tell the service it has written more commands.
For example, another implementation could have used a separate IPC for each OpenGL ES 2.0 function but that would arguably be too slow.
The command buffer gets another speed boost because it effectively parallelizes calls into the OS graphics API.
A call like glUniform or glDrawArrays might be a very expensive call but because of the command buffer the client just writes a few bytes into the command buffer and is done.
The GPU process calls the real OpenGL function on another process which effectively makes the program multi-core.

---

上下前次1-新書関写板覧索設栞歴

---

ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ

---

ぬこの手 ぬこTOP 0.036s