アカウント名:
パスワード:
なんか、変な実装をされたのをサポートするのはしんどいのでウチじゃサポートしないっすよってのは普通なんじゃないかな？その内、PhysX Readyロゴとか付けてこれが付いてるのはサポートみたいな商売を始めるのかも。まぁ、現状ではATIのカードでATIが勝手に実装してるんだからATIでサポートしろやゴルァってのがあんまり悪いとも思えませんし、オープンを謳い、仕様自体のシェアの拡大が目的なら特定チップだと動かない的なトラップを意図的に入れることは無いんじゃないかと。
まぁ、現状ではATIのカードでATIが勝手に実装してるんだからATIでサポートしろやゴルァってのがあんまり悪いとも思えませんし、
これは↓のような意図でしょうか？
タレこみ文しか読んでませんが、今回の件は↓のような話では？
これは正直、何故？と言われても仕方がない気がしますが・・・。 画面表示について仮に何か問題があったとしてそれは知らない、というのは判りますが、この構成でも物理演算処理で問題が起きたら、何かしらサポートしてほしいと思うのは自然な気持ちかと。
CUDAにはグラフィックレンダリング用のバッファを読み書きする仕組みがあり、物理演算を用いた3Dグラフィクスでは通常この機能を使って物理演算の結果をレンダリングにまわす際の遅延を回避しています。
が、この機能は同一のグラフィックハードウェアあるいはSLi接続されたハードウェア間でしか使えないため、nvidiaのハードウェアからATiのハードウェアへデータを転送する場合何らかのnvidiaが想定していない方法（おそらくその唯一の方法はCPUを経由するもの）を使うことになり、これをサポートすることが出来ないと言っているのだと思います。
が、この機能は同一のグラフィックハードウェアあるいはSLi 接続されたハードウェア間でしか使えないため
だとしたら、「SLI接続しないPhysX SLI」とか「CPUでのPhysX」とかはどうなってるんでしょう。
Driver Release 186以降、同じPC内にATIなどの非NVIDIAのGPUがある場合、PhysXが使えない（上田新聞 blog版） [nueda.main.jp]という情報が正確なら、もっと古い178.13などではATIと同居しても使えたように読めるんですが。
説明不足でした。仰るとおりフレームバッファを直接CUDAにバインドせずとも、CUDAの計算結果を一度ホスト側のメモリに移してから、別のグラフィックハードウェアに食べさせることでSLiを使うことなくデータを受け渡すことは可能です。しかし、CUDAを用いる必要があるような大量のデータを扱う処理ではCPUにデータを触らせるとCPUがボトルネックとなって性能が出ません。ローエンドなグラフィックデバイスならその性能はCPUと大差ないのでこの問題は表面化しませんが、ハイエンドなビデオカードではこのことは大きな問題となります。
PhysXの目的は物理演算の高速化なので、速くないと価値がないわけですが、こうしたグラフィックハードウェア以外の要因でパフォーマンスが低下する構成で使われたためにGeForceでのPhysXのイメージを悪くすることこそ問題と考えたのではないか、ということです。
# さっきのAC
全く関係ありませんよ。NVIDIA PhysXは実装にCUDAを利用してはいますが、物理演算の結果をDirectXのテクスチャや頂点バッファーとして受け取ることは出来ませんし、GPU内部でコピーすることも出来ません。CUDAのグローバルメモリや配列として触れることすら出来ません。
およ 使ってないのか。PhysXって思ったよりいいかげんな作りしてるなー。
そうなると確かに取り出したデータをその後何に使うかによってサポート出来ない理由が見当たりませんね。
# と同時に現時点でもマシンパワー不足に悩む流体の計算にはあ# まり使えなさそうだと思う#1648906
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie
変な実装 (スコア:3, すばらしい洞察)
なんか、変な実装をされたのをサポートするのはしんどいのでウチじゃサポートしないっすよってのは普通なんじゃないかな？
その内、PhysX Readyロゴとか付けてこれが付いてるのはサポートみたいな商売を始めるのかも。
まぁ、現状ではATIのカードでATIが勝手に実装してるんだからATIでサポートしろやゴルァってのがあんまり悪いとも思えませんし、オープンを謳い、仕様自体のシェアの拡大が目的なら特定チップだと動かない的なトラップを意図的に入れることは無いんじゃないかと。
◆IZUMI162i6 [mailto]
Re: (スコア:1, 参考になる)
これは↓のような意図でしょうか？
ATIAMDのPhysX実装をサポートしないタレこみ文しか読んでませんが、今回の件は↓のような話では？
これは正直、何故？と言われても仕方がない気がしますが・・・。
画面表示について仮に何か問題があったとしてそれは知らない、というのは判りますが、この構成でも物理演算処理で問題が起きたら、何かしらサポートしてほしいと思うのは自然な気持ちかと。
Re: (スコア:5, 参考になる)
CUDAにはグラフィックレンダリング用のバッファを読み書き
する仕組みがあり、物理演算を用いた3Dグラフィクスでは通
常この機能を使って物理演算の結果をレンダリングにまわす
際の遅延を回避しています。
が、この機能は同一のグラフィックハードウェアあるいはSLi
接続されたハードウェア間でしか使えないため、nvidiaのハ
ードウェアからATiのハードウェアへデータを転送する場合何
らかのnvidiaが想定していない方法（おそらくその唯一の方
法はCPUを経由するもの）を使うことになり、これをサポート
することが出来ないと言っているのだと思います。
Re:変な実装 (スコア:1)
だとしたら、「SLI接続しないPhysX SLI」とか「CPUでのPhysX」とかはどうなってるんでしょう。
Driver Release 186以降、同じPC内にATIなどの非NVIDIAのGPUがある場合、PhysXが使えない（上田新聞 blog版） [nueda.main.jp]という情報が正確なら、もっと古い178.13などではATIと同居しても使えたように読めるんですが。
Re:変な実装 (スコア:2, 興味深い)
説明不足でした。
仰るとおりフレームバッファを直接CUDAにバインドせずとも、
CUDAの計算結果を一度ホスト側のメモリに移してから、別の
グラフィックハードウェアに食べさせることでSLiを使うこと
なくデータを受け渡すことは可能です。しかし、CUDAを用い
る必要があるような大量のデータを扱う処理ではCPUにデータ
を触らせるとCPUがボトルネックとなって性能が出ません。
ローエンドなグラフィックデバイスならその性能はCPUと大差
ないのでこの問題は表面化しませんが、ハイエンドなビデオ
カードではこのことは大きな問題となります。
PhysXの目的は物理演算の高速化なので、速くないと価値がな
いわけですが、こうしたグラフィックハードウェア以外の要
因でパフォーマンスが低下する構成で使われたためにGeForce
でのPhysXのイメージを悪くすることこそ問題と考えたのでは
ないか、ということです。
# さっきのAC
Re: (スコア:0)
全く関係ありませんよ。
NVIDIA PhysXは実装にCUDAを利用してはいますが、
物理演算の結果をDirectXのテクスチャや頂点バッファーとして
受け取ることは出来ませんし、GPU内部でコピーすることも出来ません。
CUDAのグローバルメモリや配列として触れることすら出来ません。
Re: (スコア:0)
およ 使ってないのか。PhysXって思ったよりいいかげんな作りしてるなー。
そうなると確かに取り出したデータをその後何に使うかによって
サポート出来ない理由が見当たりませんね。
# と同時に現時点でもマシンパワー不足に悩む流体の計算にはあ
# まり使えなさそうだと思う#1648906