7

私は C++ クロスプラットフォームの OpenGL アプリケーション (Windows、Linux、および MacOS) に取り組んでおり、大規模なアプリケーションを OpenGL 3 に移植するためのアドバイスを共有できる人がいるかどうか疑問に思っています。私が OpenGL 3 を検討している理由は、新しい「同期オブジェクト」を使用すると、多くのメリットが得られると思います。Nvidia は Geforce 256 日 (gl_nv_fences) からこのような拡張機能をサポートしていますが、OpenGL 3.0+ より前の ATI ハードウェアには同等の機能がないようです...

私たちのコードは、glut/freeglut、glu 関数、OpenGL 2 拡張機能、および CUDA (サポートされているハードウェア上) をかなり多用しています。私が今直面している問題は、「gl3.h」と「gl.h」が相互に互換性がないことです (gl3.h に記載されています)。GL3 glutに相当するものがあるかどうか知っていますか? また、CUDA ツールキット ヘッダー ファイルを見ると、GL-CUDA の相互運用性は、OpenGL の古いバージョンを使用している場合にのみ利用できるようです... (cuda_gl_interop.h には gl.h が含まれています...)。何か不足していますか?

どうもありがとうございました。

4

1 に答える 1

3

glutの最後の更新は、およそ10年前のバージョン3.7でした。それを考慮に入れると、OpenGL 3.x(または4.x)をサポートすることはないと思います。

OpenGlutに取り組んでいる人々は、OpenGL 3.xサポートの可能性を検討しているようですが、まだ何もしていません。

FLTKには(部分的な)過剰シミュレーションがありますが、それは「過剰を多用する」プログラムがそもそもそれで動作しないかもしれないほど部分的です。FLTKは活発に開発されているので、最終的にはOpenGL 3.x(または4.x)をサポートすると思いますが、まだ提供されているとは思いません。 。

編集:CUDAに関する限り、明白な(確かに重要ですが)答えは、代わりにOpenCLを使用することです。これは、ハードウェア(ATI / AMDボードなど)と新しいバージョンのOpenGLの両方とかなり互換性があります。

それはgluを残します。率直に言って、これに対する明確または明白な答えはないと思います。OpenGLは、gluのようなもののサポートから離れ、代わりに、コアOpenGL仕様の一部であった漠然としたgluのような機能(たとえば、すべての行列操作プリミティブ)のサポートを廃止します。個人的にはこれは間違いだと思いますが、良いか悪いかにかかわらず、それは状況です。残念ながら、gluはglutに少し似ています。仕様の最後の更新は1998年で、OpenGL1.2に対応しています。それでは、更新が行われる可能性はまったくありません。残念ながら、私はそれを実際に直接置き換えるものも知りません。(少なくともいくつかの)同様の機能を提供する他のグラフィックライブラリが明らかにありますが、私が考えることができるそれらのすべては、大幅な書き直しを必要とします。

于 2010-06-03T15:39:32.700 に答える