問題タブ [tegra]

Tegra 2/3 SOC は、通常の /dev/graphics/fb0 dev を使用したフレームバッファへのアクセスを提供しません。grallocメソッドを使用してフレームバッファをキャプチャすることはまだ可能であるようで、実際にはいくつかのアプリケーションがすでにこのメソッドを使用しています.

gralloc からの読み取りを許可する Nvidia からのパッチがあったようです。ソースはここにあります。それはかなり古く、今までにアンドロイドに多くの変更がありました。

Androidの最近のバージョンは、グラロックバッファを読み取る方法を提供していますか?

カーネルをビルドするか、idcデバイスを変更する必要があります。カーネルをHCからICSにバックポートすることもできます。どうすればこれを修正できますか？

私は現在、opengl ES 1.1 ゲーム、最小 sdk 8、ターゲット sdk 17 に取り組んでおり、アクセスできる 4.0.3 タブレットの eglSwapBuffers で異常に大きな遅延が見られます。これは、Android の新しいバージョンでも古いバージョンでも表示されません。 . また、幸運にも 2 台の Asus 変圧器 T101 にアクセスできました。そのうちの 1 台は Honeycomb を実行しているため、これがハードウェアの制限である可能性を排除できます。

次の表は、デバイスの数とそのパフォーマンスを示しています。

古いシングル コア GTP1000 でさえ、デュアル コア 4.0.3 デバイスの 2 倍のフレームレートを取得することがわかります。

2D キャンバス、GL、UI、および 200 ミリ秒ごとに AI を更新するハートビートの 4 つのスレッドを実行しています。GL スレッドでの eglSwapBuffers 呼び出しの間、CPU はほとんど何もしていません。ある種の省電力または GPU スロットリングをトリガーしているように感じますが、これに関する情報を見つけることができませんでした。

他のすべての操作にコストがかからない場合、スワップ バッファーにかかる時間だけでフレーム レートが 15FPS 未満に制限されます。フレームごとに 150 のテクスチャ トライアングル ストリップ クワッドを描画しています。

あなたが私を正しい方向に向けることができれば、私はわくわくする.

GPU (OpengGL ES 2.0) でカメラ プレビュー ストリームのライブ フィルタリングを行うアプリを開発しています。有名なアプリ「ペーパーカメラ」（有料）や「漫画カメラ」（無料）に似ています。

私のgalaxy s2では問題なく動作し、非常に高速で、s3ではさらに高速で、古いSamsungデバイスでも問題ありません. また、Sony Xperia Arc Sとhtcの欲求、および覚えていない他のいくつかのデバイスでもテストしました.s2ほど高速ではありませんが、少なくとも10 fps以上です.

ここに問題があります: 昨日、HTC One X+ と Galaxy Tab 10.1 (それぞれ tegra 3 と tegra 2) でテストすることができました。x+ では約 5 fps で実行され、タブレットでは約 2 fps で実行されます。

また、前述の同様のアプリ (ペーパー カメラと漫画カメラ) を 1 つの x+ で試してみましたが、ハードウェアが優れているため、より高速に実行する必要がありますが、galaxy s2 と比較してかなり低速で実行されます。

テクスチャのアップロード速度 (すべてのビデオ フレームに対してテクスチャを作成する必要があります) に関する tegra GPU の既知の問題、または速度を大幅に低下させる可能性のあるその他の問題はありますか?

PS: カメラ プレビューの解像度を下げると、少し速くなりますが、それでも厄介なほど遅くなります。

p _aを (0.5, y ) の点、p b_を(5.5, y ) の点とする。p _aからp _bに線分を引くと、x軸上に 5 ピクセルの線分が得られます。問題は、これらのピクセルが正確にどこにあるかです。

OpenGL ES 2.0 仕様 3.4.1によると:

p _aとp _bがフラグメントの中心にある場合、フラグメントのこの特徴付けは、1 つの変更を加えた Bresenham のアルゴリズムに帰着します。この記述で生成される線は「半分開いた」ものであり、最終的なフラグメント (p b に対応する)は_描画されないことを意味します。

p _aからp _bまでのセグメントを描画すると、ピクセル 1 から 5 ( x座標) が得られます。p _aは最初のピクセルの中心にあり、p _bは 6 番目のピクセルの中心にあります。p _bからp _aに描画すると、2 から 6 になります。これは、iPhone 4s で取得した結果です。ただし、Android (Nexus 7およびエミュレーター) では、結果は常に 1 ～ 5 です (方向は関係ありません)。描画コードはまったく同じです (NDK を使用)。

問題は、どの動作が正しいかということです。また、両方のシステムで同じ結果を得るには、どのような回避策を使用する必要がありますか?

編集

Mac OS で次のコードを実行すると (単純なNSOpenGLViewサ​​ブクラスを使用):

次の結果が得られます。

ということで、期待通りの結果です。また、Nexus 7 では仕様の解釈が異なるか、特別な設定を有効にする必要があるようです。

編集2：

私のエミュレーターは画面に収まらず、画面出力を再スケーリングしていたため、エミュレーターがデバイスと同じ問題を抱えているという錯覚が生じました。DDMS でスクリーンショットを撮った後、エミュレーターが期待どおりの結果を生成することは明らかでした。

しかし、デバイスは次の結果を生成しています:

これを再現するには、gl_code.cpp ファイルの内容を次のコードに置き換え、 hello-gl2 ndk サンプル プロジェクトを実行します。

Google Nexus 7 でマルチスレッド Java プログラム (MapReduce スタイル) を実行しようとしましたが、実行時間を次のように測定しました。

以下のように、パフォーマンスが大きく異なることがわかりました (4 コアの Tegra 3 で 4 スレッドを使用)。

704 872 729 729 1086 778 1214 1045 749 768

しかし、シーケンシャル バージョンを使用すると、次のような安定したデータが得られました。

928 851 850 842 863 917 873 905 853 870

ガベージコレクターは並行しているのでコアもかかると思っていましたが、それが大きなばらつきの原因ですか？

パフォーマンスがシーケンシャル バージョンよりもさらに悪い場合があるのはなぜですか?

複数の ARM A9 プロセッサを搭載した Nvidia Tegra 2 や Tegra 3 などの ARM Cortex-A9 プロセッサから作成された SoC の L1 アクセス レイテンシと L2 アクセス レイテンシを探しています。

これらのアーキテクチャの L1 と L2 のサイズに関する情報はいくつか見つかりましたが、L1 と L2 のアクセス遅延に関する情報はあまり見つかりませんでした。私が見つけた唯一の信頼できる情報は、「L2 キャッシュのレイテンシーは、Tegra 3 では 2 サイクルよりも 2 サイクル高速ですが、L1 キャッシュのレイテンシーは変わっていません」というものです。

Tegra 2 の L2 のレイテンシは 25 サイクルであり、L1 のレイテンシは 4 サイクル、L2 のレイテンシは 31 ～ 55 サイクルであることが示されています。これらの参照はどれも完全に信頼できるものではありません。Nvidia、TI、および Qualcomm の Web サイトと技術文書で詳細情報を見つけたいと思っていましたが、うまくいきませんでした。

編集: OMAP4460 や OMAP4470 などの同様の SoC に関する情報も役立ちます。

これは、このプログラムが Tegra 3 デバイスでいくつかのクワッドをレンダリングした結果です。

私が使用しているテクスチャは空の透明な png ですが、このテクスチャに何を入れても、これらのワイヤフレームは常に表示されます。

Mali-400 デバイスで同じコードが正常に動作します。Tegra fwidth の実装が適切か、コードに問題があるかを誰か教えてもらえますか? 上記のコードは単なる例であり、シェーダーのエラー部分のみを示しています。

こんにちは私のレンダリングはTegra3デバイスで非常にグリッチです..これがどのように可能であるかについてのアイデアはありますか？これが2つの画面です。最初のものはAsusA510タブレットからのグリッチなもので、2番目は私のギャラクシーネクサスでの正しいレンダリングです

そして、これがレンダークラスの私のコードです：

ありがとうございました...

TegraプロセッサでのCUDAの使用については、かなり多くのSIMDコア（〜72）を提供しているにもかかわらず、何も見つかりませんでした。NVIDIAは現在、Tegra開発キット（Androidベース）を通じてTegraに開発努力を集中しているようです。

だから私の質問は、「Tegra 4またはその前身でCUDA（またはOpenCL）を使用することは可能ですか？もしそうなら、どのバージョンがサポートされていますか？」