opensuse leap 42.1でVMware Playerの3Dアクセラレーションが有効にならない

by · 公開済み · 更新済み

nvidia-gfxG04.conf更新後に、ldconfigを実行する手順を追加しました。（2016/9/23）

今、opensuse linux（leap 42.1）を常用OSとして利用しているのですが、その上でVMware Workstation 12 Playerを使って、Windowsも動かしています。
しかし起動当初から、「No 3D support is available from the host.」と表示され、どうも3Dアクセラレーションが効いていないようでした。
たしかに動作がカクつく…とは思っていました。

ちょっと時間も出来たので、重い腰を上げ、いっちょ解決してみようと思い試行錯誤した記録です。

概要

システム構成

  • Intel Core i7-4790
  • 32GB RAM
  • 480GB SSD
  • Nvidia Quadro K1200
    • DP 3本使用
    • 2048×1536
    • 3840×2160
    • 2560×1600
    • Additional package repositories – openSUSE を参考にリポジトリを入れて、Nvidia公式ドライバを導入済み
  • 仮想化：VMware Workstation 12 Player
  • ホスト：opensuse linux leap 42.1
  • ゲスト：Windows 10 Professional

現象

  • ゲストOSの3Dアクセラレーションが効かない
  • VMware Player側から「No 3D support is available from the host.」とメッセージが表示される

流れ

VMware側の設定を疑う

VMwareからメッセージが表示されるので、新しめのLinux OSで動いているのもあって、VMwareが悪いのだろうと疑っていました。
表示されるメッセージでググったりすると、確かに以下のようなページがいくつもヒットします。

# opensuse関連の情報が非常に少ないのは仕方ない…

上記のページではvmxファイルやvmwareの設定ファイルに行を追加したり、パッケージをインストールしろというものです。

実際、mks.enableDX11Rendererやmks.gl.allowBlacklistedDriversパラメータをいじってみたのですが全く解決しないorz
パッケージのインストールに至っては、Ubuntuのパッケージの情報ばかりなのもありますが、opensuseに類似するパッケージが無い（正確に言うとleapには存在しない。こういうのほんと多いですleapは）。

で、半ば諦めていたのですが…

driconf

driconfというツールがあります。
上に載せたリンクの1つ目、「(ホスト OS が Ubuntu の場合) 3D アクセラレーション設定時の警告を消す – 哲朗web」というページにも紹介されていますが、3D設定を変更できるツールのようです。
これも、leapでは標準でインストールが出来ず、

このページを参考に、xorgのリポジトリを突っ込んでやるとインストールできます。
しかしdriconfを実行するも、紹介されているような

「Image Quality」タブ > 「Enable S3TC texture compression even if software support is not available」を「はい」に設定する。

がそもそも存在しません。

Enable S3TC texture compression even if software support is not available と書いてあるとおり、無理やりS3TCを有効にする設定のよう。
じゃあS3TCとはなんぞやというところですが、Wikipediaにも載っていますが、以下のページを参考にしました。

しかし、PCのグラボはQuadro K1200というミドルレンジとはいえ比較的新しい高性能なもの。
3Dアクセラレーションに対応していないはずはないのです。
なぜそんなごまかしをしなければならないのでしょう。

Nvidiaのドライバ？

そもそもホストOS側で3Dアクセラレーションが有効になっていない？
そんな考えが頭をよぎりました。
しかしopensuseは3Dアクセラレーションが無効とは思えないスムーズな動作をしています。
とはいえ、確かめて見る必要はあるでしょう。

xorgのログを見てみます。

# less /var/log/Xorg.0.log

ログの中で(EE)がエラーを示す行です。

(EE) NVIDIA(0): Failed to initialize the GLX module; please check in your X
(EE) NVIDIA(0):     log file that the GLX module has been loaded in your X
(EE) NVIDIA(0):     server, and that the module is the NVIDIA GLX module.  If
(EE) NVIDIA(0):     you continue to encounter problems, Please try
(EE) NVIDIA(0):     reinstalling the NVIDIA driver.</pre>

こんな行がありました。
どう見ても良くない系です（直感）

どうも頭によぎった考えは正しかったようです。

これを元に調べていくと、以下のようなページが見つかりました。

するとupdate-alternativesをやって、/etc/ld.so.conf.d/nvidia-gfx-G04.confが正しいか確認してね（超意訳）と書いてありました。

解決へ

ひとまずupdate-alternativesをやる前に現在の状態を確認しましょう。

# update-alternatives --display libglx.so
libglx.so - manual mode
  link currently points to /usr/lib64/xorg/modules/extensions/xorg/xorg-libglx.so
/usr/lib64/xorg/modules/extensions/nvidia/nvidia-libglx.so - priority 100
/usr/lib64/xorg/modules/extensions/xorg/xorg-libglx.so - priority 50
Current 'best' version is '/usr/lib64/xorg/modules/extensions/nvidia/nvidia-libglx.so'.

ふむ、どうやらxorgのlibglx.soがマニュアルで優先になっているようです（なぜ？）。
上で紹介したところでは、--setで明示的にnvidiaのlibglx.soを指定していますが、priorityを見ると自動で良さそう。

# update-alternatives --auto libglx.so
update-alternatives: using /usr/lib64/xorg/modules/extensions/nvidia/nvidia-libglx.so to provide /usr/lib64/xorg/modules/extensions/libglx.so (libglx.so) in auto mode

ということで無事nvidiaのほうが有効になりました。

次に、/etc/ld.so.conf.d/nvidia-gfxG04.confファイルを見てみましょう。

# cat /etc/ld.so.conf.d/nvidia-gfxG04.conf 
#/usr/X11R6/lib64
#/usr/X11R6/lib

どうやらコメントアウトされているようです（なぜ？2回め）。
vimとかでコメントアウトを外して、ldconfigを実行します。

# cat /etc/ld.so.conf.d/nvidia-gfxG04.conf 
/usr/X11R6/lib64
/usr/X11R6/lib

# ldconfig

こうなればOK。

さてCtrl+Alt+BkspでXを終了して、無事上がってきます（ﾄﾞｷﾄﾞｷ
念の為、/var/log/Xorg.0.logを見てみると、(EE)の行がありません！
どうやら無事3Dアクセラレーションが有効になったようです。

VMwareを起動してWindows 10を立ち上げると…
「No 3D support is available from the host.」が表示されなくなりました。
画面の動きもスムーズで幸せです。

どうやら、libglx.soが何故かnvidiaのものが使われなかったのが原因だった、ということでした。

タグ:

おすすめ

コメントを残す

Amazon プライム対象