総じて･･･

･･･AMDプロセッサプラットフォームは、オーバークロック(OC)耐性が高い。

◆ だが、

どのようなプロセッサでも、仮にOCしていなくても、半導体レベルでの誤動作は 絶対にある。

それらエラーに対し、適切な修正が行われるよう構成された設計が、プロセッサや周辺半導体にも OSにも 要求される。

AMD勢でいえば FXプロセッサのOC性能は 安定性も含めて極めて高いコトは既知だろう。
またGPUも (先頃発表されたRX480は別として) RADEONシリーズのOC耐性の高さと安定性は実績がある。


◆ そして、

どのカテゴリの半導体であれ、処理中には必ず演算や通信に失敗し、それを正す処理が実行される。
これらの処理に用いる時間分、OSやデバイスドライバの構造には、充分な余裕を持たせる必要がある。

◆ それは

グラフィックを担当する半導体(GPU)とて例外ではなく、それを稼働させるドライバも然りだ。

具体例を挙げるなら、MicrosoftのWindows VISTA/7/10 は、こうした時間処理に強く、

尚、Windows10では、Windows7以上に この点、飛躍的に向上している。

だがそれは、古いモノを切り捨てて得た水準であり、
ルールに従っていないアプリケーションに対する線引きは、以前以上に極めて厳しくなっている･･･

そうした意味で、多くの32bitビルドアプリケーションが 現状、
Windowsアプリケーションとしての要件を満たしていない点を添えておく。

AMDのディスプレイドライバも、201308以降の版から堅固な構造となっている。


･･･コレでインフラは整った。 さて、これを安定稼働させるには?

■ 大前提として、

◆ 利用アプリケーション側でも 同様の配慮を施さない限り、絶対に安定稼働は担保されないのだ。

この点で nVIDIAプラットフォームは貪欲にして貧弱だ、

PCIeを介したデータ通信のタイミング１つ取ってもピーキーで、そこに余裕など配慮されておらず、
これらに合わせられたアプリケーションも同様の問題を引き起こす･･･


この問題を緩衝する機能は、WindowsVISTA/7/10 いずれでも提供されてはいる･･･
が、それを充分活かすには、最低でも 対象のアプリケーションで、それに合わせた余裕を持たせた適切なチューニングを要する。

■ また･･･

◆ OSでの メモリ管理機能に準拠する必要に迫られる。

具体的には プロテクトメモリの動作仕様な訳だが、コレが少し厄介だ･･･

★ アバウトに解説すると、

ユーザー側からは改変出来ないシステムに定義された指定時間経過毎に、メモリ上にロード済みの
OSやアプリケーションで用いるライブラリ他 動作に関わるデータのメモリ上の配置を、
ランダムに変更(複製ではなく移動、呼び出す為のアドレスも変わる)する と云う動作を行う構造。

コレに寄り、クラッカー(悪意のある不正アクセス実行者)に因る、

メモリにレイアウトを済まされた機能へ、特定の固定アドレスをターゲットとして行われるアプローチ
を 内外いずれからのプロセスであるかを問わず回避する。

昨今ではトクに重要なセキュリティ機能であり、サスガにナイと困るであろうモノの１つだ。

この仕様でメモリ管理されていない場合、攻撃者は、
特定アドレスをアタッチするだけで、システムの破壊やデータの改竄／引き出しが可能になる。


しかし、これを適切に稼働させるには、アプリケーション側で正しい時間情報を保持し 且つ、
変動に 余裕を持って 対応出来ていないとならない。


■ そう、

◆ 時間に関わる処理や

･･･用いる処理を行う場合、(64bitレジスタを直接扱えない)32bitビルドは不利にして非力なのだ。


尚、
短時間利用し すぐ終了させるアプリケーション
　で あれば、こうした配慮を要するシーンは、
　むしろ 稀有だと云える。

しかし、小一時間以上稼働させ 且つ、大量の時間処理を用いる場合は、

64bitビルドでは必要の無い、あり得ないほど丁寧な処理の構成
　を行っていない限り、
32bitビルドアプリケーションでは確実に、この問題で 
メモリ上のライブラリがレイアウトされているアドレスの取得に失敗する。

その結果として意図しない不正アクセスを実行し、まずはドライブへの書き込み権限の一部を喪失する。
続いて ポリシーで定義された限度を超えた場合、Windows側からアプリケーションの稼働許可が取り消され、
強制停止を喰らい、不正なメモリアクセスをした としてエラーコードが返される。

★ そして･･･

PSO2 の ような 大規模アプリケーションを、32bitビルドした場合、
必要な量のメモリを、'32bitアドレッシングで得られる分' ずつ、細切れに確保して稼働するしかない。

当然、各メモリ間、メモリからプロセッサ や GPU への リード/ライト 全てに、適切なアドレスで通信を行わせる必要がある。

※ 大規模なメモリ空間を扱える 64bitビルドなら必要は無く、関連するルーチンや通信を
　　大幅に削減出来る事で、全体のパフォーマンス向上の他、消費電力抑制効果も期待出来る。

もし、これらのアドレスの取得が失敗していたとしたら･･･ 既に云わずもか だろう。

◆ これこそが

★ PSO2の不安定要因そのものである。

以前 PSO2 は、自身のマッピングされるメモリ領域すら Windowsに対して隠蔽してた為、
このプロテクトメモリの稼働要件を満たさず、不正メモリアクセスで頻繁に停止していたのは記憶されているだろう。

★ だがこれは、

隠蔽しなければ発生しない問題ではナイ、時間情報を適切に取得／保持出来なければ、同じ結果となるのだ。

◆ 対象が

32bitアプリケーションであるなら、それに必要な緩衝処理を適切に設けているか が問われる。

もし これを、手を抜いて省きたいと云うのなら、

64bitビルドアプリケーションとして提供する必要に迫られる。
　と、云うワケだ。




PSO2運営には、早急な対応を求めたいトコロだ。