アカウント名:
パスワード:
(1)は仕様で、それ以降はOSで修正可能なようだから、比較的早く対応できる問題のように見えます。EIZOのページにも、以下の様に書かれていますから....
> (2) 以降の諸症状については、macOSの更新で改善する可能性がありますので、macOSを最新の状態に保つことを推奨いたします。
1番目は仕様といっても軽微ではないような。マルチモニタ構成に制限が出る。
EIZOの絵ではMacBookPro M1の絵で描かれているけれど、Mac mini M1だとどうなんだろう。ここでもHDMIとThunderbolt3含めてデュアルヘッドまでなのかな。あるいはThunderbolt3でディージーチェーンできるディスプレイだとどうなるのか。
M1チップに画面2画面までの制御機能しか無い(あるいはMacOS BigSur側にない)のかもしれない
チップの制限だと書かれていますね。
https://pc.watch.impress.co.jp/docs/column/nishikawa/1290745.html [impress.co.jp]
映像出力は、HDMI 2.0とThunderbolt 3(DisplayPort)。ただし、2つあるThunderbolt 3は、1つのみ画面出力可能で、HDMIと合わせて最大で2画面出力となる。M1版のMacBook AirとMacBook Proでも同じ仕様で、どうやらこれはM1の制限のようだ。
実用性はともかく、やろうと思えばM1版Mac miniで最大6台はできるみたい。M1搭載Mac、最大6台の外部ディスプレイに接続する方法が発見 [engadget.com]
DisplayLinkはUSBで繋がるフレームバッファにドライバ側で作った仮想デスクトップの動画を流すような仕組みなので、USB 2.0でも3.0でも同時に何枚でも常識の範囲内で増やせますけど、全部CPU描画になって負荷と性能と画質はリモートデスクトップ並みになりますよ。内蔵GPUの制限を回避できるわけではないです。
> 全部CPU描画になって違うのでは？
DisplayLinkは、動作イメージとしては、本体GPUが仮想フレームバファに描画して、そのデータを圧縮してUSBを通し、USBの先（ドングル）で復元してHDMIなりDisplayPort経由でモニタに送るので、それほど遅くはならない。
Windowsの場合は、直結と比べてだいたい9割ぐらいのパフォーマンスを発揮する [impress.co.jp]。
ただ、ドライバの出来が性能を大きく左右すると思われるので、もしかしたらMac OSでは劇遅なのかもしれないけど。ちなみにLinuxではかなり問題があるように見受けられます [archlinux.jp]。
(...)D2Dは上記の通りサポート外のためか、画面が真っ白になり実行できなかった。 一方OGLは、何もしないと画面全体がフラッシュしている状態だが、実行しているウィンドウからマウスポインタをセカンドディスプレイ側に移してフォーカスをアウトすれば、タスクバーが現れる状態ではあるものの実行可能であった。
それほど遅くはならない、と言われましても。仮想フレームバッファの描画をdGPUの孫請けに出して画面が白く点滅している状態というのは、遅くなるとかならないではなく動作していないと表現すべきなのでは……
「全部CPU描画になって」の部分は明らかに間違いですね
GPU上にフレームバッファをCPUのメモリ側にUSBの送信用バッファを用意して
1) GPUがフレームバッファに描画 （通常のディスプレイ表示はこれで終わり）2) GPUのDMAでフレームバッファを送信バッファへコピー3) USBコントローラーのDMAで送信バッファの内容を送信
とすればオーバヘッドは2)と3)の部分だけで、CPU負荷はほとんど掛かりません。DMAコンテキストの初期化は一回だけで良いので、CPU処理はDMA完了を待つだけ、割り込みを受け取るだけです。
ずいぶん古い記事もてくるね。もう少し新しのだとこれでどうでしょう。https://pc.watch.impress.co.jp/docs/topic/review/1096807.html [impress.co.jp]
>圧縮もCPUで行なうためある程度負荷に耐えるCPUを使用する必要がある。ということで、解像度が大きいとそれなりの負荷がありそうだけど。
>フルスクリーンにすると、シーンの変更といった画面内容が大幅に変化したときや、スクロールしたときに、テアリングやカクつきが発生した。1080p、60Hzでも難しいみたいね。動画は非推奨とある。
「そうすればするだけ」ってえらく簡単そうに言いますけど、存在しないAPIとかできない動作とか架空のドライババージョン依存のハックとかが気軽に活用されてる気がするんですが……
実際のDisplayLinkデバイスとドライバはいろんなバージョンのWindowsとかLinuxで動きますし、普通にCPU負荷かけてきますよ。定期的に捨て値で出てくるので何個か持ってるんですよね。
> 気軽に活用されてる気がするんですが……
それはあなたの思い込みですよ
> 普通にCPU負荷かけてきますよ。
DMAとか割り込み処理って何かご存知ですか？
あなたの「常識」で話をせずに、せめて DisplayLink CPU 負荷 でググるなりして実際どうなのか製品レビュー調べるなりしてみたら？
仮想ディスプレイドライバをDirectXアプリとして実装すれば結果的にGPU上にフレームバッファが置けるとか、圧縮をGPUの機能で掛けられればDMAで取り回すだけでCPU時間は取らない、という話なら分かるんですが、DisplayLinkの仮想ディスプレイがGPUに繋がってる物理的なモニタとしてGPUドライバに認識されてる前提ですよね? そういう実装にはなっていないので……
DMAはデータの転送にCPU負荷を掛けなくてすまなくなるやつやろ？割り込みは通知か。それ以外の処理でCPU使うところあったらDMAしてもしなくてもCPU使うやん。何かをご存じなせいで何かをご存じあげないんじゃね？
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
開いた括弧は必ず閉じる -- あるプログラマー
どれも軽微かな? (スコア:1)
(1)は仕様で、それ以降はOSで修正可能なようだから、比較的早く対応できる問題のように見えます。
EIZOのページにも、以下の様に書かれていますから....
> (2) 以降の諸症状については、macOSの更新で改善する可能性がありますので、macOSを最新の状態に保つことを推奨いたします。
Re: (スコア:0)
1番目は仕様といっても軽微ではないような。
マルチモニタ構成に制限が出る。
Re: (スコア:0)
EIZOの絵ではMacBookPro M1の絵で描かれているけれど、Mac mini M1だとどうなんだろう。
ここでもHDMIとThunderbolt3含めてデュアルヘッドまでなのかな。
あるいはThunderbolt3でディージーチェーンできるディスプレイだとどうなるのか。
M1チップに画面2画面までの制御機能しか無い(あるいはMacOS BigSur側にない)のかもしれない
Re:どれも軽微かな? (スコア:2)
チップの制限だと書かれていますね。
https://pc.watch.impress.co.jp/docs/column/nishikawa/1290745.html [impress.co.jp]
映像出力は、HDMI 2.0とThunderbolt 3(DisplayPort)。
ただし、2つあるThunderbolt 3は、1つのみ画面出力可能で、HDMIと合わせて最大で2画面出力となる。
M1版のMacBook AirとMacBook Proでも同じ仕様で、どうやらこれはM1の制限のようだ。
Re:どれも軽微かな? (スコア:1)
実用性はともかく、やろうと思えばM1版Mac miniで最大6台はできるみたい。
M1搭載Mac、最大6台の外部ディスプレイに接続する方法が発見 [engadget.com]
Re:どれも軽微かな? (スコア:2)
DisplayLinkはUSBで繋がるフレームバッファにドライバ側で作った仮想デスクトップの動画を流すような仕組みなので、USB 2.0でも3.0でも同時に何枚でも常識の範囲内で増やせますけど、全部CPU描画になって負荷と性能と画質はリモートデスクトップ並みになりますよ。内蔵GPUの制限を回避できるわけではないです。
Re:どれも軽微かな? (スコア:1)
> 全部CPU描画になって
違うのでは？
DisplayLinkは、動作イメージとしては、本体GPUが仮想フレームバファに描画して、そのデータを圧縮してUSBを通し、USBの先（ドングル）で復元してHDMIなりDisplayPort経由でモニタに送るので、それほど遅くはならない。
Windowsの場合は、直結と比べてだいたい9割ぐらいのパフォーマンスを発揮する [impress.co.jp]。
ただ、ドライバの出来が性能を大きく左右すると思われるので、もしかしたらMac OSでは劇遅なのかもしれないけど。ちなみにLinuxではかなり問題があるように見受けられます [archlinux.jp]。
Re:どれも軽微かな? (スコア:2)
(...)D2Dは上記の通りサポート外のためか、画面が真っ白になり実行できなかった。
一方OGLは、何もしないと画面全体がフラッシュしている状態だが、実行しているウィンドウからマウスポインタをセカンドディスプレイ側に移してフォーカスをアウトすれば、タスクバーが現れる状態ではあるものの実行可能であった。
それほど遅くはならない、と言われましても。仮想フレームバッファの描画をdGPUの孫請けに出して画面が白く点滅している状態というのは、遅くなるとかならないではなく動作していないと表現すべきなのでは……
Re: (スコア:0)
「全部CPU描画になって」の部分は明らかに間違いですね
GPU上にフレームバッファを
CPUのメモリ側にUSBの送信用バッファを用意して
1) GPUがフレームバッファに描画 （通常のディスプレイ表示はこれで終わり）
2) GPUのDMAでフレームバッファを送信バッファへコピー
3) USBコントローラーのDMAで送信バッファの内容を送信
とすればオーバヘッドは2)と3)の部分だけで、CPU負荷はほとんど掛かりません。
DMAコンテキストの初期化は一回だけで良いので、CPU処理はDMA完了を待つだけ、割り込みを受け取るだけです。
Re: (スコア:0)
ずいぶん古い記事もてくるね。
もう少し新しのだとこれでどうでしょう。
https://pc.watch.impress.co.jp/docs/topic/review/1096807.html [impress.co.jp]
>圧縮もCPUで行なうためある程度負荷に耐えるCPUを使用する必要がある。
ということで、解像度が大きいとそれなりの負荷がありそうだけど。
>フルスクリーンにすると、シーンの変更といった画面内容が大幅に変化したときや、スクロールしたときに、テアリングやカクつきが発生した。
1080p、60Hzでも難しいみたいね。動画は非推奨とある。
Re:どれも軽微かな? (スコア:2)
「そうすればするだけ」ってえらく簡単そうに言いますけど、存在しないAPIとかできない動作とか架空のドライババージョン依存のハックとかが気軽に活用されてる気がするんですが……
実際のDisplayLinkデバイスとドライバはいろんなバージョンのWindowsとかLinuxで動きますし、普通にCPU負荷かけてきますよ。定期的に捨て値で出てくるので何個か持ってるんですよね。
Re: (スコア:0)
> 気軽に活用されてる気がするんですが……
それはあなたの思い込みですよ
> 普通にCPU負荷かけてきますよ。
DMAとか割り込み処理って何かご存知ですか？
Re: (スコア:0)
あなたの「常識」で話をせずに、せめて DisplayLink CPU 負荷 でググるなりして実際どうなのか製品レビュー調べるなりしてみたら？
Re:どれも軽微かな? (スコア:2)
仮想ディスプレイドライバをDirectXアプリとして実装すれば結果的にGPU上にフレームバッファが置けるとか、圧縮をGPUの機能で掛けられればDMAで取り回すだけでCPU時間は取らない、という話なら分かるんですが、DisplayLinkの仮想ディスプレイがGPUに繋がってる物理的なモニタとしてGPUドライバに認識されてる前提ですよね? そういう実装にはなっていないので……
Re: (スコア:0)
DMAはデータの転送にCPU負荷を掛けなくてすまなくなるやつやろ？割り込みは通知か。
それ以外の処理でCPU使うところあったらDMAしてもしなくてもCPU使うやん。
何かをご存じなせいで何かをご存じあげないんじゃね？