HLSL対GLSL対cgの長所と短所は何ですか？[閉まっている]

3つの長所/短所は何ですか？

coderangerは、DirectXをターゲットとするHLSL、OpenGLとCGをターゲットとするGLSLが両方のインターフェイスで利用可能であることについて正しいです。

ただし、他にも考慮すべきことがあります（OGREフォーラムで学習）：

• CGでは、GLSLの最新機能を使用できません（HLSLについてはわかりません）。これは中間的なものであるため、GLSL機能を完全に活用することはできず、Shader Model 3.0（AFAIが理解する）までは一般的な機能しか利用できません。
• CGはNVidiaによって作成されており、カード用に最適化されていますが、ATIカードに対しては多くの作業を行っていないようです。
• OpenGLは、WindowsプラットフォームのDirectXよりも少し遅いようです。それは実際にあなたがしていることと相対的なものであり、その理由はドライバー実装のソースであることがわかりますが、APIと関連するシェーダー言語を選択する前に知っておくと良いでしょう。ただし、すべての（win / mac / unix /一部のコンソール）プラットフォームで使用できるインターフェイスはOpenGLのみです。そのため、GLSLのみを使用することは、Microsftを中心としないクロスプラットフォームゲームではより良い選択かもしれません。
• LinuxのNVidiaドライバーはATIドライバーよりも安定しているようで、Linuxでうまく動作することを確認する必要がある場合はCGをより面白くします（報告された情報はすべて、詳細を確認する必要があります）

そのため、最新のシェーダー機能を使用していない場合は、CGが適切な選択肢のようです。GLSLは、完全なOpenGLを使用している場合、より優れているように見えます。Microsoftプラットフォームのみを使用する場合は、HLSL。

まず、Windows用のHLSLで開発してDirectXを使用し、次にLinuxおよびMac用のGLSLに変換することは、パフォーマンスを確保し、より多くのシェーダー機能セットを使用するためのより良いソリューションです。しかし、それは多くの作業になる可能性があります（自分ではできなかったので、わかりません）。OGREグラフィックエンジン（およびその他のエンジン）は、任意のAPI（DirectXまたはOpenGLまたはその他）を使用できるので役立ちますが、この方法を使用する場合は、変換するシェーダーコードがまだあります。

これが、シェーダー言語の選択中に収集したすべての情報です（まだ決定していません）。

更新：Valveは、ゲームの1つをOpenGLに変換しましたが、DirectXバージョンをOGLバージョンよりも高速にする方法を見つけられませんでした。したがって、ドライバーの実装状態やAPIの品質などは毎年大きく変化しているため、どちらかを選択するための引数として生のパフォーマンスに完全に依存することはできません。これを念頭に置いて、OpenGL / GLSLを選択して、Windows以外のプラットフォームで作業する（または計画または作業を希望する）ときの生活を簡素化します。 APIはOpenGLよりも高速です（これは現在反転しているため、期待しないでください）。ユーザーに両方の可能性を提供したい場合はCGを使用しますが、それを行うための労働力（およびツール）がある場合は、GLSLとHLSLの両方を使用することも実行可能なソリューションです。

更新（2012）：CGが廃止されており、Nvidiaによるサポートも積極的な作業も行われていないことに注意することが重要です。Nvidiaは、すべてのユーザーがGLSLとHLSLの組み合わせ、またはnvFX（github上の）などの新しいライブラリに切り替えることをお勧めします。これは、GLSLとHLSLの間で機能の互換性を維持するのが難しすぎるためです。

CGとHLSLについてのみ話すことができます。これらは私がこれまでに使用した2つだからです。

CgはHLSLと同じではありません。

Cgでは、NVIDIAは非常にきれいなシェーダー構文を作成する上で素晴らしい仕事をしました。HLSLと非常によく似ています。

ただし、D3D9 / D3D11（初期化コード、シェーダーコンパイルコード）との連携は、HLSLではCgよりもずっとクリーンです。-1 Cg。Cgには、D3Dを介したHLSLのために必要としない、厄介なスタートアップコードがあります。

Cgでは、設定/変更するすべての uniformシェーダー変数に対して「cgGetNamedParameter」を指定する必要があります。そしてCGparameter、その変数のコード内で参照を維持する必要があります

// C++ code to interact with Cg shader variable (shader language independent)
CGparameter mvp = cgGetNamedParameter( vs, "modelViewProj" ); 
CG::getLastError("Getting modelViewProj parameter");  // check for errors
cgSetMatrixParameterdr( mvp, &modelViewProj._11 ) ;   // setting the matrix values

HLSLでは、これは最終的にずっときれいになります-1行だけで、そのCGparameter変数を維持する必要はありません。

// D3D9 C++ code to interact with HLSL shader variable
DX_CHECK( id3dxEffect->SetMatrix("modelViewProj", &mvp._11 ), "Set matrix" ) ;

上記DX_CHECKは、SetMatrix呼び出しから返されるHRESULTをチェックする単純な関数です。 上記のコードはd3d9です。D3D10と11はもちろん、もっと苦痛です（ID3DX11Effectオブジェクトがないため）。

HLSLを使い始める前は、このコードを見て、実際にactually していました。

NVIDIAは、OpenGL / D3D間Cgのための共通のインターフェースを作るために自分のベストを尽くしたものの、実質的にその話していない、そのように、あなたが持っているcgGL*、cgD3D9、cgD3D10、cgD3D11機能グループはと競合します。そのため、全体がOpenGL と D3Dで機能します!! クレームはこれまでのところだけです。#ifdef異なるプラットフォームで動作させるには、すべてをOpenGL / D3D タイプグループにまとめる必要があります。-2 Cg。

さらに、最近Cg / ATIカードで悪い経験をしましたが、これは私の悪いことではないと確信しています。（他の誰かが試してみますか？）。Klaimが主張しているように、NVIDIAがATIカードを完全にテストしていないのは本当かもしれません。または、ATIはCgでテストしません。いずれにせよ、そこには不一致と何らかの利益相反があります。-3 Cg。

全体として、私はCgを好みました。そのシェーダーコードの構文と命名は、クリーンで、甘く、整頓されています。残念なことに、これらの他の問題が発生しました。

私の非常に基本的な理解は、HLSLはDirectX専用であり、GLSLはOpenGL専用であるということです。Cgは基本的にHLSLと同じ言語ですが、DirectXまたはOpenGLで使用できます（ただし、異なるランタイムコードを使用します）。

HLSLとGLSLのもう1つの重要な違い（私はCGがわからないのでお話しできません）は、HLSLではMicrosoftがD3Dランタイムの一部としてシェーダーコンパイラを提供するのに対し、GLSLではハードウェアベンダーがその一部として提供しますドライバ。

これには、両方の利点と欠点があります。

GLSLメソッドを使用すると、ベンダーはコンパイラをハードウェアの機能に合わせて調整できます。彼らは自分のハードウェアを最もよく知っており、何をすべきか、何をすべきでないかを知っています。一方、不利な点は、複数のハードウェアベンダーが存在する世界では、シェーダーコンパイラー間で矛盾が発生する可能性があり、ベンダーも完全に自由に統治できることです。

HLSLメソッドを使用すると、Microsoftがコンパイラを制御します。誰もが一貫した技術ベースに基づいており、シェーダーが1か所で正常にコンパイルされた場合、どこでもコンパイルできるはずです。同じシェーダーは、ベンダーに関係なく同じコンパイル済み出力を生成します（他のすべてのものはもちろん同等です）。一方、HLSLコンパイラは「すべてで一貫して動作する」ものでなければならないため、最後の数滴のジュースをタンクから取り出すための特別なベンダー固有のトリックを引き出すことはできません。

これがHLSLの世界観を好むように思える場合、それは私がそうしているからです。以前は、異なるプラットフォームでの非常に一貫性のない動作にひどく噛まれており、場合によっては、機能するベースラインを取得するためだけにGLSLの負荷をARB ASMにロールバックしなければならないこともありました。NVIDIAのGLSLコンパイラは、ここでは特に悪名高いものと見なすことができます-HLSL構文とキーワードも受け入れます。つまり、注意しないと、NVIDIAでしか動作しないシェーダーを作成することになります。そこはジャングルです。

私は両方を使用していますが、glslから始めて、プロジェクトがそれを要求しているという理由だけでhlslに移行しました。選択を考えると、それはすべてGLSLです。glslは非常に滑らかで、hlslはエンジニアの趣味のベンチから出てきたように感じます。

Ogreに付属しているRTSS（Run Time Shader System）も検討してください。これはかなり新しいものですが、基本的には外部ファイルではなくコードでシェーダーを記述します。まだ実装していませんが、時間が来たら必ず使用する予定です。

Ogre wikiには、シェーダーを作成するためのチュートリアルの膨大なシリーズがあります。 http://www.ogre3d.org/tikiwiki/JaJDoo+Shader+Guide

あなたの元の質問については、Praetorが言ったように、それは実際には賛否両論の問題ではなく、どのレンダリングシステムを使用するかという問題です。OgreでDX / OpenGLを使用するのはプラグインを読み込むだけなので、ほとんどの場合、.cg形式を使用する必要があります。