AMD Radeon HD6800ドキュメントがリーク – BartsがHD6800シリーズとなる?

vr-zone.com AMD Radeon HD 6800 Document Leaked Published on Friday, October 8 2010 2:59 pm by Sub より。

新たに登場する予定のRadeon HD6800シリーズのPDF概要ドキュメントのスクリーンショットがリークした。出典はIT.com.cnで、Chiphellが掲載した。だけれどもドキュメントは簡体中文であるが、いくつかもの詳細が暴露されている。たとえば命名体系やトレードマークの特徴などが英語で書かれている。予測されるRadeon HD6870の特徴はGDDR5メモリとPCI Express 2.1 x16をサポートし、DirectX11やEyefinityに加え、「EyeSpeed」と呼ばれる機能jが追加されている。UVD3も記載されているが、詳細は中国語である。意外ではないが、AMDはついにnVidia 3DVisionの代替技術を導入している。名前はAMD HD3Dである。そして極めて重要な情報がこの後記載されているが、Barts XTとはAMD Radeon HD6870であり、Barts Proは Radeon HD6850のことである。

噂では長い間Bartsはメインストリーム向けHD5700 Juniperの置換えであり、Caymanが性能重視のCypressの置き換え、dual-Caymanが高性能であるAntillesプロダクトであると信じられていた。これはBartsはHD6700、CaymanはHD6800、AntillesはHD6900であると論理的に導き出された結果である。BartsがHD6700の代わりにHD6800となるとしばらく噂が流れていたが、当初は高性能を重視する消費者によって無視されていた。だけれども、PDFドキュメントが正式なものであると仮定するのなら、もしBartsは実はHD6800であり、CaymanとAntillesはどの位置づけになるのだろう?確かに、CaymanはHD6850/6870になることが出来るが、Antillesについてはどうなるのか?そのスライドはまたAMDの命名他医系に衝いて言及しており、確実な接尾辞は「30」「50」「70」であり、HD6900は不確実である。それに加えこ噂のAntillles Proは事実ではない。そしてもしBartsがHD6800であり、この意味がHD5800より遅いのかかろうじて速いのだろうか?

明らかにいくつかの噂と数多くの相反する情報であり、多くのことが命名体系から推測する必要がある。

加えて、Chiphellの投稿者はHD6800の価格は300ドル未満であると強調している

参考元:Chiphell

Ubuntu Linux 10.10 Maverick Meeakatのリリースに向けてフリーズ宣言 – リリースまでバグつぶし

gihyo.jp Ubuntu Weekly Topics 2010年9月24日号 10.10のFinal Freeze・Papercuts(6)・UWN#211・Hardware Summit・カーネルのセキュリティアップデート  2010年9月24日 吉田史

gihyo.jp  2010年10月1日号 10.10のRC・Ubuntu Font・10.10のPapercuts(7)・UWN#212・9.04のEOL・LibreOffice 2010年10月1日 吉田史 より。

Ubuntu Linux 10.10 Maverick Meeakatのメジャーリリースに向けてリポジトリパッケージのフリーズが宣言された模様。あとはひたすらバグつぶし。

あとはユーザ操作を損ねるバグや挙動を100個潰していく修正マラソン「Hundred Papercut」で下記の内容が修正された模様。

  • LP#16492 マウスが利用されていない状況でキーボード入力があった場合,マウスカーソルを隠すべき。
  • LP#44082 何かの弾みでGNOMEの右側にあるべきアイコンが移動してしまうのを何とかしたい。
  • LP#206837 geditのウインドウの右端に,なぜか1ピクセル分の空きがある。
  • LP#386900 「Auto eth0」ではなく「eth0」と表記されるべき。
  • LP#387799 Nautilusと,GTKのファイルダイアログの間でファイルの並び替え機能が合致していない。
  • LP#410636 右クリックで開かれるメニューにおいて,「右クリックによってメニュー項目を実行できる」ようになっているため,油断するとメニューを開いた瞬間に処理を実行してしまうことがある。
  • LP#530751 「バッテリが放電中」ではなく「バッテリで動作中」とすべき。感電しそう。
  • LP#376966 gdebiがパッケージをインストールする際,「完了したら閉じる」チェックボックスを一度チェックしたら,それ以降のgdebiの利用時にも覚えておいてほしい。
  • LP#509656 ファイルの「詳細」表示時,時刻で並び替えを行った際,右端に表示される矢印の向きがNautilusとファイルダイアログで逆転している。
  • LP#550955 Software CenterのAboutダイアログが,設計と違ってモーダルダイアログになってしまっている。
  • LP#616569 Jockyの処理中,タイトルのついていないウインドウが表示される。
  • LP#39328 ウインドウ上でマウスホイールのスクロールを行うとウインドウが切り替えられる機能は,ノートPC上で悲惨な挙動になるので止めた方が良い。
  • LP#342567 NotifyOSD環境では,特定のキーを押し続けることでアクセシビリティ設定を行うことができない。
  • LP#395692 メニューエディタ上でドラッグアンドドロップすると,場所によって全く異なる操作になる。
  • LP#442940 インストール時にユーザー名を登録する際,スペルチェッカをかけた方がよい。ミススペルで悲しい想いをすることがある。
  • LP#507788 ヘルプにおいて,目次が表示される場所を左右どちらかに統一すべき。
  • LP#391223 Bluetoothデバイスをダブルクリックしたら,デバイス上のファイルを閲覧できるようにした方がよい。
  • LP#411559 管理者権限を利用した操作を行う時のパスワード認証においては,間違ったパスワードが入力された場合は「認証失敗」ではなく「パスワードが違います」といったものを出力した方がよい。
  • LP#618723 「アップデート・マネージャ」は「ソフトウェア・アップデータ」の方が分かりやすい。
  • LP#387382 アップデート・マネージャは,アップデートを試みる前にインターネット接続を確認すべき。
  • LP#66015 一部のアプリケーションで,スペルチェック辞書を選択するメニューで同じ言語を意味する項目が重複している。
  • LP#111939 ドラッグアンドドロップ中,Alt+Tabが効かないのは直すべき。
  • LP#155930 Synapticにおいて,「すべてのマークを外す」と,インストール済みといった情報まで消えてしまう。
  • LP#393358 Synapticやダウンロードマネージャで,ダウンロードが完了すると「ダウンロード速度」が「不明」になるのはナンセンス。
  • LP#426708 アップデート・マネージャにおいて,「バッテリで動作しています」という警告は良くない。「安全にアップデートするにはAC電源に接続すべき」といった記述にすべき。
  • LP#426710 ACアダプタを接続しているのに,「バッテリで動作しています」という警告が消えない。
  • LP#484249・LP#494772 アップデート・マネージャが自動的に起動したあげく,いきなり「バッテリで動作しています」と言い出すことがある。何のことだか分からない。
  • LP#492825 Ubiquityにおいて,「インストール」ボタンにアクセラレータ(ショートカットキー)が設定されていない。
  • LP#515682 「デスクトップを表示」のキーバインドは,Windowsと同じくSuper+Dにすべき。
  • LP#531400 インストール直後に生成される~/Examplesディレクトリに,異常に古いファイルやよくわからないファイル名のサンプルが放置されたままになっている。
  • LP#555213 プリンタジョブの表示部分だけ,システムのテーマの設定を無視している。
  • LP#586928・LP#600804 アップデート適用後の画面表示において,メニューに「再起動が必要です」と表示するのでは目的が不明瞭。「再起動(アップデート完了には必須)」といった 記述になるべき。しかも状況によっては,不要パッケージの削除の後に表示されるので,削除完了には再起動が必要なのかと思わされる。難解なので操作UIを 整理しなおすべき。

できればRadeonオープンソースドライバのGallium3Dでのバージョンアップが含まれていると嬉しい。(すぐにxorg-edgersいれるだろうけど)

  • LP#39328 ウインドウ上でマウスホイールのスクロールを行うとウインドウが切り替えられる機能は,ノートPC上で悲惨な挙動になるので止めた方が良い。
  • LP#342567 NotifyOSD環境では,特定のキーを押し続けることでアクセシビリティ設定を行うことができない。
  • LP#395692 メニューエディタ上でドラッグアンドドロップすると,場所によって全く異なる操作になる。
  • LP#442940 インストール時にユーザー名を登録する際,スペルチェッカをかけた方がよい。ミススペルで悲しい想いをすることがある。
  • LP#507788 ヘルプにおいて,目次が表示される場所を左右どちらかに統一すべき。
  • LP#391223 Bluetoothデバイスをダブルクリックしたら,デバイス上のファイルを閲覧できるようにした方がよい。
  • LP#411559 管理者権限を利用した操作を行う時のパスワード認証においては,間違ったパスワードが入力された場合は「認証失敗」ではなく「パスワードが違います」といったものを出力した方がよい。
  • LP#618723 「アップデート・マネージャ」は「ソフトウェア・アップデータ」の方が分かりやすい。
  • LP#387382 アップデート・マネージャは,アップデートを試みる前にインターネット接続を確認すべき。
  • LP#66015 一部のアプリケーションで,スペルチェック辞書を選択するメニューで同じ言語を意味する項目が重複している。
  • LP#111939 ドラッグアンドドロップ中,Alt+Tabが効かないのは直すべき。
  • LP#155930 Synapticにおいて,「すべてのマークを外す」と,インストール済みといった情報まで消えてしまう。
  • LP#393358 Synapticやダウンロードマネージャで,ダウンロードが完了すると「ダウンロード速度」が「不明」になるのはナンセンス。
  • LP#426708 アップデート・マネージャにおいて,「バッテリで動作しています」という警告は良くない。「安全にアップデートするにはAC電源に接続すべき」といった記述にすべき。
  • LP#426710 ACアダプタを接続しているのに,「バッテリで動作しています」という警告が消えない。
  • LP#484249・LP#494772 アップデート・マネージャが自動的に起動したあげく,いきなり「バッテリで動作しています」と言い出すことがある。何のことだか分からない。
  • LP#492825 Ubiquityにおいて,「インストール」ボタンにアクセラレータ(ショートカットキー)が設定されていない。
  • LP#515682 「デスクトップを表示」のキーバインドは,Windowsと同じくSuper+Dにすべき。
  • LP#531400 インストール直後に生成される~/Examplesディレクトリに,異常に古いファイルやよくわからないファイル名のサンプルが放置されたままになっている。
  • LP#555213 プリンタジョブの表示部分だけ,システムのテーマの設定を無視している。
  • LP#586928・LP#600804 アップデート適用後の画面表示において,メニューに「再起動が必要です」と表示するのでは目的が不明瞭。「再起動(アップデート完了には必須)」といった 記述になるべき。しかも状況によっては,不要パッケージの削除の後に表示されるので,削除完了には再起動が必要なのかと思わされる。難解なので操作UIを 整理しなおすべき。

nVidiaはCUDAのx86アーキテクチャへの最適化にほとんど興味がない – アナリスト談

xbitlabs.com Nvidia Hardly Interested in Optimal Performance of CUDA on x86 Processors – Analyst. Despite CUDA x86 Cross-Compiler, Life of Programmers Will Not Get Easier [09/28/2010 07:49 PM] by Anton Shilov より。

nVidiaはCUDAのx86アーキテクチャへの最適化にほとんど興味がない – アナリスト談

CUDAのx86向けクロスコンパイラに反して、プログラマの生活はより良くはならないだろう。
Anton Shilov
2010年9月28日

nVidiaとPortland Groupは先週nVidia CUDAアーキテクチャからx86へ、又は逆にx86からCUDAへソフトウエアを開発することができる特別なコンパイラを登場させた。これはソフトウエア開発者が彼らのプログラムに広く互換性を保証し、高並列GPUアーキテクチャを活用できることを提案している。だけれども、ソフトウエアメーカの生活はより良くなることはないだろうと、Jon Peddie ResearchのAlex Herreraは語った。

異なるアプリケーションのため、これらにはスーパーコンピュータ分野も含まれるが、より高い性能を照らす光明があるにもかかわらずATI RadeonやnVidia Geforceのようなグラフィクスプロセッサのために作り直されることはない多くの理由がある。主な理由の一つは、これまでも使われているレガシーなコードがあり、既に業務で使用されているためほとんどど捨てることができない。コンパイラはPGIとnVidiaが共同でソフトウエア開発者にCUDAベースのソフトウエアをx86プラットフォームにアプローチすることでテストしてもらいたがっており、信頼度を測ってもらいたがっている。それにもかかわらず、十分に安定して動作しているが、CUDAベースのソフトウエアのx86アーキテクチャでの性能はほとんど最適化されていない、とHerrera氏は主張している。

GPUベースのnVidia PhysXがそうであるようにCUDAもまたSSE2等のSIMDインストラクションをサポートしていない。新しいコンパイラはAMD BulldozerやIntel Sandy Bridgeマイクロプロセッサで使われる予定のAVXのようなものもサポートしないだろう。その結果、アプリケーションソフトウエアはx86プラットフォームでは最高性能を発揮できないだろ。

「x86で動作するCUDAはCUDAを使用しないでx86アーキテクチャに最適化されたアプリケーションソフトより遅くなるだろう。そしてx86で動作するCUDAアプリケーションやFermiで動作するアプリケーションを動作させる開発者は、最初に簡便に最適化できるCUDA無しのx86プラットフォームのほうが他のCUDAベースのアプリケーションよりも速く動作するのを目撃するだろう。より大きな性能向上によるベンチマーク数値はnVidiaが多くの浮動小数点演算を多用するアプリケーションソフトウエアでCPUよりもGPUのほうがより速いと宣伝する目的で使用されるだろう。」とアナリストは語った。

最後に、特定の目的および一般向け商用ソフトウエアの設計者は異なるハードウエアのために異なるコードを実装する必要が出てくるだろうし、いくつかは既に行われている。


開発側の負担が大きくなるだけで誰も得をしないということだな、nVidiaのCUDAは。あくまでも宣伝用でしか無いと。

AMDの次世代GPU Radeon HD6000シリーズのローンチが遅延し、その間にnVidiaはGPU価格を更に下げる

digitimes.com AMD to delay the launch of Radeon HD 6000 series, while Nvidia drops GPU price Monica Chen, Taipei; Joseph Tsai, DIGITIMES [Tuesday 28 September 2010] より。

AMDは次世代GPUであるRadeon HD6000シリーズ(Southern Islands)のローンチスケジュールを当初の2010年10月12日から11月に延期したとの情報がグラフィクスカード市場から伝えられた。

複数のニュースソースは、このチャンスを捉えてnVidiaは新しいエントリー向けGPUを10月に既存のGPU価格より切り下げてローンチし市場シェアを取り戻す意向である。

AMDとnVidiaの双方は自身のGPU製品のローンチスケジュールについてコメントを拒否している。

TSMCがGPU向け32nmプロセスのR&Dをスキップし、直接28nmプロセスのR&Dを行うため、AMDは自身の計画を修正し新しいRadeon HD6000シリーズを40nmに合わせて継続することを決定した。だがそのため新GPUの構造とプロセスは既存のHD5000シリーズに近いと市場関係者は新製品は少し保守的な製品になると語っている。

その反応に対し、nVidiaは新しいエントリー向けGPUであるGeforce GT430を10月にローンチする計画であり、Geforce GT220およびGTX460 768MBグラフィクスカードの価格を切り下げることにした。

—-
nVidiaは誰得なGPUカードの価格を下げるんだなw

更新2010年10月2日

dititimesから記事が。2010年10月19日台湾で開催されるAMD’s Technical Forum and Exhibition 2010 でRadeon HD6000シリーズが公開されるとのこと。ここの記事はなんか玉石の差が大きすぎるな。

うわさ AMDの次世代GPU Radeon HD6700とHD6800のスペック表がリーク – 予想以上の性能向上を実現?

vr-zone.com UPDATED: [Rumour] AMD Radeon HD 6700 Specification Chart leaked Published on Monday, September 27 2010 1:19 am by Sub より。

噂 AMD RadeonHD6700のスペック表がリーク

PCinlifeフォーラムメンバーがRadeon HD5700シリーズと比較する目的のため登場予定のHD6700/HD6800のスペック表をリークした。最新のリーク情報はHD5700シリーズから激しくアップグレードされることを伺わせており、コードネーム「Barts XT」HD6770の特徴は320個の4VLIWシェーダクラスタで1280ストリームプロセッサ(SP)となる。特徴はHD5870と同じく256bitメモリインターフェース及び32レンダーアウトプットパイプライン(ROP)が特徴で、逆にTMUは80から46に減っている。コアクロックはとてつもなく高い900MHzで、これまでのディスクリートGPUで最も速いクロックスピードとなる。メモリクロックとメモリ帯域はHD5870に比べ下げられており、134.4GB/secとなる。「Barts Pro」HD6750は280シェーダクラスタ、もしくは1120SPで56TMUでクロックスピードはより下げられて750MHzであるが、メモリスピードは1GHzからたった50MHzしか下げられていない。ついでにクロックスピードはHD5850と同じである。

この表はまた「Barts」コアのSIMD構造についての詳細を暴露している。「Evergreen」シリーズのSIMDは16個の5VLIWシェーダクラスタで5シェーダが接続されており、トータルで80SPであった。それぞれのSIMDはまた4TMUにつながれていた。最上位製品である「Cypress XT」HD5870はまた20SIMD、320クラスタで1600SPおよび80TMUであった。最初のメジャーな変更点は、既に広く知られているが、それぞれのシェーダクラスタ構造である。いまや4シェーダしかない。だけれども、それぞれのクラスタは現在より効率的になっており、少ないダイサイズ中の面積にこれまでと同じかより向上した性能を実現する。それぞれのSIMDユニット数は現在奇妙にも20個の4VLIWクラスタからなる(通常ならば8・16・32…という数字が予想される)SIMDユニットあたりのトータルシェーダ数は同じ80異なるが、彼らは異なる改良を行なっており、故に「Barts XT」は64TMUを特徴としている。もしこれらのスペック表が本物だとしたら、HD6770は確実にHD5850の息の根を止める結果となり、最近の噂のとおり、性能はHD5870に非常に近くなる。これだけの効果のあるシェーダークラスターに感謝し、これらの性能全てが現在の「Cypress」より同じ40nmプロセスでの製造にかかわらず低消費電力でかつ小さなダイサイズで達成されることになる。これらの噂が本当か否かにかかわらず「マイナーな改善」という噂からとてつもなく大きな性能向上である。

もちろん、これらのリーク情報が非常に大きな塩の塊であるということを覚えていく事に価値はある。前の噂では960SP及び1120SPであるという内容であった。現在私たちはまた1280SPというリーク情報を受け取っている。明らかなのはこれらの全てが真実であるということは無く、もしくは全て嘘であるかもしれない。だがもしこれらのスペック表が偽物でも、よくできた噂であり口にするには丁度良い噂ではある。

参照元 PCinlife

更新

ChiphellのNapoleonにより、同じ表のフルバージョンがリークされた。二つの表は異なる情報元からでているが酷似しており、先程の情報源に比べこの表は確実性が非常に高い。フルバージョンの表では更に消費電力について詳細が記載されている。HD6770の消費電力はHD5700より上でHD5850より下であり、ほとんどのGPUを軽くけちらすだろう。HD6770は146W TDPであり、HD6750は丁度良い116Wである。アイドル時の消費電力はそれぞれ23Wと20Wである。このことはHD6770の消費電力は150W以下であり、二つのPCI Express電源コネクタであると考えるのが妥当であり、HD6750は一つだけであると簡単に推測できる。

nVidia CEOがFermi出荷遅延について問題点を率直に語る

hexus.net NVIDIA explains initial Fermi delays より。

nVidiaのJen-Hsun Huangが最新GPUの出荷の遅れを引き起した原因について驚くほど率直なインタビューでいくつか説明してくれた。

インタビューと動画撮影をしたジャーナリストはGolem.deである。huangは、会社は設計図は現実に可能であることと必ずしも調和しないということを気付かされたと説明した。Fermiアーキテクチャの製造で生じた問題は、それそれが相互接続インターフェース群を経由して接続されている複数のストリーミングプロセッサ(SM)クラスタが壊れてしまったことである。

Huangはこれらの相互接続インターフェース群は密度が高くきつく束ねられた織物の繊維のようであると説明した。設計上では、相互接続インターフェースはそれぞれの演算コアとチップのそれ以外の部分とが非常に高速に通信できるようにされていた。だが実際には計画とは全く異なった。

最初のサンプルがTSMCから受け取ったとき、全てのSM群は正常に動作しているように見えたが、他のSMとの通信が全くできなかった。一見したところ相互接続インターフェースは、信号がそれぞれ干渉しあい、完全に通信ができなかった。それはチップ内で情報を伝えることができない交通渋滞のようなものである。

Huangはそれを「設計とツール及び現実との間が完全に壊れてしまった状態」と語った。その問題は製造エンジニアと設計エンジニアがそれぞれ別の部門に所属していたために発生した。その問題自身は解決はそんなに難しいわけではないが、経営管理者によって問題に対する解決の指示を部門に割り当てなかった為、その問題は中に浮いたままになってしまった。結果として動作しないチップを再設計しなおす必要になり、最初のFermiアーキテクチャグラフィクスカードのローンチ遅延を引き起した。

これは単純な懺悔だが、特に経営層にとって会社が間違いを広く認めているように見えることは元気づけられる。そしてそれらの問題から前進することを学ぶことを願うばかりである。

—-

えっと、製造プロセスと設計に問題があって、組織上の問題が重なって製品が遅延したということか?
その間AMDはTSMCで改善に取り組んでいたわけだし、同じ製造会社で問題を回避しHD5000シリーズは大ヒットしたんだよな。
…問題は経営者か。

うわさ AMD Radeon HD6870が2010年11月に登場 – チップ製造は非常に良好 SemiAccurate Charile Demerjian氏記事

AMD’s 6870 coming in November Early silicon doing very well by Charlie Demerjian September 24, 2010 より。

AMDのHD6870は11月にやってくる

初期シリコン製造は非常にうまくいっている
Charlie Demerjian
2010年9月24日

ATIが、おっとすまないAMDは、HD6870をうまく軌道に乗せているようである。早くもAMD中央からは二つの大きな情報が手に入った。

私たちは既にATIの、またすまないAMDの最初のシリーズである「Northern Islands」ファミリーの「Barts」が既にテープアウトしたことを伝えた。「Barts」はミドルレンジでNvidia GF104/GTX460に正面から対抗するために作られており、それはHD6770と呼ばれている。それはまもなく出荷準備をしており、強豪相手を消し去る予定である。

「Barts」の兄である「Cayman」は「Barts」の1ヶ月以内にテープアウトし、それは「Barts」から1ヶ月後に通りを埋め尽くすと予想している。これは11月の中旬から下旬にかけてHD6870として店に並ぶだろう。SemiAccurateのソースは私たちにそれが正確に起きることを話している。

OEMへの発送は「Barts」HD6770が通りを埋め尽くす時期に出荷開始される予定である。これは2週間〜4週間後のブラックフライデー(感謝祭翌日)に合わせるだろう。ブラックフライデー以前の噂は適切でなく、このカードは本当に出荷され、nVidiaが2009年にFermiを本物としてモックアップを掲げたときとは違う

この出来事ののもう一つの側面は、前回と異なり最後が870の数値以外のカードが今回は非常に大量に供給されているということである。それは既に需要に応じて初期の在庫不足が生じた時から、周辺のウエハース供給が非常に多く、頂点に達し歩留まりも非常によく、最初の工場からでたシリコンウエハースはHD5870/Cypressが同じラインで製造されたときよりも遥かに歩留まりが良くなっている。

結論として11月には「Northern Islands」カードのHD6800とHD6700の両方共非常に大量に供給されるだろう。もし需要が正常な場合、デュアル「Cayman」カードであるHD6900「Antilles」は2010年末よりも前に市場に登場するだろう。もしHD6870の需要が高すぎる場合、HD6970は適切に供給ができるようになるまで少しだけ登場が遅れるだろう。ATI、おっとまたまたすまないAMDは前回の件からそれについて強く学んでいる。

暇なのなら、2010年残りの時期はGPUのスタートポイントとして非常に興奮するだろう。そして2011年初旬もいい感じだろう。もしあなたがnVidiaの株式を保有しているのなら、あまり楽しめないだろうが。

Linux上でネイティブなDirectX 10/11の実装が実現 – Gallium3DによりオープンソースでGPUドライバ実装が可能に

phoronix.com Direct3D 10/11 Is Now Natively Implemented On Linux! Published on September 21, 2010 Written by Michael Larabel より。

概要として、

Luca BarbieriとMesa / Gallium3D開発者がオープンソースのグラフィクスドライバでMicrosoftのDirectX10と11のAPIをLinuxに搭載することに成功し、既に動作しておりWineに統合中とのこと。

Luca Barbieriは「D3D1x」と呼ばれているDirect3D 10/11 COM APIをGallium3Dに追加した。
Lucaはこれは単なる初期バージョンであるとしているが、既に動作しいくつかのDirectX10/11のテクスチャデモがLinux上で動作させることが可能。
これは現在のWine実装のようにDirect3DをOpenGLへ変換したりせず、ネイティブにGallium3DとTGSIに直接グラフィクスドライバ及びハードウエアとやりとりが可能である。
Gallium3Dの設計に感謝し、Direct3Dのサポートが基本的にLinuxドライバにほんの少しかほとんど変更無しで「フリー」で可能となる。

freedesktop.orgのコミットを読むと、「最初のゴールは複数のAPIサポートというGalliumの約束を現実にすることであり、Galliumの上に非常に薄い簡単な実装により動作を可能にすることを提供し、たくさんの巨大な絡みあったプログラムコードの必要なOpenGLの代わりになる。2番目のゴールはWineを使いLinux上でWindowsのDirect3D 10/11仕様のゲームを動作させることである。」

Wineもこの活躍に感謝を示し、DLLのいらないWineへの組み込みは行われいているが、Lucaは目標達成は全く持って簡単であると語った。

もしこの出来事がより良くできなければ、「FglrxとnvidiaドライバはOpenGLを使えるようなGalliumドライバを開発することでサポートが可能となり、それは比較的簡単な作業である。Direct3D 10/11の偉大な設計とGalliumとの近密性に感謝し、このアプローチが体感できるようなオーバーヘッド無しで結果を得られ、FglrxやnvidiaのプロプライエタリドライバからGalliumのオープンソースドライバに切り替えるパッチを提供するだけででほとんどメンテナンス可能になる。

特にDirectX10.0の限定サポートやDirectX11.0の未サポート状態のWineにとってこのニュースは信じられないようなものである。

現在の他のゴールについて、「3番目のゴールはWindowsシステム以外で動作するOpenGLを代替する高品質なグラフィクスプログラムの実現を可能にし、特にLinuxやその他フリーやオープンソースシステムにもたらされる。一から開発されたこの非常に簡潔で練られたコードに感謝し、Direct3D 10/11はOpenGLに比べ極めて良いAPIであり、極端なまでに少ないコードと開発時間でサポートすることが可能となり、あなたは現在存在するMesa OpenGL実装のプログラムソースと比較することも可能である。」

Linux上で標準でDirect3D 10/11が実装されたことについていくつか考えさせられるのは、「最後に、成熟したDirect3D 10/11実装はOpenGL実装に比べ本質的により高速でより高信頼であり、劇的に小さなAPIはアプリケーションを開発する目的のために必要な開発により多くの時間を割くことが可能になる。」

VMwareは以前Direct3Dの実装をし、それはオープンソースでもなく、Windows上でのGallium3D実装でDirectX9をターゲットにしたものであったが、それとは全く異なり、コミュニティメンバー達により開発されたオープンソースであるということである。

Gallium3Dの成果はMesa開発者たちにも可能なマイルストーンを準備した。
幸運にもまもなく私たちはOpenGL 3.x/4.0が実装されるのを遂に実現できるだろう。Linux上でのDirect3D 10/11実装の実現には26,000行の追加がMesaに必要であった。
私はMicroosftがDirect3DをLinux上で実装するのに彼らに何故ビール(※beerとwine。ソース元のページには開発者がビールで祝っている画像がある)を買ってやったのか不思議でたまらない。

※コミット内容

  • Independently created headers for Direct3D 10, 10.1, 11 and DXGI 1.1, partially based on the existing Wine headers for D3D10 and DXGI 1.0
  • A parser for Direct3D 10/11 DXBC and TokenizedProgramFormat (TPF)
  • A shader translator from TokenizedProgramFormat to TGSI
  • Implementation of the Direct3D 11 core interfaces
  • Automatically generated implementation of Direct3D 10 and 10.1
  • Implementation of DXGI using the “native” framework of the EGL st
  • Demos, usable either on Windows or on this implementation
    • d3d11tri, a clone of tri
    • d3d11tex, a (multi)texturing demo
    • d3d11gears, an improved version of glxgears
    • d3d11spikysphere, a D3D11 tessellation demo (currently Windows-only)
  • A downloader for the Microsoft HLSL compiler, needed to recompile the shaders (compiled shader bytecode is also included)

なお、x86_32でのみテストしたとのこと。

—-

すごい事になったな。OpenGLを介さずに実現するとは。

nVidiaの次世代GPU「Kepler」は2011年第2四半期に登場予定

vr-zone.com NVIDIA next-gen is “Kepler”, 28nm in H2 2011 Published on Wednesday, September 22 2010 5:17 am by Sub より。

nVidiaの次世代GPU「Kepler」は2011年第2四半期に登場予定

GTC2010開催中に、nVidiaは現在呼ばれている次世代GPUアーキテクチャ名「Kepler」を公開した。nVIdiaは未だに「Fermi」シリーズの最後のチップである「GF108」を2010年10月にGeforce GT400リリースして製品ラインナップを補間するのに忙しい。次の大きなステップはたった2011年第2四半期に「Kepler」と共に進むという。

「Kelper」はワットあたりの倍精度性能を「Fermi」の2倍〜3倍の向上を目指している。不運にもGTCは伝統的にゲームよりもコンピューティングに重きを置くが、倍精度演算はゲームにとっては少なくとも現時点ではあまり重要ではない。ゲームに関連する様々な大きな革新は将来開示されると考えることが適切だろう。「Kepler」と共にやってくる「Maxwell」は、相当なワットあたりの倍精度演算性能の改善を約束しているが、nVidiaの科学者の名前をアーキテクチャ名にする流れは2013年および22nmまで続くだろう。

2011年第2四半期の「Kepler」および2013年の「Maxwell」のスケジュールが公開されている間、nVidiaもTSMCも目標日程に合わせるために必要な工程全てに成功しているわけではなく、我々はこれらの日程を割り引いて捉えるだろう。特にかつて「Fermi」が同じスライドに2009年の日程が書かれており、実際には一番早く「Fermi」カードが登場したときは2010年4月しか可能ではなかったことを考えると現実には目標日程は割り引いておくことが妥当であろう。たとえそうでも、2011年第2四半期はかなり遅い時期であり、私たちはAMD HD6000世代との戦いの前に幾らかの蓄えを持っておくことを願うばかりである。

参照元:Fudzilla

—-

ちなみに「Kepler」(ヨハネス・ケプラー)は、17世紀現在のチェコ共和国にてプラハでティコ・ブラーエの膨大な天体観測結果から、コペルニクスの地動説の問題を解決し惑星運動の3大法則を発見した偉人。
「Maxwell」(ジェームズ・クラーク・マックスウェル)はアンペール・マックスウェルの法則(変位電流と磁場の関係)およびマックスウェル方程式で電気と磁気を統一する電磁気学を創設した偉人。
さてnVidiaはこれらの偉人の名前を傷をつけない製品を開発できるのか?

AMDの次世代GPUの「Barts」のメモリコントローラについて妄想してみる

semiaccurate.com Northern Islands Barts benefits to moar, bigger? by Stephen Werner September 20, 2010 より。

概要は下記の通り。

  • AMD Radeon HD6770について非常に期待されているが、いったいどのくらいの価格帯なのか?
  • Radeon HD6770もしくは「Barts」は256bitメモリインターフェースと噂されているが従来のRadeonの価格帯では128bitが通例だった。
  • 製造コストを上げてまでAMDは256bitを採用するのか、HD5770「Juniper」の2倍の帯域が必要なのか見ていこう。
  • まずはRadeon HD5770のGPU動作周波数とメモリ周波数を調整する。Crysisと3DMark Vantageの数値から見ていく。実際にはDDR5のECCによる帯域への影響が結果として出るかもしれない。
  • メモリクロックをテストが失敗しない数値まで増加させた。結果数値は動かない。ベンチマークを他の日にもう一度動かしても数値は動かないので結果には自信がある。

Vantageは8.3%のメモリクロックまでで不具合を起こした。 **全体の合計より大きい点に注意

  • これらのテストではAMD PhenomII X4 3.2GHz、4GBメモリ、Windows7 64bitを使い、CPUのボトルネックが発生していないことを似たようなベンチマークを使って確認している。
  • 結果GPUのオーバークロックはメモリのオーバークロックより効果的であり、DDR5のECCによる帯域への結果は出ていない。結果として合計で35%の性能向上ができた。
  • 興味深い点はCrysisのスコアである。GPUとメモリのオーバークロックは個別にオーバークロックしたときの合計よりも性能向上につながる。
  • この結果からHD5770はバランスの良い製品であるという明快な結果が出た。

他のGPUでも試す。

  • HD4890は二つのチップを載せているが、DirectX11対応ではない。もちろんメモリコントローラも既に古い。
  • 理論的にはHD5770とHD4890の間にはメモリ帯域により20%の性能差がある。
  • HD4890をだしたのはメモリコントローラの違いを測定するためではなく、メモリ帯域がHD5770の76.8GB/secに対して124.8GB/secと67%大きい点で比べた。
  • 注意して表の数値を比べてみて欲しい。二つのGPUボードには20%の性能差がある。

  • 興味深い点はHD4890のメモリ帯域により性能が100%拡大しているわけではないところである。それでも30%〜40%の性能向上は見られるのだが、HD4890はHD4870よりメモリは遅い。
  • HD4870はHD5770より50%もメモリ帯域が大きいが、これ以上速いメモリが必要ではない。よってメモリを速くしても少ししか性能は上昇しない。
  • 更にnVidia Geforce 9600GTと9800GTで比較する。両方とも256bitメモリコントローラである。スペックか下記のとおり。

  • 9800GTは9600GTにほとんどの点で優っており、9800GTのテクセルフィルレートや浮動小数点演算能力は9600GTに比べ62%も上である。
  • メモリフィルレートは9800GTと9800GTXはほぼ同じである。
  • 一般的に9800GTは9600GTより15%性能が上であり、その結果メモリの帯域上昇による全体の性能上昇は小さいことがわかる。

メモリ帯域増加によるコスト

  • X-bit labsはRV770のメモリコントローラサイズを4,000万〜4,500万トランジスタと計算している。これはRV770の全体のトランジスタ数の5%未満である。
  • RV770とJuniperは似ている点があり、メモリ帯域が増加することによりトランジスタ数が増加していない点である。
  • この意味はJuniperのメモリコントローラが2,200万トランジスタか全体のトランジスタ数の2%前後であることがわかる。
  • ダイサイズに何が占有しているかはわからないが、一般的なメモリコントローラのトランジスタ密度を知らなくてもある程度のトランジスタ数を見積もることができる。
  • ポイントとして、「メモリコントローラーは128bitと256bitでダイサイズの影響は殆ど無い」ということである。
  • ダイサイズのコストはその大きさが小さくなると歩留まりが少しだけ上がる。もしPCB基板のコストが1層あたり10ドル上がるとした場合、コストの大半はPCB基板が占めるだろう。
  • 9800GTと9600GTを比較することにより、シェーダ数とテクスチャユニット数が性能向上に有効な点がわかる。メモリコントローラを2倍にしてもダイサイズ上では2%〜10%の間に留まるだろう。
  • シェーダ数とテクスチャユニット数の増加は性能向上もあるがダイサイズを大きくしてしまう。だがほとんどのコストを占めるPCB基板のコスト上昇は抑えられる。
  • 数多くの選択肢からどの道を行くのかを決めており、AMDとnVidiaは自身のパートナーの粗利を壊すことなく自身の粗利を確保しているだろう。
  • 歩留まりは予測され決定される必要があり、適切なコストは目標としている性能カテゴリの主要な要素であり、バランスが必要である。

「Barts」は256bitメモリコントローラか否か

  • 「Barts」の競合製品が何であるか思い出すことは非常に重要だ。それはnVidia Geforce 460GTXで、「256bitメモリコントローラ」を持っている。
  • AMDがそのような製品に128bitメモリコントローラを採用した製品で競争することは無いだろう。
  • 「Cayman」シリーズのDDR5メモリコントローラが「Barts」の1,600MHz(x4)であり、25%しかメモリ帯域が大きくない点がそれを示している。
  • もし40%以上のメモリ帯域を上乗せしても全体の性能は10%未満であろう。
  • 256bitメモリコントローラは確かに20%の性能向上をもたらす。
  • ただ確かな点は「Barts」は他のアーキテクチャ改善を行っているだろう。より多くのメモリ帯域は性能向上を提供するが、GPUとメモリクロックを一緒に上昇させたときの素晴らしい性能向上を思い出して欲しい。

最後に誰もが新しいアーキテクチャはダイサイズが小さくなるとメモリ帯域の制限により性能が制限されてしまうだろうと思うが、より大きなメモリコントローラは「Barts」シリーズに性能改善の多大なる貢献をするだろう。

AMDは同意しているかって?あと数週間でわかるよ。

—-

とりあえずスケジュールがHD5000シリーズ時より1ヶ月遅れているようなので2010年10月頃発表・月末販売開始か?