by
Anonymous Coward
on 2015年07月10日 11時01分
(#2845299)
元コメの疑問への回答としては、引用されているページのここですかね。
Since internal Linux kernel interfaces and data structures may be changed at any time, DRI kernel modules must be specially compiled for a particular kernel version. （Linuxカーネルの内部インターフェイスとデータ構造は随時変更されるため、DRIカーネルモジュールは特定のカーネルバージョン専用にコンパイルされなければならない。）
GPUドライバがカーネルの一部なの？ (スコア:0)
よくわかってないんだけど、たかが1ベンダのドライバがカーネルの一部としてリリースされるの？
とすると、Linuxのカーネルには主要なGPUに対するドライバが全部含まれてて、
新しいベンダからGPU製品がリリースされたら、カーネルを変更しないと使えないの？
よくいうLinuxはmonolithic構造だから、っていう話かな。
Re:GPUドライバがカーネルの一部なの？ (スコア:4, 参考になる)
既に、述べられてる点 [linux.srad.jp]を除いて細かいところを書いておきますね。
基本的には、x86系で主に使われるGPUメーカで、IntelとAMDは積極的にオープンソースに対して協力的ですし、ARM SoCの幾つかのメーカも協力的ですが、nVidiaは余り協力的ではないということがあります。
AMDは最近GPU関連に力を入れていて、例えば「次世代OpenGL」のクロスプラットフォームAPIとして規格化されたVulkan [impress.co.jp]の基になったMantle [4gamer.net]を開発・実装していたり、GPUで色々計算をやらせるための規格であるOpenCL [wikipedia.org]に力を入れています。
で、最近、AMDがGPU周りの資源共有に対して、他の会社に先行して大きな変更を入れていて、AMDKFD [phoronix.com]と言うドライバを投入してきました。
これはいつも使われてるOpenGLやGLの一機能で大きな役割を担ってるGLSL、更にはOpenCLやVulkanを滞りなく並行して使えるようにする目的の物で、今のところ対応してるのは主に新しいAPUやGPUに限られているようですが、最終的には全ての（AMD製）GPUでこれを噛ませるようにしていこうとしてるっぽいです。
こんな事があって、最近のAMD製のGPUに関するドライバは相当な勢いで毎回変更されてマージされてる状況です。これがある程度落ち着いて機能の有効性が確立したら、今度はIntelやARM SoCに統合されてるGPUでの対応作業が追随していくのではないかと思います。nVidiaはわからないですが(^_^;
Re: (スコア:0)
SteamOSでValveと協力してOpenGLにも力入れるぜ！って宣言 [nvidia.com]はしてましたけどね。
Re:GPUドライバがカーネルの一部なの？ (スコア:2)
ああ、言葉が足りなかったけど、オープンソースドライバの話です。
nVidiaの場合は、お世辞にもオープンソースドライバのサポートがいいとは言い難くて、AMDやIntelと較べて対応がかなり遅れてます [freedesktop.org]。
と言うのも、オープンソースのnVidia GPU向けドライバというのは、元々はクローズドソースなドライバしか出してこないのに憤慨した人がリバースエンジニアリングを重ねてリリースしていたという経緯も関係してるのか、nVidiaの技術的サポート自体が歴史的に手薄で、Linusが公の場で強い不快感を示して [gihyo.jp]やっと、メーカ側のサポートが本格的に入った？と言う感じなんですよ。
他社と較べて数年は遅れてる。
nVidiaだけではなく、AMDもクローズドソースなドライバを出してますが、これはOpenGL4.2やOpenCL2.0のような、最先端の技術や規格をサポートしてる代わりに安定しない場合が多いという物で、ここで安定した技術（の一部）をオープンソースに持ち込んでるような感じなんですよね。
nVidiaの場合は、安定性と性能、両方共クローズドソースでないと満足できない状態がまだまだ続いてる感じがしますけどね。
だから、ここで「OpenGLにも力を入れる」というのは、あくまでクローズドソースのドライバの充実に関する話だと思いますよ。
Re:GPUドライバがカーネルの一部なの？ (スコア:1)
昔はGPU関係の処理はユーザーランドで動作するXserverに切り離されてたんですが、
カーネル内の Direct Renering Manager http://dri.freedesktop.org/wiki/DRM/ [freedesktop.org] で
提供されるように変わってきました。（理由もこのページに書いてあります）
従来のようにユーザーランドにドライバを置くこともできるにはできるんですが、
最新のGPUは、あらかた DRM を使うようになってます。
とは言うものの、タレコミにあるように単一のドライバで50万行というのが本当ならば、
そんなものをカーネル空間で動かすのは危険としかいいようがない気がします。
現行の DRM の仕様は、カーネル側で担当する仕事が多すぎるんじゃないかなあ。
ある程度はカーネル側でやった方がいいにしても、せいぜい数万行オーダーで済む範囲内に
しておいて、残りの仕事はXserverに戻したほうが良い気がします。
Re:GPUドライバがカーネルの一部なの？ (スコア:1)
元コメの疑問への回答としては、引用されているページのここですかね。
Since internal Linux kernel interfaces and data structures may be changed at any time, DRI kernel modules must be specially compiled for a particular kernel version.
（Linuxカーネルの内部インターフェイスとデータ構造は随時変更されるため、DRIカーネルモジュールは特定のカーネルバージョン専用にコンパイルされなければならない。）
monolithicとかいう高尚な次元の話じゃなかった。
Re: (スコア:0)
Re: (スコア:0)
これのおかげでLinuxデスクトップではドライバのインストール問題が極めて少ない
カーネルに全部入ってるか、なくてもディストロが一緒にコンパイルして配ってくれる
Re: (スコア:0)
はあ？じゃ、俺がGPUハードウェアを開発したとして、それを使いたい顧客はどうやってドライバを手持ちのマシンにインストールすんの？
俺が独自ディストロ作って配るか、Linuxカーネルのメインラインにマージしてもらわないといけないわけ？
Re: (スコア:0)
VMware Toolsだとこんな具合。
・メジャーディストロ向けにはコンパイル済みのドライバモジュールが用意されていて、それがインストールされる
・上記に該当しない場合はドライバモジュールをソースからコンパイルしてインストール（要カーネルソース）
では頑張ってGPU開発してくれ :-P
Re: (スコア:0)
はいけーもっど〜(D0R@EM0N風に)
まあカーネルのアップデートで画面が映らなくなったりしますが個人でGPUを作っちゃったりする暇人なら恐らく問題ないでしょう。
Re: (スコア:0)
うーん、素人考えだとコンパイル済みのドライバモジュールとやらを各ベンダーがカーネルバージョン毎に用意すればいいだけに思えるのですが、何で本家Linuxカーネル側がソースに取り込むのか訳がわからんです。
オープンソースにしたいならドライバモジュールをソース含めて公開すればいいだけでは？
Re: (スコア:0)
なぜってその方法は面倒だからさ。
補足 (スコア:0)
1.ドライバーを利用してもらえない
2.ドライバーの導入で手間がかかって敬遠される
3.ドライバーを自社サイトで配布する必要がある
4.ドライバーのバグを発見した人が、自社サイトに送ってくる
5.送られてきたパッチを精査したりマージするとか自社で管理する必要が生じる。
6.そのへんが滞ったりすると、そのハードウェア自体の評判が落ちる。
実際、Linux系OSでは、かなり長いこと
ATIの純正ドライバーに不満を抱えている人がいると思うんですよね。
PentiumM前後に、Radeon搭載ノートPCが多かったことも、逆にマイナスになっている気が…
なお、ATI(AMD),NVIDIAは純正ドライバーを公開していますが
それとは別に、カーネルツリーにはOSSのドライバーが存在しています。
intelは大半のGPUについて、OSSのドライバーを寄贈しているようです。
Re: (スコア:0)
この状況は、サードパーティ周辺機器のドライバ拡充の障害になっていると思うのですが、なんで疎結合のI/F仕様を定めないんですかね。
Re:GPUドライバがカーネルの一部なの？ (スコア:1)
>この状況は、サードパーティ周辺機器のドライバ拡充の障害になっていると思うのですが、なんで疎結合のI/F仕様を定めないんですかね。
「そんなものを要求する暇があるなら、ソースコード公開しろ」と言うのが、LinuxでありGPLでありのポリシーですから。
実際、一度ドライバのソースコードをリリースすれば、カーネルのメジャーヴァージョンが上がっても、余程作法の悪いドライバ以外は大抵はコンパイルが通るし、通らなくても数十行のパッチで問題なく動く場合がほとんどだと思いますよ。
# 勿論、商業レベルで確実に動作しますよ。と言うテスト工数を含めた保証は又、別の話。
Re: (スコア:0)
話が噛み合ってないような印象。
要求しようがしまいが、ソースコードの公開は常に要求されているわけだし、
ソースコードを公開したところで、カーネル側がそれに合わせてくれるわけでもない。
再コンパイルやパッチで、ドライバ側がカーネルに合わせなければいけないことに変わりはなく、
それなら極力手間がかからないように、疎結合のI/F仕様を定めてくれという要求は、
至極真っ当だと思うのですが。
Re: (スコア:0)
当時はDRMとか無かったけど、NT4.0で見た悪夢やRage Furyを思い出す。
変なことやってないことを祈るのみ。。
DRMがカーネル側に振られてるのは利権者の政治臭く感じるのは私だけですかね。
Re: (スコア:0)
バイナリブロブはカーネルに入れないことになっている。そこでどうしてもDRMに対応させるためにこうしたんだろ。
Re: (スコア:0)
>DRMがカーネル側に振られてるのは利権者の政治臭く感じるのは私だけですかね。
なんの利権?
Re: (スコア:0)
そもそも名前が…絶対わざとかぶらせてるだろ
Re: (スコア:0)
つまりsystemd-drmの出番というわけだな!
Re: (スコア:0)
Windowsは太古のNT4で、まさにパフォーマンスのために一度カーネルモードに移って、Vistaからやっぱ安定性がダメだということでユーザーモードに戻ってきたので、2周半くらい遅れていますね。
Re: (スコア:0)
Re: (スコア:0)
Linuxはハードウェアに合わせてカーネルを作ります
Windowsはカーネルに合わせてハードウェアを作ります
Re: (スコア:0)
オープンソースなのでドライバを公式のソースコードに突っ込んどけばカーネルの開発者がカーネルのコードを変更する際にドライバに配慮してくれるかもしれない。
ちなみにカーネルが変更されるとドライバのリビルドが必要になる問題はdkmsで解決する。