ナゼＶＲＡＭの読み込みは遅い？

質問

昨日質問を立てたのですが回答が付かなかったので、路線を変更して再質問させていただきます。
とりあえず今回はハードウェアカテで（笑）

１．（ＣＰＵから見て）何故ＶＲＡＭへの書き込みは速いのに、読み込みは遅いんでしょうか？

２．ＶＲＡＭの読み込みが速い機種もあると聞きますが、何処の何と言う機能（？）が改善に役立つんでしょうか？

近況は面倒なので昨日の質問をコピペ（笑）
>２，３年前、ＤｉｒｅｃｔＸでＰＣゲームを作っている際に、画像データの編集でＡＧＰの上りと下りの転送速度差で大いに苦労したのを思い出しました。
>当時は何も気にせず「そんなものか」と思ったものですが、今になって無性に気になります。
>というわけで、このあたりに詳しい方お願いします。

よろしくお願いいたします。

回答No.6

noname#11476 · ベストアンサー

補足読みました。

その場合だとCPUは遅いAGP経由でアクセスしますから絶対遅くなると思いますよ。
読み込みと書き込みをランダムに繰り返しますから。
そしてＣＰＵのキャッシュも効きません。
ＶＲＡＭの速度ではなくてＡＧＰの速度に制限されているんですね。
（ＶＲＡＭ自体は最近ではＤＤＲとか高速ＲＡＭを使うしバスも広いからかなり早い。）

対して単純に書き込む場合は、一度に転送できるのでＡＧＰのバースト転送で最大速度で送り出せます。
この差は非常に大きいですよ。
バースト転送でアドレッシングがいらなくなるとざっくり半分になりますので。

ＣＰＵ－ＡＧＰ－ＶＲＡＭのアクセスは当然（ＨＥＬで）転送するデータ量×２（ＣＰＵ行きと戻り）ですから、先のバーストとあわせて４倍違うわけですね。
（ＨＥＬでのＣＰＵ－メモリ間の速度も考えれば差が縮まるかもしれませんけど、でもＡＧＰよりは早いはず）

＞読み込みも速いマシンが存在する記述を見たことがあるんため、質問２が存在します（笑）。
う～ん（笑）、なんだろ。
もしこれの速度を早くしようとすると、、、、、

あ、そういえばメインメモリ上にＶＲＡＭを展開することが出来るので（たとえば815Eの内臓ビデオ）、それだったら違いはないですよね。
この場合ＶＲＡＭ＝メインメモリですから（そして画面表示用データをＡＧＰで送るんです）、速度に差は出ないかと。

お礼

度々ありがとうございます。

CPUは32bit、AGPは128bitですから、プログラム次第ではバースト転送に対してで２×２×４(128/32)倍かそれ以上の差がつくかもしれませんね。（8bit単位の処理など）
だんだん見えてきたような気がします。というかこれが決定打かな？？

当時のソースは残っていたと思うので、２については自分で調べてみたいのですが・・・今になってオンボードビデオのマシンを持ってないのが悔やまれます（笑）

回答No.5

noname#11476

あ、あともともとの書き込み／読み込みの速度差であれば、ＤＲＡＭだから読み込みの方が遅くなりますね。
これはＶＲＡＭでもメインメモリでも同じなんですけど、メインメモリはＣＰＵのキャッシュが効くのとメモリバースト転送なども出来るからメインメモリのほうが早そうですね。
ＡＧＰのバースト転送はＶＲＡＭ自体のメモリバーストを使っているわけではないでしょうから。（これは推測ですが）

回答No.4

noname#11476

あぁ、ごめんなさい。
ようやく言っている意味を理解しました。おまけに一つ前の補足のHAL/HELを取り違えていましたね。
すいません。

整理すると、ＣＰＵ－メモリ間とＶＲＡＭ－グラフイックチップ間は高速、でもＡＧＰは遅い。

動画については、

・ＣＰＵでの処理がメインとなる動画編集だとメインメモリで編集して送り出したほうがずっと早い。
（ＣＰＵから直接だと遅いＡＧＰを経由しなければならないから）

で理解できると思います。

ＨＡＬ＜ＨＥＬだったというのは、、、処理内容によるのではないでしょうか。
ＨＡＬのつもりでもそうなっていなかった場合、CPUが直接VRAMにアクセスしているかも知れないですよね。
ＨＥＬの場合だとメインメモリで処理してから転送するでしょうから。

そういう関係ではないかと？？？
＃ちょっと自信無しです。

補足

こちらこそ申し訳ありません、用語の使い方が悪かったです。
DirectXでHALの設定を行うとサーフェイス（画像イメージ）がVRAMに、HELだとメインメモリに作成されます。プログラム内ではHALとHELのフラグを変更するのみで、その他は一切変更無しです。
そしてその環境でCPUで画像加工を行うと、以下のようになります。

HEL：CPU-メインメモリ間で画像編集
　→最終的に出来上がったイメージをVRAMに転送、表示
　　＃VRAMに対して書き込みのみ
HAL：CPU-VRAM間で画像編集
　→直接VRAMに描画、表示
　　＃VRAMに対して書き込み、読み込みの両方

こういうことをすると、HALの方が圧倒的に遅いんです。

つまるところ下記ＨＰの下の方にある「▲VRAMにCPUでアクセスする時の注意事項」に書かれている理由が知りたいのですが・・・
http://www1.odn.ne.jp/ceb94660/memo/memo.html
偶然このページを見つけてしまいましたが、ここに書かれているように禁止されていたんでしょうか・・？

尚、他のBBS等で読み込みも速いマシンが存在する記述を見たことがあるんため、質問２が存在します（笑）

回答No.3

noname#11476

>ＨＡＬとＨＥＬ
それはＣＰＵの処理よりは専用チップの処理のほうが格段に早いに決まっていると思うのですが。
これって別に転送速度の話ではないと思うのですが。
ＨＡＬでの処理は画像転送でなくて、カード内の高速BUSを使って専用チップで処理なので。
HELだと汎用のCPUで処理→遅いバス→カード内VRAM転送ですよね。
二重に遅い処理があるとおもいます。

１０年以上前からのＶＲＡＭの変遷を考えれば、初めはＣＰＵからのアクセスと画像表示のためのアクセス(RAMDAC)の両方をシェアしていたので遅くて、でもDual Port RAM（ＣＰＵ側のアクセスと独立にRAMDACからアクセス可能）になってかなり改善されましたね。
その後も変遷を続けていて、AGP4X位のビデオカードになればカード内のBUSは128bit位のバス幅でしょうからカード内は非常に高速だと思いますよ。

回答No.2

noname#11476

それはもちろんバス転送速度はメモリ間よりも周辺機器用のバス（ＰＣＩ、ＡＧＰ）の方が遅いからでしょうね。
メモリバス６６ＭＨｚの自体ではＰＣＩは３３ＭＨｚだったし、メモリバス１００ＭＨｚ／１３３ＭＨｚの現在主流はＰＣＩより早いＡＧＰ（×１）ですがそれでも６６ＭＨｚですから。

あとメモリ直接の場合はreadでキャッシュが効くので、これもまた速さを感じる理由ですね。

補足

すみません、ちょっと納得しがたいのですが・・・
ＶＲＡＭのＲｅａｄ／Ｗｒｉｔｅの速度差の回答にはなっていないような気がします。

昔作った自作の画像加工ルーチンを伴うヘボプログラムで、ＨＡＬとＨＥＬとを比較して、１０倍以上ＨＡＬの方が遅かった経験があります。
インターフェースによる速度差は認識してますが、コマンド応答やらタイミングの問題を考慮しても、ここまで差がつくとそれ以外の問題が大きいと思うんです。（ちなみに当時使用したＰＣはＡＧＰ４ｘ、ＰＣ１３３のメモリアクセスよりもＶＲＡＭアクセスの方が理論上高速でした）

プログラムに欠陥があり、実際はＶＲＡＭのＲｅａｄ／Ｗｒｉｔｅの速度差が、メインメモリのＲｅａｄ／Ｗｒｉｔｅの速度差と大差ないとしたら、例えば動画編集ソフトはＶＲＡＭを使用した方が効率が良い場合が多いと思いますが、残念ながらそういう市販ソフトは見かけません。
ですから何かがあると思うのですが・・・

これらの認識は間違っているでしょうか？

回答No.1

noname#25358

１．について心当たりがあるので。

　大昔の話なんで現状がどうか分かりませんが、昔のＲＡＭは、パソコンの種類によっては読み込みが遅いのが当たり前でした。（たとえばＭＳＸとか(笑)）
　というのも、ＲＡＭというのは種類によっては「破壊読み込み」という方法によって読み込みを行うからです。

　ＲＡＭのあるビットからデータを読み込もうとすると、そのビットに電気信号を送らなければいけません。
　ところが、ＲＡＭのビットというのは電気信号によって反転する性質があるため、データを読み込むと、読み込み元のビットの情報は破壊されてしまうのです。
　なんで、次のプロセスに移る前に再書き込み作業が必要になり、結果として読み込みだけが遅くなります。

　現在、破壊読み込みせずにすむのが主流なのか、いまだ破壊読み込みが主流なのかはよく分かりません(^_^;
　それどころか、破壊読み込みしないＲＡＭというのが存在するかどうかも分かりませんが(笑)

お礼

ありがとうございます、勉強になります。
たしかにメインメモリでさえ、多くのベンチ結果を見てもWriteよりReadの方が遅いですから、破壊したものを修復しているのかもしれませんね。

ただ気になる点が、いくら遅いといっても、メインメモリの場合は倍も違いなかったと思いますが、ＡＧＰやＰＣＩ接続のビデオカードのＶＲＡＭの場合、比較にならないほど遅かったと記憶しています。（コレが間違い？？）
ならばオンボードビデオでメインメモリを共有する物が同程度、ということになるんでしょうか・・？
う～む・・・