AMDが新しいLinux向けグラフィックドライバを開発中 42
ストーリー by hylom
新しいバイナリblobとなる可能性も 部門より
新しいバイナリblobとなる可能性も 部門より
insiderman 曰く、
AMDは同社のGPUをLinuxで利用するためのドライバを公開しており、その一部はオープンソース化もされている。ただし、オープンソース版のドライバは非オープンソース版ドライバと比べて機能が劣っているという問題があり、また非オープンソース版のドライバは利用時にビルドが必要でその手間があった。こういった状況を踏まえ、AMDは新しいLinux向けドライバの開発に着手しているという（slashdot、元ネタのPhoronix）。
背景には、Valveが開発するLinuxベースのゲーム向けOS「Steam OS」や、それを搭載するハード「Steam Machines」など、Linuxベースのゲーム環境が登場していることがあるようだ。
新しいLinuxドライバでは、ドライバの一部機能をユーザースペースで実行させ、カーネルスペースで実行させるコードについてはオープンソース化してLinuxカーネルの開発ラインへの投入を目指すという。これにより、カーネルのバージョンをアップデートした場合でもカーネルモジュールのリビルドが不要になるという。
また、カーネルスペースのコードが公開されることで、オープンソース版ドライバの開発がしやすくなるというメリットもあるという。ただし、このような構造が実際に実現可能なのか、またLinux開発者側がこのようなドライバを受け入れるのか分からない、という問題もある。
素直じゃないなぁ (スコア:1)
AMDのE-450を使ったノートPCをUbuntu13.10で使っていますが、AMDの謹製ドライバだとYoutubeもカクつきます。それと、Cinnamonが正常に起動しなかったり。
また、カーネルスペースのコードが公開されることで、オープンソース版ドライバの開発がしやすくなるというメリットもあるという。
それなら素直にOSSなドライバの開発に協力すればいいのに……。ツンデレなんですねわかります。
640GBはすべての人にとって未来永劫充分なメモリだ。
Re:素直じゃないなぁ (スコア:2, 参考になる)
そういえば、Kernel OOPSの原因の第一位は、AMD純正ドライバのCatalyst (fglrx)ですねぇ。
http://www.kerneloops.org/ [kerneloops.org]
これで、OOPSが減ってくれればありがたい。
Re: (スコア:0)
○：AMD純正、AMD製
×：AMD謹製
他者にへりくだらせてどうすんの？
Re: (スコア:0)
他者のものに「謹製」を付けて皮肉とする、慣用的な使い方だと思いますが…。
AMDはゲーム機と関わったせいで家ゴミ脳を発症した (スコア:0)
合理性よりも客への嫌がらせを優先する。脳が壊れた人にありがちな行動です。
Re: (スコア:0)
すごい説得力だ…
だってdkmsあるから、リビルド必須でも不便じゃないよな (スコア:1)
カーネルモジュールのリビルドは、大昔は手作業で、面倒なものでしたね。
でも、それはけっこう昔のことで、たとえばUbuntuでは
リポジトリーからNVIDIA製ドライバーを選んで導入を行わせれば
自動的にダウンロード,展開,リビルド,インストール,アップデートが可能ですし
アップデート時にはdkmsによって、自動的にリビルドも行われます。
もちろん、それにはそれなりの時間がかかりますが
GPUに力を入れるようなPCは、CPU性能もそれなりにあるので
これにかかる時間は、それほど大きな時間ではありません。
ですから、dkms+NVIDIA製ドライバーは充分に簡単で良い仕事をしてくれます。
AMDがそれを上回る人気を得るためには、まず安定と性能で
新機軸を盛り込んできたことが、大きな利点と受け入れられる可能性は低いんじゃないかと思います。
Re: (スコア:0)
ゲームはオープンソースじゃないのに… (スコア:1)
高速なグラフィックドライバの主な使用方法がゲームだけど、そのゲームはほとんどオープンソースじゃない。
(開発費が掛かってるから公開なんか出来ない)
なのにドライバだけオープンにしろってのも変な話だ。
ソース公開したら非互換な実装だらけで収集がつかなくなる事必至だ。バイナリが1つだけあればいい。
実際Firefoxとか複雑なものになると、公式ビルドは想定通り動くのに
Fedoraがビルドしたものだと動かないことが結構あった。
Re: (スコア:0)
linusは動かないデバイスが嫌いだ。サポートするのに手間がかかるクローズなドライバーはもっと嫌い。
オープンソースのドライバならカーネルのメインラインに取り込まれるバージョンしか使われないから、互換性に問題は起きない。
AMD F*CK (スコア:0)
いや、どう考えてもLinus激おこフラグでしかないだろ……。
ドライバにどんな秘密が？ (スコア:0)
なぜクローズドにこだわるんでしょうか。
バイナリにしたところでチップとのインターフェイスに関するノウハウは容易に解析されてしまうわけで、そこまでしてソースを非開示にしたい理由がよくわかりません。
GPU市場も先行き明るいとはいえませんし、Linuxユーザーを顧客として認識したのなら、多少は流儀に合わせてもよさそうなものですが。
Re:ドライバにどんな秘密が？ (スコア:5, 参考になる)
GPUは知財の塊ですよ。クロスライセンス等の大人の事情もあるので、そう簡単には仕様は公開できません。
> バイナリにしたところでチップとのインターフェイスに関するノウハウは容易に解析されてしまうわけ
本当ですか？
実際に nVidia のGPUを解析しているプロジェクトとしてはnouveau があります。
彼らは、５年以上、解析を続けていますが、
- GPGPUな部分（Tesselation、OpenCL関連）
- 動画の再生支援
などは未だに解析も実装も終わっていません。
特に、新しい世代のGPUについては作業が遅れてて
機能限定版のドライバを現在コーディング中、というレベルです。
http://nouveau.freedesktop.org/wiki/ [freedesktop.org]
http://nouveau.freedesktop.org/wiki/FeatureMatrix/ [freedesktop.org]
彼らの活動をみるだけでも、解析はかなり難しいように思えます。
容易に解析できるスキルがあるなら、是非 nouveau プロジェクトに貢献していただきたいものです。
Re:ドライバにどんな秘密が？ (スコア:2, すばらしい洞察)
オープンにして当たり前だと思ってる奴は頭がどうかしていると常々思ってる。
Re:ドライバにどんな秘密が？ (スコア:1)
そういう輩はオープンにしたら [srad.jp]したで文句 [srad.jp]をつける [srad.jp]わけで。なんだかなぁ。
Re: (スコア:0)
当たり前だとは思ってないけど
Linuxでトラブルが多発するハードは使いたくないと思ってる。
対岸の火事だと思ってたらWindowsでも再現するなんてよくある話だし。
Re: (スコア:0)
使わなければいいし黙ってればいいんじゃね？
Re: (スコア:0)
隠す意味がないから → 公開すればいいのに
作る側として、この飛躍ぶりにはいつも違和感を覚えます。
Re: (スコア:0)
クローズドソースのドライバーを サポートするのがタダだと思っているのか、
Re:ドライバにどんな秘密が？ (スコア:1)
パテントトロールが怖いんじゃないの。
Re:ドライバにどんな秘密が？ (スコア:1)
なぜクローズドにこだわるんでしょうか。
私もそう思うほうです。素人なので分からないからなのでしょうけど。。
デバイスドライバは、ふつーに考えると(1)-(4)を、そのGPUに合わせて記述したプログラムです。
(1)仮想メモリマップA0000000-B0000000まで予約
(2)GPUにメモリマップをくくりつけ
(3)画像をメモリマップに書き込み
(4)描画しろっ(GPUに命令)
(1)-(4)みても、GPUの中身は分からないような気がするのですが、、
仮想メモリマップの画像をどのように映像として表示するのか、
GPU内部で行われていることを(1)-(4)で分かるとは思えないのですが。
>GPUは知財の塊ですよ。
GPUの「中身」はそりゃ知財の塊で、意味不明でしょうけど。デバイスドライバはOSとの橋渡しをするだけで
GPUの中身は見ないはずなのですが。インターフェースもGPU購入者に隠すほどの知的所有権なのでしょうかね。
ということで、なぜ(1)-(4)のプログラム(デバイスドライバ)が秘密なのか、いまいち分からないと思うのです。
「いろいろ面倒だから」公開しないというのなら分かるのですが。
例えばチップのリビジョンごとに書き込みタイミングをμsあたりで微調整しているデバイスドライバのソースとか
メンテしたくありませんしね。。
Re:ドライバにどんな秘密が？ (スコア:2)
> デバイスドライバは、ふつーに考えると(1)-(4)を、そのGPUに合わせて記述したプログラムです。
http://www.x.org/wiki/RadeonFeature/ [x.org]
http://www.x.org/wiki/radeonhd:feature/ [x.org]
OSS版のドライバの仕様と機能サポートの状況です。(1)～(4)だけのシロモノではありませんね。
Re: (スコア:0)
デバイスドライバの出来で描画性能が左右されるんなら「橋渡しをするだけ」ではないということなんでは？
Re: (スコア:0)
Re: (スコア:0)
恥ずかしいから。
Re: (スコア:0)
難読化と言い張れば大丈夫さー。
Re: (スコア:0)
ベンチマーク最適化はやってそう
ベンチマーク最適化どころかタイトル毎にチューニングしてる (スコア:1)
ドライバのバージョンアップがある度に「○○が30％高速化」という項目がずらずら並んでる。
NVIDIAもゲーム毎にチューニングしてる事を売りにしてるし、ベンチマーク最適化も当然
ケチが付かない程度にやってるだろう。
Re: (スコア:0)
異方性フィルタの手抜き処理論争とか懐かしいですね
Re: (スコア:0)
NVIDIAとか他のGPUメーカーにノウハウを盗まれたくないからでは？
Re: (スコア:0)
公開した場合のリスクとリターンの予測がつかないからでは？
色々な予想は出来ても、根拠あるものを出せなければワンマンでもないかぎりどーしようもないでしょうしね。
Re: (スコア:0)
だったら高速なドライバ書いて公開してください。
何だったら実装に必要な分解析した結果でもいいです。容易なんでしょ?
Re: (スコア:0)
どうせ利用者の大半はソースなんか眺めずビルド後のバイナリしか利用しない人たちだらけなのに。
ドライバの提供を受けたいなら、多少は流儀に合わせてもよさそうなものですが。
Re: (スコア:0)
「私らはオープンにするけど、他社の権利に引っかかる部分は無理よ」
というアナウンスを以前していた気がしますが。
素で質問 (スコア:0)
PC UNIXから離れて10年くらい経つので最近の状況は全く知らないのですが，
>> また非オープンソース版のドライバは利用時にビルドが必要でその手間があった。
「非オープンソース」ってことはソースが公開されていないという意味ですよね？それを「ビルド」ってどういう意味なんでしょうか？
Re:素で質問 (スコア:1)
「非オープンソース」でかつソースが公開されているってのもいっぱいあります。
オープンソースの定義をどうぞ。 http://www.opensource.jp/osd/osd-japanese.html [opensource.jp]
Re:素で質問 (スコア:1)
ドライバをバイナリで配布してるベンダーでもLinuxカーネルのIFって結構頻繁に変わるから、
ドライバのカーネルと直接やり取りするところだけソースの形式で配布してるのよ。
でドライバを動かす環境でそこだけビルドすることによって実行環境のカーネルのバージョンの影響をあまりうけないようにしてる。
Re: (スコア:0)
それだけなら別にベンダがビルドして配布してもいいでしょ。問題は技術的な所じゃなくてLinuxのカーネルモジュールのライセンス。
Re: (スコア:0)
ディストリビューション毎にベースのカーネルバージョンが異なるうえにディストリビュータの都合で頻繁にアップデートされること考えたら、ベンダが都度ビルドして配布するって技術的に現実的じゃなくね。
あと、誰がビルドしようが最終的にロードしたらTaintedになる、ってだけな気がすんだけど。
nvidia (スコア:0)
のウンコより対応が100倍マシ。
Android 用 TV Stick (スコア:0)
Mali 400 のドライバも公開されたら、
Android TV スティックで、Linux + GUI がバリバリ使えるようになるので、とても嬉しい