アカウント名:
パスワード:
Xがメンテモードという意見には同意ですね. 特にXFree86ではドライバの外部モジュール化が完成した時点で終わったと思って良いのではないでしょうか.
ただ, 後継がOpenGL程度のものと想定するのはあまりにも近視眼的だと思います. 少なくとも現在見えている時点でも
あたりがあるわけですから, 少なくともプログラマブルな画像表示仮想マシンアーキテクチャと, それに合わせた通信プロトコルという形の実装の方が良いように思われます.
# CgでXサーバって実装できないかな?
いえいえ, ここで私が問題だと思っているのは現在から近い将来にかけて想像されうるハード機能をソフト側でサポートできなければ意味が無いということです. この点でAPIの定義は重要なのですが, さらにやっかいなのは現在のGPUが固定的なAPIで定義するには高機能になりすぎちゃったってことです.
OpenGLは良くも悪くも画像表示のためのAPIなので, リファレンスマニュアル等にも明示されているように複雑な幾何学的オブジェクトの描写やモデリングの手段は含まれていません. そのため, ストリーミングデータのデコードをGPU側に任せることによりバスの負荷を低減させたり, ゲーム等で物理モデル計算の一部をGPUに行わせるなんていう, 従来の画像処理の範疇に入らない, しかしGPUの用途として考えられることには対応できません.
要は今後GPUに求められるものを十分に実現しようとするならば, プリンタにおけるPostScript並みの汎用言語がAPIとして必要になるのではないか, さらにそれを実現できるだけのハードパワーがグラフィックサブシステムに備わってきたのではないかってことですけどね. まあ, 汎用言語がグラフィックサブシステムに相応しいのか(PostScript→Acrobatという前例も有りますし), また性能が本当に出せるのかという問題はありますけど. ただ, 5年前ならともかく, 今の時点でOpenGL決め打ちというのは先が無さそうなんで...
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
にわかな奴ほど語りたがる -- あるハッカー
ま、Xはとりあえずメンテモードということで (スコア:0)
新しく作るんだったら、OpenGLサーフェース上で動く
ウインドウシステムにしてちょうだい。
見えてるものが全部テクスチャードポリゴンってのが、
時代の潮流なんだろうし。
Re:ま、Xはとりあえずメンテモードということで (スコア:3, すばらしい洞察)
Xがメンテモードという意見には同意ですね. 特にXFree86ではドライバの外部モジュール化が完成した時点で終わったと思って良いのではないでしょうか.
ただ, 後継がOpenGL程度のものと想定するのはあまりにも近視眼的だと思います. 少なくとも現在見えている時点でも
あたりがあるわけですから, 少なくともプログラマブルな画像表示仮想マシンアーキテクチャと, それに合わせた通信プロトコルという形の実装の方が良いように思われます.
# CgでXサーバって実装できないかな?
Re:ま、Xはとりあえずメンテモードということで (スコア:1, 参考になる)
OpenGL程度っていうけど、OpenGLはあくまでAPIであって、
SteppingWindさんのおっしゃっていることは、すべてハードウェア
の話しであって、混同されています。
それに、Cgはシェーディングランゲージであって、OpenGL(または
DirectX)があってはじめて動作するものです。
当然、Xサーバなんて実装できません。
「プログラマブルな画像表示仮想マシンアーキテクチャ」
まさしく、OpenGL(と、シェーダー)のことですね。
Re:ま、Xはとりあえずメンテモードということで (スコア:2, 興味深い)
いえいえ, ここで私が問題だと思っているのは現在から近い将来にかけて想像されうるハード機能をソフト側でサポートできなければ意味が無いということです. この点でAPIの定義は重要なのですが, さらにやっかいなのは現在のGPUが固定的なAPIで定義するには高機能になりすぎちゃったってことです.
OpenGLは良くも悪くも画像表示のためのAPIなので, リファレンスマニュアル等にも明示されているように複雑な幾何学的オブジェクトの描写やモデリングの手段は含まれていません. そのため, ストリーミングデータのデコードをGPU側に任せることによりバスの負荷を低減させたり, ゲーム等で物理モデル計算の一部をGPUに行わせるなんていう, 従来の画像処理の範疇に入らない, しかしGPUの用途として考えられることには対応できません.
要は今後GPUに求められるものを十分に実現しようとするならば, プリンタにおけるPostScript並みの汎用言語がAPIとして必要になるのではないか, さらにそれを実現できるだけのハードパワーがグラフィックサブシステムに備わってきたのではないかってことですけどね. まあ, 汎用言語がグラフィックサブシステムに相応しいのか(PostScript→Acrobatという前例も有りますし), また性能が本当に出せるのかという問題はありますけど. ただ, 5年前ならともかく, 今の時点でOpenGL決め打ちというのは先が無さそうなんで...
Re:ま、Xはとりあえずメンテモードということで (スコア:0)
そういう「グラフィック側のハード機能をソフト側でサポートするように」という話になると、「DirectXのサポート」という方向に行かざるを得ない気がします。
「OpenGL決めうちに将来無し」という意見には(個人的には)賛成です。でも、NVIDIA
Re:ま、Xはとりあえずメンテモードということで (スコア:0)
今度は、古くはVRMLのようなモデリング言語の話しになっていますね。
ちなみに、NVIDIAなんかもチップの最高性能を出したければOpenGLを
推奨しているように、機能拡張が容易(DirectXなんかと比べると)なAPIです。
それに進化が止っているDirectXよりも、機能拡張が容易なので差別化がしやすい
ため、今後はOpenGLの方が重要だと、NVIDIA・ATIとも言っています。
もうちょっと、OpenGLしいては3Dの勉強をしてください。
結論としては、
ハードウェア←OpenGL+シェーディング言語←モデリング言語
というかん
Re:ま、Xはとりあえずメンテモードということで (スコア:0)
「独自拡張をして、もはや互換性の無いOpenGL」を「OpenGL」と呼ぶのでしょうか。;-p それにしても、「最高性能を出したければOpenGLを推奨している」というのは初耳ですね。この辺りのインタビュー [mycom.co.jp]を見ても、「OpenGLを推奨」なんていう空気は全く感じられないんですけど。Windows上だけで生きていけば良いアプリならDirectXが推奨されていると思っていました。
>> それに進化が止っているDirectXよりも、機能拡張が容易なので差別化がしやすい
Re:ま、Xはとりあえずメンテモードということで (スコア:0)
数年後...
/dev/fb0 ってデフォルトで swap 領域だよね。BitBlt 転送で CPU には負荷掛からないし、今じゃ古いけど AGP 接続だから、 転送速度も不満なし。256Mbyte なんでちょっと狭いけど...
Re:ま、Xはとりあえずメンテモードということで (スコア:0)
Re:ま、Xはとりあえずメンテモードということで (スコア:1, 参考になる)
ちゅうか、OpenGLはこれ以上低レベルにできないくらい
低レベルなんだけど。。。
それを、古いも新しいもないだろうに。
DirectXも8のDirectXGraphicsで、OpenGLに近付いたんじゃなかったっけ?
Re:ま、Xはとりあえずメンテモードということで (スコア:0)
素のOpenGLでガリガリかける人はある意味神だな
Re:ま、Xはとりあえずメンテモードということで (スコア:0)
私の周りはみんな素でガリゴリ書いてるなあ。
そんなに難しいものではないし大変でもない。
Re:ま、Xはとりあえずメンテモードということで (スコア:0)
MacのQuickDraw3Dとかは高レベルにして速度が出なくて失敗した気がする。
3DMF形式のファイルをAPIに送るだけで描画してくれたから便利なんだけど、3Dのように速度が要求されるものは、低レベル