タグ付けされた質問 「gpgpu」

10
GPUの代わりにCPUを使用する利点はありますか?
私はプロセッサとグラフィックスカードを研究してきましたが、GPUはCPUよりもはるかに高速であることを発見しました。この記事の 1つで、特定の状況で2年前のNvidia GPUが3.2GHz Core I7 Intelプロセッサーを14倍上回る性能を発揮したことを読みました。GPUがこれほど高速な場合、開発者がゲームのすべての機能にそれらを使用しないのはなぜですか?GPUがグラフィックス以外のことを行うことは可能ですか?
63 gpu  process  gpgpu 

7
パーリンノイズによって作られた世界のスポーンユニット?
Perlinノイズベースのゲームで出会ったいくつかの問題があります。以下の添付のスクリーンショットをご覧ください。 あなたが見る白い領域は壁であり、黒い領域は歩行可能です。中央の三角形がプレーヤーです。 このゲームでは、物理学を実装して、テクスチャ(白または黒のピクセル)に描画し、それをCPUから取得します。 しかし、今は別の問題に直面しています。画面の端で、ユニット(またはクリープと呼びます)が常に出現するようにします。ここでのポイントは、最終的なゲームでは、プレイヤーがそこまで見ることができない「戦争の霧」があるということです。 画面の端のピクセルをスキャンして、その物理テクスチャが黒かどうかを確認し、そこにランダムに物を生成できると考えました。ただし、スクリーンショットをもう一度見ると、(左上隅に)クリープが生成されないようにする例があります(そこからプレイヤーに到達できないため) 。 どういうわけかGPUにこれらのスポーンスポットを決定させることは可能ですか、それとも別の方法ですか?画面の端にある提案されたポイントとプレイヤーの間にベクトルを作成し、10ボクセルごとにそれをたどって、そこにユニットをスポーンする前に壁が衝突するかどうかを確認することを考えました。 ただし、上記の提案されたソリューションは、CPUに負荷がかかりすぎる可能性があります。 この問題に関する提案はありますか? 注1 スポーンされるユニットについては、これらのユニットがプレイヤーに向かって走る際の壁の衝突を避けるために、いかなる形態の経路探索も使用したくありません。したがって、ユニットは画面の端に、プレイヤーに向かって直線的に歩いても壁と衝突しない場所に出現する必要があります。
16 xna  path-finding  hlsl  gpgpu 

1
nVidiaのCUDAは、経路探索計算の実行に適していますか?
GPUでパスファインディングを実行する価値があるかどうかを知りたい(nVidiaの 特定の状況で CUDAまたは同等のものする)か、それとも無駄な努力かどうか。私が想像する状況は、ボットのパスを見つける責任があるヘッドレスマルチプレイヤーサーバーです。 ナビゲーションメッシュを使用したA *パスファインディングに特に興味がありますが、GPU実行からより多くの利益を得る別のパスファインディングアルゴリズムがある場合、それを聞きたいです。

1
計算シェーダーとパイプラインシェーダーによるアルゴリズムの実装
DirectXとOpenGLの両方のコンピューティングシェーダーが利用可能になったことで、ラスタライズパイプラインを経由せずに多くのアルゴリズムを実装し、代わりにGPUで汎用コンピューティングを使用して問題を解決できるようになりました。 一部のアルゴリズムでは、これは本質的にラスター化ベースではないため、これは直感的な標準的な解決策になり、ラスター化ベースのシェーダーはGPUパワーを活用するための回避策のように見えました(簡単な例:ノイズテクスチャを作成します。ここでクワッドをラスター化する必要はありません) )。 両方の方法で実装できるアルゴリズムが与えられた場合、通常のルートを使用する場合と比較して、計算シェーダーを使用する場合に比べて一般的な(潜在的な)パフォーマンス上の利点はありますか?注意が必要な欠点はありますか(たとえば、実行時にシェーダーの計算を切り替えるために、ある種の異常なオーバーヘッドがあります)? 2つを選択するときに考慮すべき他の利点または欠点はおそらくありますか?

2
Silverlight 5でGPUを使用して高速フーリエ変換を行う
遅いマシンで加速が必要なSilverlightのオーディオライブラリがあります。具体的には、このライブラリは、音響エコーキャンセレーションおよびノイズリダクションアルゴリズムの一部としてFFT変換を広範かつ繰り返し使用します。このためにGPUを使用するのが理にかなっているか疑問に思います(たとえば、ここ:http : //www.inf.fu-berlin.de/lehre/SS10/SP-Par/download/fft1.pdf)。 Silverlight 5がMicrosoftのXNAフレームワークのかなり単純なポートを提供していることは知っていますが、残念ながら、私は3Dコーディング全般、特にXNAの完全な初心者です。理論的には頂点および/またはピクセルシェーダーの組み合わせを使用してこの魔法を働かせることが可能であるように思えますが、この道を進む前に、いくつかの質問について専門家の意見を聞きたかったのです。 (1)SL5のXNA実装は、そのパイプラインの出力を単一の "DrawingSurface"にスローします。私はこれが計算の結果を読み取ることができるかもしれないと思っていました(WriteableBitmapを使用して、SL4のピクセルシェーダー計算の結果を読み取る方法の一種)。しかし、どうすればよいのかわかりません。「GetPixels()」メソッドなどはありません。通常のXNA 4.0では、VertexBufferにGetData()メソッドがあり、Texture2DおよびTexture3Dクラスと同じですが、これらのメソッドはSL5バージョンにはありません。シェーダー出力の結果を実際に読み取る方法を知っている人はいますか?または、GPUはSL5の書き込み専用デバイスですか? (2)GPU計算の本当の問題は、結果をすばやく読み取ることです。私が問題1を解決できると仮定すると、FFTがこの種のソリューションに適しているかどうか誰かが知っていますか? (3)Silverlight 5はHLSLレベル2に制限されています。HLSLレベル2には、命令、レジスター、使用可能な関数などに関して、いくつかの重大な制限があります。FFTまたはその一部をこれに移植できると期待することはまったく理にかなっていますか? 前もって感謝します。
7 xna  gpu  gpgpu 
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.