« ちょっと湿っぽい話ですが | メイン | これが年末進行というものか?(微妙に違う) »

2009年11月02日

今年も残すところあと2月

Second Opinion:今週分これから
Tech-On!:今週分済
MJニュース:今週分済
ASCII.jp ロードマップ:26回分入稿済
ビジネスアスキー What's Up? Tech:10月末〆分入稿済。でも実は間違いがあった。まぁ初稿ん時に直そう。
某Web不定期連載:3回目着手
某Web記事:インタビューは終了
某Web記事:いろいろやっては見ました。
某Web記事:もうちょっと先
某Web記事:これからネタ考えます。というか何なんだ今年は一体...
某文章:そろそろやらないと

*****
急ぎのものはとりあえず片付いた。やっと落ち着いてIDFに取り掛かれる(おい)

# 某不定期連載も進めないと、
*****
流石にそろそろ真剣に64bitへの移行を考えるか、と取りあえず64bitのUltimateマシンを用意。このあたりを見ながら、試しに環境を作ってみる。

んで、やっぱり問題山積み。
・まともな64bitのアプリケーションランチャーが無い
・まともなキー変換ツールが無い
という時点で、「これは全然無理だ」という気になる。アプリケーションライチャー、今はSoH Launcher 3を使ってるのだけど、こいつは64bit環境でインストールできず。後継製品のSoH Evoは32bitモードで動作はするのだが、レジストレーションコードが入手出来ず。いやSoHをちゃんとレジストレーションしてるんで、本来ならばSoH Evoのレジストレーションコードは無償で入手できる筈なのだが、作者がメンテを放棄したようで、以前リクエスト送っても返事がなし(ソースコード公開してる時点で、もうメンテする気は無いのが明白)。これがまだVisual Studioでビルドできるなら自分で何とかする案もあるが、Delphiだと流石に...ということで、放棄。

同様にキー変換ユーティリティも無し。これまではAltIMEを使ってきたが、ここにもあるように、64bitモードでは動作しない。秀CAPSは64bit版があるけど、こっちはCaps/Ctrlの交換ができない(というか、やらないと筆者が明言してるし)。レジストリ書き換えは、1台だけならいいけど、今後台数が増えることを考えると、ちょっと面倒かなぁ、と。

あと微妙なところでEmigrant32が64bitモードで動かないというのがあって、あんまり致命傷ではないのだけど、ちょっと面倒。

よく「64bitに簡単に移行できた」とか言うヒトは居るけど、こーいう環境ツールは結構全滅状況がXPの頃から変わっておらず、それが厄介の元だったりする。自分で作れ、ということかもしれんが...

ちなみにH/Wは(PhenomII X4 965のお陰で)ベンチマーク用機材から外れたPhenomII X4 940にM3A32-MVP、RADEON HD 3870とWDの500GB×2という、これまた微妙に二線級マシン。まぁ性能的には十分なんだけど。

それにしてもWindows 7のUIが気持ち悪い。特にExplorerがすごくいや。Windows 2000の頃のExplorerに戻してほしい(XPもちょっと変なままなんだよなぁ)、というか、2000のExplorer.exe動かないのかな?ためしてみよう。せめて64bit XPのExplorerが動くだけでもだいぶマシなのだが。
*****
私個人からすると、OSというのは要するにアプリケーションを動かす土台でしかないわけで、だから使い慣れたアプリケーションが使えれば別にWindowsでなくてもいいし、逆に使えない新OSというのはまるで意味が無い。んで、例えばAltIMEとか、Firehand Emberみたいに「動きません」&「作者が死んじゃって、もうアップデートありません」&「同等の機能を持つほかのソフトが見当たりません」という状況では、積極的に移行する意欲が湧かないのは致し方ないところ。それでもサポートがなくなるだの何だのの理由で移行せざるを得ないわけだが、少なくとも前向きに移行する気にはなれないなぁ。Windows 7を入れて、その上でVirtual PCでXPを常時動かすのも手だけど、だったら最初からXPでいいじゃない、みたいな。困ったもんである。

# AltIMEはここのサムウィンさんの書き込み。Firehand Emberはこちらを参照
*****
ということで、とりあえず64bit Nativeで動くApplication Launcherとキー設定ツール(除秀CAPS)の情報を求む。CLaunchは今度試してみます。
*****
なんかすっかり定位置が655位になってしまった

投稿者 ohara : 2009年11月02日 12:27

トラックバック

このエントリーのトラックバックURL:
http://www.nekobaka.com/cgi-bin/MT-3.11/mt-tb.cgi/499

コメント

Bulldozerの整数演算における4つのパイプは
ALU+AGUのペア4つではなくてペア2つではないのでしょうか?
この辺はいろいろ意見が分かれているようですが・・・

投稿者 TLG : 2009年11月15日 02:15

これは色んな話が出ていますが、少なくとも現時点ではAMDは構成について何も言ってません。なので完全に推測ベースの話なんですが、K7→K8→K10とずーっと3 pipeでやってきて、もう3命令/cycleの実行効率がずいぶん上がってるんですよね。。最初はALU+AGU命令(LDとADDとかが一緒になったタイプですね)をMicroOps Fusionみたいに1 μOpsで処理する形で更に実行効率を上げるのかなと思ってたんですが、プレゼンみて考え変えました。個人的にはこの4pipe、K10までの対称型ではなく、3 simple AUL+1 complex ALUみたいな形になるかな?と思ってます。以前からSingle ThreadのIPC向上は引き続き続ける、とAMDは公言してますし、だとするとBulldozerが2 ALU+2 AGUではむしろIPC下がってしまいます。それにALUとAGUをわけるなら、Bobcatのプレゼンみたいな表現になるんじゃないかと思うんですよ。わざと表現を変えた時点で、私は2 ALU+2 AGU説には与しません。

もう一つの理由は、Bobcatを出すことで、Heavy Loadの対応が必要ないマーケットにはBobcatが使えることになります。だから、Bulldozerはサーバー〜ハイエンドデスクトップのHeavy Load Work向けの構成が取れますし、ならば4命令/cycleにチャレンジしても不思議じゃないと思うんですよね。んでBulldozerとBobcatの間はStarsの延長でカバーできますし。

という話は原稿に書くべきだったか?(笑)

投稿者 ohara : 2009年11月15日 17:14

こんなに詳細な返答を頂き恐縮です・・・!本当にありがとうございます。

非常に筋の通った説明で分かりやすかったです。
確かに2 ALU+2 AGU説では裏付けが薄いですね。
特にラインアップの観点から考えるのは目からウロコでした。

これにも関連して興味深い情報があったのですが
http://www.amdzone.com/phpbb3/viewtopic.php?f=52&t=137076
ここに書かれたChuck Moore氏の発言通りだとすれば相当リッチな構成ですかね?
(これまた解釈次第ではややこしくなりそうですが)。

もし出来るものであればどこかで記事にしていただけると大変嬉しいです。
しかしほとんど確定していない段階ではやはり難しいでしょうか・・・。

投稿者 TLG : 2009年11月17日 00:16

一応現時点で2箇所から、これについて解説をという話は頂いております。多分年末〜来年1月末のタイムフレームになると思いますが。

Chuck Moore自身はAnalyst Dayに出てきて無いので確認できないんですが、彼のプレゼンテーションをPatrick Patla(VP and GM, AMD Server Business)が引用しながらBreakout Sessionで説明しています。
http://phx.corporate-ir.net/phoenix.zhtml?p=irol-eventDetails&c=74093&eventID=2457771
音が割れてて結構聞きづらいんですが、それでもまぁ要点は大体。

目下悩んでるのは、Fetch→Decoderの構造なんですね。FMA4をサポートした時点で、恐らくバス幅は256bitで確定だと思うんですが、これがどういう構成だと2組の4 ALU Pipeにうまく命令配分できるか、がなかなか思いつかなくて。多分某G氏も同じこと悩んでると思うw

投稿者 ohara : 2009年11月17日 06:07

以前、バイオ5の国内版だと〜とコメントさせていただいたものです

今回の5970の記事でバイオ5に対して「小細工」が行われていると書かれていますが

1. 小細工=チート=描画内容が異なる手抜き という解釈でよろしいでしょうか?
2. (1.がYesの場合)チートが行われていると断定される根拠はお持ちでしょうか?

前回、海外版との比較を期待するようなことを書き込ませていただいたのは
性能差の原因がチートなのか(描画内容変化のない)最適化なのか
調査いただけないかなと期待していたからでして
そちらが判明しているようでしたらぜひ教えていただけませんでしょうか

投稿者 通りすがり : 2009年11月19日 01:14

βドライバではファイル名を変えるとスコアが明確に変わっている、というだけでかなりグレーだとは思います。

今回は検証の時間も無い(何をどう変更したのかの調査には、猛烈な時間がかかります)のと、正式版のCatalyst 9.11ではまだ検証していない(というか、公開される前に原稿の〆切が来たので検証不能)ので、あくまでもあの表現にしております。

その意味で1.はNot sure、2.はNoです。あくまで状況証拠にすぎません。

んで検証する時間があるか、と言われると当分は無理というお答えになります。バックログが猛烈に積み重なっているので...というか、調査そのものは単純で、例えばFLAPSなんかを使って、BH5DX10.EXEとBH5DX100.EXEの画面をキャプチャして、比較すればいいんですが、どんなオプションで違いが出るかどうかまで調べるには猛烈な手間隙がかかることだけは言えると思います。

投稿者 ohara : 2009年11月19日 02:29

ご回答ありがとうございます。

正直に言いますと、「グレー」ではなく
完全に「クロ」を前提としているように読めました。

以下はド素人の個人的見解ですが…

1. 「チューニングでこんなに上がるか?」について

 もともと、Radeonは演算器が過剰といっていいほどの構成なので
 ドライバがいかに飢えた演算器にうまく命令を与えられるかが
 鍵となってくると思います。

 チューニング前が最悪に近いの状況で
 チューニング後がピーク性能に近いような状況ならば
 2倍程度の向上はありえる範囲に思えます。

 もともと、他のアプリなら実効性能として競合といい勝負ができていますし。

2. 「ファイル名を変えるとスコアが明確に変わっている」について

 たとえば、以下のような仕組みなら「(チートではない)最適化」で
 「ファイル名によってスコアが変わる」と思います。

 ・知らないEXEファイル名の場合はコンパイラで
  (TransmetaのCMSの1st Gearのように)
  短い時間で終わらせるために浅い最適化を行う

 ・既知のEXEファイル名の場合は
  EXEファイル名とシェーダーコードをキーとして
  ドライバ内のデータベースから
  事前にオフタイムで高度に最適化されたネイティブコードを辞書引きして用いる

  もしくは

  EXEファイル名とシェーダーコードをキーとして
  最適化に有益なプロファイリング情報を使用することで
  より優れた最適化を行う

 ※単純にシェーダーコードだけをキーにしないのは
  ドライバという性格上、メモリ消費を抑えたいため…かな?

検証されるのは難しいということですので
もし、AMDの人とお話される機会などがありましたら
真相に迫っていただいてどこかにお書きいただければと存じます。

PS
もう御存知かもしれませんが、ATI Catalyst 9.11には
「バイオ5対応」が入っているようです。
http://www.4gamer.net/games/022/G002212/20091118011/

投稿者 通りすがり : 2009年11月19日 07:26

GeForceでもリネーム後のテストをしてみたらいかがでしょうか?

投稿者 alt : 2009年11月19日 20:32

えっとですね。もちろん特定のアプリケーションで高速化できるようなドライバの技法ってのはいくらでもあります。問題は、ではその動機なわけです。たとえばメーカーがあるプログラムの性能を改善するのに、ドライバレベルで手を入れないといけないor入れたほうが早い、ということはありえるでしょう。その場合、例えば開発費を払ってある種の特殊動作を組み込んとか、メーカー側でチューンしたドライバコードを組み込んでもらうというのはありえますし、過去にもありました(ATI/AMDじゃないですが)。逆パターンでは、昔AMDが何かの3DNow!対応版(Quakeだっけか?)をリリースしたこともあります。ただそうしたスピードアップの技法を、BH5にのみ施す理由がさっぱり思いつきません。

勿論バグ対策はありえます。ある種の対応が、ソフト側で行うのが非常に難しく、ドライバでAdHoc的に対応というケースは、非常に多いです。

確かにCatalyst 9.11のRelease Notesを見ると "Resolved display driver incompatibility with Resident Evil 5 Japanese release"という表記があるわけですが、これがドライバに起因する問題なのか、BH5に起因する問題でAMDがAdHocで対応したのか、これだけではさっぱりわからない訳です。この表現は実に微妙です。あと、「問題」というのが、いわゆるバグに属する問題なのか、それとも仕様に属する問題なのかも微妙です。以下の例はあくまで一般論(今回の問題がこれだと言っているわけではない)ですが、例えばアプリケーションが複数の描画オプションを組み合わせて発行したときに、GPU側がそれを全部まとめては実行できない(Antialias 6xとAnisotropic Filter 16xは可能だけど、Antialias 12xが指定されるとAnisotropic Filter 8xしかできない)なんて制限があったとします。その時にAntialias 12xとAnisotropic Filter 16xが指定されたら
(1) アプリケーションに「そんな指定は出来ない」といって返す
(2) まずAntialiasを掛けて一回画像を作り、それにあらためてAnisotropic Filterを掛ける(つまり二度手間になる)
(3) Anisotropic Filter 16xを優先してAntialias 6xに落とす
のどれが正しい仕様でしょう?これはドライバメーカーだけでは決められない問題で、恐らくアプリケーションベンダーと協議して対応を決めることになります。仕様の問題というのは、こーいう話です。

これはベンチマーカーにとっても問題です。ではこのケースでは、(1)〜(3)のどの形でベンチマークを取るのが正しいでしょうか?で、例えば最初は(2)だったのが(3)に変わった場合、ベンチマーカーはどう評価すべきでしょう?ゲームベンチは非常に身近なMethodなんですが、こうした問題は常に付きまといます。

話を戻します。今回の時点では、少なくとも特定コードが入っていることはまぁ事実だと思いますが、何が問題で特定コードを入れたのかは不明です。Jay Marsdenのcolumnでも特にこれに関しては何も書かれていません。AMDの人、といってもドライバの開発はカナダですので、現実問題として彼らとお話する機会は残念ながら皆無です(Mktg Mgrなどにはお会いできますが、彼らもドライバのそこらへんまで把握している訳ではありませんし)。現時点でわたしがコメントできるのはここまでですね。

あとGeForce系は元々SLI対応もあってアプリケーションプロファイル入ってるという、これはこれで別の問題がありまして(苦笑)

投稿者 ohara : 2009年11月20日 05:12

>一応現時点で2箇所から、これについて解説をという話は頂いております。
>多分年末〜来年1月末のタイムフレームになると思いますが。

おお、これは嬉しいですね。クリスマスかお正月の楽しみになりそうです。
この手の発表はサラッと流されるだけで考察などはあまり見かけない印象があるもので。

プレゼンについてなんですが
http://phx.corporate-ir.net/phoenix.zhtml?p=irol-eventDetails&c=74093&eventID=2457769

http://www.amdzone.com/phpbb3/viewtopic.php?f=52&t=137076&st=0&sk=t&sd=a#p170975

4つのBreakOut Sessionsのうち、APUのセッションでChuck Moore氏が
質疑応答にも応える形でBulldozerについても話しているので
そこからスライドに載ってない内容を時系列順に抽出したものと思われます
(と自分は判断したのですが、何か大きく勘違いしていたら申し訳ないです)

上記に関連して、Fetch→Decoderについては口を濁してるみたいですが
様々なPrefetchで何とかする、みたいなことを言っているようですね。

IntelのTrace cacheライク?なRedirect Recovery cacheの特許を
AMDが持ってるようなのでそれを採用するのでは?という見方もあるみたいですね
http://www.freshpatents.com/Redirect-recovery-cache-dt20080814ptan20080195844.php?type=description

投稿者 TLG : 2009年11月25日 02:46

粕だな…

投稿者 お : 2009年12月01日 10:25


性能が跳ね上がるからチート、俺(ohara)の勘だと最適化じゃない。
再検証する気はない、GFで同様のテストもしない。
AMDに聞いてみるけどチートで間違いないと思う。
聞いた結果はそのうち公開するかもしれない。


思考がメチャクチャ

要約すると
「俺(ohara)様がチートだと思ったからチートなんだよ」


投稿者 NB : 2009年12月01日 12:44

日本語版バイオが英語版のように最初から普通に動いてれば絶対チートなんて難癖つけなかったですよね。
あそこまでメディアで言い切ったのですから、ベンチで試したソフトを全てファイルネーム変えて試してみればいいと思いますよ。んでRADEON自体がチート製品だった!っていう展開を希望します。

AMDはバグを修正して普通のスコアにしてはいけなかったんですよ。それはチートなんですから!

話は変わりますが、カプコンやスクエニのPC版ゲームはNVIDIA製品に偏重されてRADEONでは不自然に性能が出ない事が多いですが(あくまでベンチでは)、これは当然の性能差による物なので、「これが一番体感に近い気がする」んですよね?
GeForceのドライバ更新でベンチスコアが上がることがあっても、こちらは「最適化」ですよね?

投稿者 ムー : 2009年12月01日 14:14

NB様&ムー様

既に私の見解は述べた通りです。それ以上でもそれ以下でもありません。

投稿者 ohara : 2009年12月02日 12:01

荒れるもととなる投稿になってしまったようでもうしわけありませんでした。

> ただそうしたスピードアップの技法を、BH5にのみ施す理由がさっぱり思いつきません。

すこし試してみたところではBH5以外にも「ファイル名を変更するとスコアが変わる」ベンチがありました。
(環境はVista 32bits SP2/HD 4850/Catalyst 9.11、
スコアは5回のうちの「最低〜中央値〜最高」で、それぞれ「リネーム前/リネーム後」)

LOST PLANET EXTREME CONDITION
 Snow 46.2/44.6〜46.2/44.8〜46.3/44.9
 Cave 58.7/54.2〜58.8/54.6〜59.1/54.7
(安定したスコアの出るベンチで、リネーム前の最低値>リネーム後の最高値)

Devil May Cry 4
 St1 117.47/112.05〜118.27/113.48〜119.22/114.58
 St2 75.69/73.58〜75.90/74.12〜76.69/75.78
 St3 141.68/134.07〜151.48/146.11〜156.68/148.35
 St4 90.23/82.22〜92.59/82.57〜93.61/84.16
(ステージ4が約10程度の差が出ており顕著)

World in Conflict
 Arg 35/35〜36/35〜36/35
 Min 16/12〜17/14〜18/14
 Max 59/59〜59/59〜59/60
(リネーム後の最低FPSは14が限界)

これらが全部チートなのか全部最適化なのか入り混じっているのかはわかりませんが
とりあえず、「BH5だけ」というわけではないように思えます。

> AMDの人、といってもドライバの開発はカナダですので、現実問題として彼らとお話する機会は残念ながら皆無です

大原さんが、海外の技術者にインタビューをされた記事をいくつも読ませていただいておりますし
http://www.4gamer.net/games/022/G002212/20080905042/
のような記事を読んだことがあったので少しは機会があるのではないかと勝手に期待してしまいました。

個人的にはRadeonのドライバ周りはAMDがこのアーキテクチャを継続するかの鍵となっているような気がしているのでかなり注目しています。(最低でもFusionがLlanoベースの間は生きつづけるようですが)
もし機会があればGPUのドライバ周りに関するお話を取り上げていただければと思います。

投稿者 通りすがり : 2009年12月06日 22:19

ども>通りすがり様

まぁこのコメント欄は、私にツッコミを入れるために開放している(ので、メールアドレスの入力すら求めていない)んで、突っ込みをいただける分には構わないんですが。

あと、善ちゃんと後藤さんは別格だと思ってください。特にGPUマーケットは。私はDX9の手前位でGPUを追うのをやめてしまって、CPUやMCUにフォーカスしたので、最新動向は全然なんです。彼ら2人は引き続きGPUマーケットをカバーしていて、特に善ちゃんはGPUをゲームから見たトレンドを日本で唯一カバーしているライターです(後藤さんはややGPGPU寄りですから)。もっともHPC絡みで、最近は私も「GPUはカバー外」とは言い切れないんですが。もう少ししたら、OpenCL絡みで再びGPUを追わないといけなくなりそうなんですが、まぁそれはあくまでGPGPUというポジションであって、GPUそのものとはちょっと違うかな、と。

で、例えば日本から我々ライターが渡米して向こうにAttendをお願いするわけですが、GPUに関して実績が無いライターがいきなりエンジニアに近い人とお話するのはまず無理です。Mktg寄りのMgrが出てくるのがせいぜいでしょうね。そうではなく、実績を積んで向こうにも顔が通り始めると、やっとそういう中の人とお話できるチャンスが廻ってくるというわけです。そんなわけで、これがCPUとかチップセットとかメモリとかバスであれば私もそれなりに顔が通るんですが、GPUとかHDD/SSDなんかは無理です。

んじゃ何でおまえがGPUのベンチやったんだ?と聞かれると「それは人が足りなかったから」という話ですな(笑)。ちゃんと環境を用意して比較ベンチ出来る時間・機材・環境があるライターさんはそう多くないので、他のライターさんが溢れるとこっちに廻ってきます。まぁハイエンドものはともかくミドルレンジに関しては編集部内で簡単にベンチ回して終わり、という事も多くなってきたので、最近はそれほど頻繁にやるわけではありませんが。ただ製品レビューそのものから手を引いた訳ではないので、求められれば今でも記事はやります。ロードマップ書いてるのもそうした一環です。ただそんなわけで、GPU Internalとかドライバ周りは、私ではなく善ちゃん方面にリクエストを出していただいたほうが確実です。

投稿者 ohara : 2009年12月07日 00:16

コメントしてください




保存しますか?

(書式を変更するような一部のHTMLタグを使うことができます)