2026/05/15 0:47
RTX 5090 と M4搭載のMacBook Air：これらでゲームは遊べるのか？
RSS: https://news.ycombinator.com/rss
要約▶
Japanese Translation:
ユーザーは、Thunderbolt 4 のトンネルを利用して M4 MacBook Air に NVIDIA RTX 5090 eGPU を接続でき、「タイム・トゥ・ファースト・トークン」において最大 120 倍の劇的な向上を達成しています。この向上は特に AI インスペクションのプロンプト解析（プリフィル）に効果的であり、ネイティブの macOS ドライバーが用意されていない状況下でも非常に有効です。しかし、今回の設定には通常/tinygrad の最近のドライバーが必要となる場合があり、それらは M4 Pro でのネイティブ Metal に比べて著しく低速（約 10 倍）です。また、安定性を確保するには広範な技術的な回避策が必要です。例えば、カーネルクラッシュを修正するための独自 QEMU パッチ適用（
HV_MEMORY_EXEC本文
MacBook Air にフルサイズのデスクトップ用 GPU を取り付けることってどうでしょう？実は、それが可能なんです。まず FTC が求める免責事項から：私のリンクから購入された場合、コミッションを得ることがあります。「勝算なんて言うな」ね。認めるのがいやですが、私の多くのプロジェクトで最初のステップは、AI に聞いていることが多いです。知らないことを教えてくれるかもしれません。幸いにも、実用的ではないくらい挑戦的なのがお気に入りに近いです。
Thunderbolt eGPU とは何？
- 計画は、大きな PC ゲーム用 GPU、NVIDIA RTX 5090 を M4 MacBook Air に接続することです。これを行うには、PCIe を Thunderbolt アダプトする Thunderbolt ドックに接続し、さらに USB-C ポートへ接続します。Thunderbolt は PCIe を USB-C ケーブル経由でトンネリングするため、コンピュータから見ると Thunderbolt デバイスは確かに PCIe デバイスであり、USB デバイスではありません。Thunderbolt 4 では最大 40Gbps の速度で 4 ペイスの PCIe チェインを使用でき、トンネリングによるわずかなパフォーマンスの損傷があります。
- USB4 はオプション機能として同じ PCIe トンネリングをサポートしており、一部の非-Thunderbolt USB4 ポートでもこれを行うことができます。互換性のあるポートを持つラップトップに GPU を接続するためにこれを活用できます。ラップトップ側の Thunderbolt は GPU ドックへ接続され、GPU はモニターに DisplayPort 経由で接続されます。
- これが公開された直後、私はこのドックを壊してしまいました。コンピュータから見ると、デバイスは少し遅い PCIe デバイスのように見えるため、通常これらのデバイスに使用するドライバを使い回せます。eGPU は Linux や Windows で概ねそのまま動作します。Raspberry Pi にも使用可能ですが、こちらは Oculink 仕様であり Thunderbolt は不可です。
- しかし最初の足かせは、macOS が Apple Silicon マシン向けに NVIDIA も AMD も GPU ドライバを同梱していないことです。
tinygrad について？
- tinygrad は最近、独自の macOS eGPU ドライバーを発表しました。これは NVIDIA および AMD ハードウェア向けの独自オープンソースドライバパイプラインを含む、全新的な AI スタックです。残念ながら、メインの目的が AI 推論やゲーム実行の場合、tinygrad はあなたに適さない解決策かもしれません。YouTuber の Alex Ziskind が示した動画では、tinygrad を介して eGPU で推論を行うことは、eGPU を使用せず M4 Pro に直接ネティブな Metal 推論を実行するよりも約 10 倍も遅いことが明らかになっています。
- tinygrad eGPU ドライバーは tinygrad スタック専用であり、他の用途には利用できません。また、様々な AI モデルへのサポートも非常に限られています。GPU に NVIDIA PTX コードを実行させることと、任意のソフトウェアに対応する汎用ディスプレイドライバを書くことは比較的死に難い問題です。
- 現時点で eGPU と Mac で実際にできることは何でしょうか？既存の Linux ドライバーを利用できます。現在では Linux も Apple Silicon マシン上で動作可能ですが、遺憾ながら現時点では Linux カーネルは Apple Silicon 上で Thunderbolt をサポートしていない（内部デバイスと USB3 のみ）。しかし……macOS ホスト上で 64 ビット ARM バーチャルマシン (VM) で Linux を実行することは可能です。macOS は Thunderbolt デバイスをサポートしており、Linux は NVIDIA GPU をサポートします。これらを組み合わせて、GPU を Linux VM へパススルーさせることにしましょう。
- あくまでハイレベルでは、GPU を Linux VM 内に配置するだけです。VM と Mac ホストのアーキテクチャは同じ (arm64) なので、パフォーマンスは比較可能でしょう。もちろん、問題は細部にあります。
macOS 上での PCI パススルーの実装
- PCI デバイスの基本: VM が PCI デバイスと対話するための要件として、2 つのポイントがあります。
- PCI BAR (Base Address Registers): 各 PCI デバイスは、コンピュータが読み書きできるメモリチャンクを通じて通信します。各デバイスのためにコンピュータ上に予約されたメモリ領域が存在し、PCI パススルーを機能させるためには、これらのメモリ領域を VM 内にミラーリングする必要があります。
- DMA (Direct Memory Access): デバイスがホストのメモリの情報を読み書きする方法です。CPU がデータをコピーして負荷をかけるのではなく、デバイスが自動的にメモリの転送を行います。GPU の場合、コンピュータのメモリからテクスチャを直接ビデオメモリへコピーする際に使用されます。
- PCI BARのマッピング:
- QEMU が VM を起動すると、ゲストのメモリレイアウトを設定します。通常の RAM については、QEMU 内の
関数を呼び出すことになり、Hypervisor.framework メソッドを使用します。hvf_set_phys_mem()hv_vm_map(mem, guest_physical_address, size, HV_MEMORY_READ | HV_MEMORY_WRITE | HV_MEMORY_EXEC); - 次に、ホスト PCI DriverKit ドライバに接続し、PCI デバイスのメモリをプロセスへマッピングするよう依頼します（ドライバー側のコードの詳細は省略しますが、非常に類似したボイラープレートです）。
mach_vm_address_t addr = 0; mach_vm_size_t size = 0; IOConnectMapMemory64(driverConnection, 0, mach_task_self(), &addr, &size, kIOMapAnywhere); - さて、これで
が取得でき、BAR0 メモリがプロセス内で直接アクセス可能になりました。通常のメモリのようになんでも読み書きできます。addrvolatile uint32_t *bar0 = (volatile uint32_t *)addr; printf("BAR0[0] = %x\n", bar0[0]); // 出力例: BAR0[0] = 0x1b2000a1 // これは my RTX 5090 を記述するデバイス固有の定数です。 // // BAR0[0] は BOOT_0 レジスタです。フィールドは以下のように分解されます: // arch = 0x1b → GB200 GPU ファミリー // impl = 0x2 → GB202 die (RTX 5090) // major_rev = 0xa → ステッピング A // minor_rev = 0x1 → レビジョン 1 (合せて stepping A1)
- QEMU が VM を起動すると、ゲストのメモリレイアウトを設定します。通常の RAM については、QEMU 内の
- これで、QEMU にデバイスメモリを
で呼び出し、それをゲストへマッピングすれば、ゲストコードがそのマッピングに触れるたびにホストオーバーヘッドを最小限に抑えて直接 GPU と対話できます。これが理論上の最良のパフォーマンスです。実際にやってみると、VM が PCI BAR メモリに触れた瞬間、ホストカーネルがクラッシュしました。以前このような経験がないと、錯乱します。全コンピュータがフリーズし、トラックパッドのフィードバックがソフトウェア制御されているため、突然クリックしなくなります。近所の犬や猫が鳴き始めます。家の壁から写真が転がり落ちます。最終的にコンピュータが再起動し、このダイアログが表示されます。hvf_set_phys_mem() - さて、デバイスメモリを直接マッピングできないことはわかりましたが、他に手を打つ余地があります。メモリのすべてのアクセスをトラップしてゲストを出て QEMU へ戻り、QEMU が各読み書きをデバイスに転送します。動作は正しく保てますが、極めて低速です。多くのワークロードでは問題は別にあることが多いですが、性能に敏感な作業の多くは DMA であり、BAR を通じてコマンドを押し込む速度にも注目するパスもあります。
- 私は Apple へのバグレポートを作成し、AI の助けを借りて再現用の小さなプログラム (~100 ラインの C) で問題を証明しました。VM を立ち上げ、デバイス BAR をゲストにマッピングしてアクセスコードを実行できます。このバージョンはクラッシュせずに実行されましたが、QEMU はホストをパニックに陥せていました。しばらく悶々としていました。ゲストページテーブルの問題か？BAR がゲスト RAM と微妙な衝突を起こしていたのか？なぜ犬と猫はまだ鳴いているのか？
- 最終的に絶望して AI コーディングアシスタントにサンプルと QEMU の比較を頼みましたが、即座に私のマッピングが
を使用しているのに対し、QEMU はHV_MEMORY_READ | HV_MEMORY_WRITE
を使用していることが指摘されました。再び AI に敗北しました。おどろおどろしいブログプロジェクトですら安全ではなくなりました（大部分は冗談ですが）。HV_MEMORY_READ | HV_MEMORY_WRITE | HV_MEMORY_EXEC - QEMU での回避策はわずかな変更でした。動作しますが、完璧ではありません。ARM にはデバイスメモリのいくつかのフラバー（Device-nGnRnE/nGnRE/nGRE/GRE ファミリー）があり、書き込みがまとめられるか、順序が入れ替わるか、あるいは早期に確認されるかの異なるルールがあります。x86 の最も許可的なエンドでの write-combining に概ね相当します。
- 実際のハードウェア上、GPU のプリフェッチ可能な BAR はまとめて処理することを許可されることが想定されており、BAR0 よりもバッチ書き込みが数倍高速です。しかし
ではこの設定のためのフラグがなく、すべてのデバイスマッピングが厳格な nGnRnE として終了してしまいます。これではどうしようもなく、トラップ処理に比べてまだ約 30 倍速いですが、BAR を書くことを通常の時の約 10 倍遅くします。hvf_vm_map()
DMA
- これはおそらくプロジェクトで最も不安な部分でした。まず、Linux VM PCI パススルーを実行する PC でこれがどのように機能するかを振り返り、macOS での課題と比較しましょう。単にコンピュータがデバイスと対話している場合（VM は関与せず）、彼らは直接対話しできます。PC はデバイスに「DMA バッファーを用意できたので、このメモリアドレスから始めましょう」と伝え、デバイスはそれらのメモリの直接アクセス（つまり DMA）を行います。簡単です。
- VM が関与すると複雑になります。ゲスト物理アドレスはホスト物理アドレスに対応していません。VM の RAM は利用可能などこかのホストメモリの一部として割り当てられています。つまり、ゲストがデバイスに「0x00000000 に DMA しなさい」と伝えても、デバイスはホストで実際にそこにあるものを喜んで書き込みます。最も単純な解決策は以下の 2 つです。
- ゲストメモリをすべてピン止めして、デバイスが触る可能性がある間に出し入れされないようにする。
- デバイスとホストメモリの間に IOMMU というハードウェアユニットを配置する。ハイパーバイザーがゲスト→ホストの翻訳でプログラムし、デバイスの各 DMA リクエストはリアルタイムで再マッピングされる。
DMA Request: Read/Write 0x00000000 IOMMU Translation Table: 0x00000000 - 0x80000000 -> 0x20000000 - 0xA0000000 Host Physical Memory: 0x20000000 - 0xA0000000
- これは粗末な解決策です。ゲストには特別なことはできませんが、ホストはすべてのゲスト RAM をピン止めしておく必要があります。より高度なアプローチ（仮想 IOMMU など）もありますが、この記事の範囲外です。
- Apple Silicon 上の DMA: Apple Silicon 上では、IOMMU に概ね相当する DART というハードウェアユニットがあります。これは VM 固有のものではなく、デバイスが任意のホストメモリにアクセスするのを防ぐセキュリティ境界としても機能します。理想としては、Linux が上記単純なケースで IOMMU を使うのと同じように DART を使用したいところですが、残念ながら DART（少なくとも Thunderbolt デバイスの PCI DriverKit を介して）には厳しい制約があります。
- ~1.5GB のマッピング制限。RAM で 1.5GB の VM は起動できますが、CUDA はメモリ不足になり、現代のゲームは 8-16GB 必要です。
- ~64k のマッピング上限。多くの小さな DMA バッファーがある場合、マッピングテーブルが埋まります。
- アドレスまたはアライメント制御なし。PCI DriverKit がマッピングアドレスを自動的に割り当てます。選択したり、アライメント制約を指定することもできません。これにより仮想 IOMMU は不可能で、ゲスト自身が DMA アドレスを選択する必要があります。
- 1.5GB の天井が最大の初期ブロックでした。いくつかの回避策を試みました：DMAs が着陸するであろう範囲を推測して事前にマッピングし（もちろん失敗）、
デバイスツリー属性を使用してすべてを事前割り当てられた領域を通じて強制するものを使用しました。制限されたプールのアプローチは単純なデバイスでは実際には機能しますが、GPU ドライバーはそのモデルにフィットしすぎず奇妙です。（詳細についてはrestricted-dma-pool
のスレッドで議論しています）。qemu-devel - apple-dma-pci: 結局 QEMU に新しい仮想 PCI デバイス
を設計しました。パススルー GPU とともに VM 内に挿入され、ゲスト内の同伴カーネルドライバーは NVIDIA ドライバーの DMA マッピング呼び出しをインターセプトします。これは正直言って非常に辛いハックですが、機能します。apple-dma-pci - マッピングは DMA リクエストごとにオンデマンド作成され、バッファーが解放されたときに取り壊されるため、必要なマッピングメモリ量を減らせます。1.5GB の制限に収まるのは、その瞬間のライブ DMA バッファーのワーキングセットだけであり、ゲスト全体のメモリではありません。
- ゲストドライバーは早期にロードされます（
設定を介して）、そのため NVIDIA ドライバーが触れる前に GPU を検出し、カスタム DMA ops をスワップできます。/etc/modules-load.d/
static struct dma_map_ops apple_dma_ops = { .map_page = apple_dma_map_page, .unmap_page = apple_dma_unmap_page, .map_sg = apple_dma_map_sg, .unmap_sg = apple_dma_unmap_sg, .alloc = apple_dma_alloc, .free = apple_dma_free, }; static int apple_dma_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id) { struct pci_dev *gpu = pci_get_device(PCI_VENDOR_NVIDIA, PCI_ANY_ID, NULL); if (!gpu) return -ENODEV; set_dma_ops(&gpu->dev, &apple_dma_ops); pci_dev_put(gpu); return 0; }
- 各カスタム op は薄いラッパーです。その引数を小さなリクエストにマーシャルし、
バーチャル BAR のメモ리에書き込み、ベルレジスタを蹴り、返信を待ちます。ホスト側では QEMU がリクエストを受け取り、PCI DriverKit ドライバへ引き渡され、実際の DART マッピングが行われ、結果として得られる DMA アドレスはゲストメモリに書き戻されます。NVIDIA ドライバーには違いを感じるはずがありません。apple-dma-pci
Linux VM (Guest) -> apple-dma-pci 仮想デバイス -> VM exit -> マップされたアドレスがスタックをたどって戻ってくる -> NVIDIA のアライメントのニッチ
- しかし、すぐにうまく機能したわけではありません。ドライバーが初期化してカードを読み込ませても、CUDA ワークロードを実行しようとすると、この面白いカーネルログメッセージが表示されました。
[ 456.194883] NVRM: nvAssertOkFailedNoLog: Assertion failed: The offset passed is not valid [NV_ERR_INVALID_OFFSET] (0x00000037) returned from pRmApi->Alloc(...) [ 456.371282] NVRM: GPU0 nvAssertFailedNoLog: Assertion failed: 0 == (physAddr & (RM_PAGE_SIZE_HUGE - 1)) @ mem_mgr_gm107.c:1312 [ 456.372020] NVRM: nvAssertOkFailedNoLog: Assertion failed: The offset passed is not valid [NV_ERR_INVALID_OFFSET] (0x00000037) returned from pRmApi->Alloc(...)
- これまで DMA に関するセクションで、DMA マップされたバッファーのアライメントを制御できないことに触れました。悲しいことです。この時点で、ドライバーに修正できる何かがあるか調べてみました。関連する部分は以下です。
if (type == UVM_RM_MEM_TYPE_SYS) { if (size >= UVM_PAGE_SIZE_2M) alloc_info.pageSize = UVM_PAGE_SIZE_2M; else if (size >= UVM_PAGE_SIZE_64K) alloc_info.pageSize = UVM_PAGE_SIZE_64K; status = uvm_rm_locked_call(nvUvmInterfaceMemoryAllocSys(gpu->rm_address_space, size, &gpu_va, &alloc_info)); // TODO: Bug 5042223 if (status == NV_ERR_NO_MEMORY && size >= UVM_PAGE_SIZE_64K) { UVM_ERR_PRINT("nvUvmInterfaceMemoryAllocSys alloc failed with big page size, retry with default page size\n"); alloc_info.pageSize = UVM_PAGE_SIZE_DEFAULT; status = uvm_rm_locked_call(nvUvmInterfaceMemoryAllocSys(gpu->rm_address_space, size, &gpu_va, &alloc_info)); } }
- モジュールに追加のデバッグログを加えると、これが 16MB の
タイプのアリケートであることを確認できました。つまり、最大の（2MB）ページサイズを使用しています。皮肉なことに、すでにアリケーションが失敗する場合は回避策が存在します。小さくなるページサイズで再試行します。ただし、アライメントのエラーコード (UVM_RM_MEM_TYPE_SYS
) を考慮していないだけです。NV_ERR_INVALID_OFFSET - さて…状態チェックをこの新しいエラーも含めるように拡張すれば、メモリを再割り当てにフォールバックし、すべてが動作します！いいえ、ドライバーを修正せざるを得なくて本当に不便です。新しいドライバーリリースが出ると、また修正する必要がありますね。私はドライバーのフォークを維持して、自動的にパッチ付きのパッケージセットを生成することもできるかもしれませんが、既存のマインラインドライバーを動作させる方法があるか考えていました。
の呼び出しをホットパッチし、常に小さいページサイズを使用するようにしたらどうでしょうか？Linux カーネルの kprobes 機能を使って、任意のカーネル関数の入手にハンドラを付与できます。ハンドラの内部では、その時点で CPU レジスターにアクセスでき、実行前に関数の引数を検査または変更できます。パッチの簡略化されたバージョンは以下のような形です。nvUvmInterfaceMemoryAllocSys()
/* ドライバーの内部レイアウトに一致させなければならない */ struct uvm_alloc_info { /* ... その他のフィールド ... */ u64 pageSize; /* ... その他のフィールド ... */ }; /* nvUvmInterfaceMemoryAllocSys(address_space, size, gpu_va_out, alloc_info) * arm64 ABI: 引数は x0, x1, x2, x3 に — alloc_info は 4 番目の引数。 */ static int pre_alloc_sys(struct kprobe *p, struct pt_regs *regs) { struct uvm_alloc_info *info = (void *)regs->regs[3]; /* DART の 16KB マッピングが常にアライメントを満たすように小さなページを強制する。 */ info->pageSize = UVM_PAGE_SIZE_DEFAULT; return 0; } static struct kprobe kp = { .symbol_name = "nvUvmInterfaceMemoryAllocSys", .pre_handler = pre_alloc_sys, }; static int __init patch_init(void) { return register_kprobe(&kp); } static void __exit patch_exit(void) { unregister_kprobe(&kp); }
- このカーネルモジュールをロードすると、NVIDIA ドライバーへの変更なしで、すべての
の呼び出しがデフォルト（小さい）ページサイズをリクエストするようになります。nvUvmInterfaceMemoryAllocSys() - この時点で、NVIDIA ドライバーは単純なワークロードで動作します。
マッピングの統合 (Coalescing mappings)
- 素晴らしい！これでドライバーが機能し、基本的なワークロードも動作しているようです。残念ながら、ゲームの設定を本当に上げると、 totalCount 制限の ~64k を超える小さなマッピングを大量に作成し始めます。以前「これは問題になるかもしれない」と触れましたね。最初はアプリ適用のパッチで悪化しているだろうかと考えていましたが、その通りではありませんでした。どちらの場合も制限に達します。
- 私はここまで来てしまい、すぐにあきらめようとはしていませんでした。すべてのマッピングをログに記録し、分布を見ると、90% 以上のマッピングが 4kB であることが分かりました。それらは通常連続していないため、統合して全体のマップ数を減らすのが容易そうに見えませんが、クラスタとして現れています。
- メモリをより大きなクラスタの観点から見られるようにしたスキームを考え出しました。すべてのゲストメモリを固定サイズ（例えば 256kB）の領域に分けます。ドライバーが 4kB バッファーのマッピングを要求すると、その内の 256kB クラスタ全体をマッピングし、後続で同じクラスタに入る割り当てはそれらのマッピングを再利用します。
個々のマッピング: バッファー 1 つにつき 4kB のマップ -> 10 マップ 256 kB クラスタにグループ化: クラスタ化されたマッピング -> 多くのバッファーが共有する 256kB のマップ -> 3 マップ
- 言及すべきいくつかのエッジケースがあります。2 つのクラスタにまたがるバッファーは、このスキームにはうまくフィットしないため、その場合はクラスタアロケーター外で直接マッピングにフォールバックします。実際にはそれが割り当ての数分のみで発生します。クラスタのライフタイムは参照カウントで処理されます。クラスタ内の最後のライブ 4kB バッファーが解放されたときに、クラスタは自動的にアンマップされ、必要以上に DART マッピングを保持しなくなります。
- このスキームは厳密に必要なメモリよりも少し多くの総メモ리를マップすることになります。各クラスタには実際のライブバッファーの裏付けがない「スロップ」バイトがあります。幸運なことに、実際にはテストしたワークロードでも ~1.5GB のマッピング天井に留まります。重要なのはマッピング数を 64k に減らすことでした。試みたワークロードでは、ライブマッピングの数は約 4 倍減少し、最高設定で demanding なゲームを実行するのに十分な余裕がありました。
- これは性能感度の低いパスではありません。マッピングは主にゲームがロードされている間に起こり、実行中ではないため、変更自体が速度を向上させるわけではありません。クラスタリングは完全にゲストドライバー内で発生するため、DART マッピングを作成するためにホストに呼び出す頻度が減ります。
その他のパフォーマンス上の懸念
- スケジューリング: テストを行っている際、パフォーマンスが非常に不整合で、しばしばかなり低速であることを発見しました。ベンチマークスコアは大幅に変動し、ランダムに 50% も遅いように見えることがありました。これを見つけるのに費やした時間について少し恥ずかしいですが、QEMU が vCPU スレッドに優先順位を設定していないことが分かりました。スケジューラーが背景タスクとして優先度を下げているのか、単なる運のせいなのかは不明ですが、ベンチマーク実行中に VM に多くの時間を割いてもらえていないように見えました。
- macOS にはプロセス優先順位を操作するための複数の API があります。数試して有効に役立つと思われるこの選択肢に落ち着きました。QEMU へパッチを当てて、vCPU が起動する際、大幅に高い優先度を得るようにしました。
--- a/accel/hvf/hvf-accel-ops.c +++ a/accel/hvf/hvf-accel-ops.c @@ -162,6 +162,18 @@ static void *hvf_cpu_thread_fn(void *arg) rcu_register_thread(); + pthread_set_qos_class_self_np(QOS_CLASS_USER_INTERACTIVE, 0); + + { + struct sched_param param; + param.sched_priority = sched_get_priority_max(SCHED_RR); + pthread_setschedparam(pthread_self(), SCHED_RR, ¶m); + } + bql_lock(); qemu_thread_get_self(cpu->thread);
- 総ストア順序 (Total Store Ordering): 私が説明してきた VM は arm64 Linux ですが、出荷されているゲームのほとんどは ARM 上でネイティブには動作しません。x86-64 Windows バイナリーです。実際にプレイするには、FEX-Emu（JIT x86-64 から aarch64 へ）の上に Proton (Valve の WINE フォークで Windows API を実装) を重ねます。この翻訳レイヤーには、x86 と ARM に異なるメモリ順序ルールがあるという非明らかな懸念点があります。x86 は Total Store Ordering (TSO) を使用し、1 つのコアからのストアがプログラム順序で他のコアに可視になります。ARM のモデルはもっと弱く、明示的なバリアなしでほぼ何でも入れ替えられます。多くのコードはスレッド間の単純なロードとストアに依存しており、x86 エミュレーションを ARM に移植するにはどこにも高価なバリアが必要か、または微妙な方法でクラッシュします。
- Apple Silicon にはエスケープハッチがあります：ペーシング・スレッドごとのハードウェア TSO モードです。vCPU の ACTLR_EL1 のビット 1 をフリップすると、そのスレッド上のすべてのロードとストアが x86 スタイルの順序に従い、バリアは必要ありません。Apple はこれを macOS 15+ の Hypervisor.framework 経由で提供しています。Linux 側では、Hector Martin が 2024 年にカーネルパッチシリーズを公開し、ビットをスレッドごとにフリップする
prctls を追加しましたが、アップストリームはマージしませんでした。しかし Asahi のカーネルには含まれています。PR_SET_MEM_MODEL - QEMU も TSO を提供していませんが、UTM（macOS GUI 付きの QEMU フォーク）にはそれが vCPU 全体に対して有効にするパッチがあります。私がテストのために借用しました。
--- a/target/arm/hvf/hvf.c +++ a/target/arm/hvf/hvf.c @@@ -1358,8 -1352,21 +1358,23 @@@ int hvf_arch_init_vcpu(CPUState *cpu arm_cpu->isar.idregs[ID_AA64MMFR0_EL1_IDX]); assert_hvf_ok(ret); + if (__builtin_available(macOS 15, *)) { + uint64_t actlr; + ret = hv_vcpu_get_sys_reg(cpu->accel->fd, + HV_SYS_REG_ACTLR_EL1, &actlr); + assert_hvf_ok(ret); + actlr |= (1 << 1); /* Apple TSO enable bit */ + ret = hv_vcpu_set_sys_reg(cpu->accel->fd, + HV_SYS_REG_ACTLR_EL1, actlr); + assert_hvf_ok(ret); + } else { + error_report("HVF TSO mode requires macOS 15 or later"); + return -ENOTSUP; + } aarch64_add_sme_properties(OBJECT(cpu)); return 0;
- そのビットを設定すると、FEX-Emu のソフトウェア TSO エミュレーションを無効にできます。ソフトウェア TSO エミュレーションの切り替えには明確な副作用があります。ハードウェアビットなしでオフにすると、Geekbench 6 が途中でクラッシュします。
- やがて FEX が Hector のパッチを含むカーネルで実行された場合に自動的に TSO フラグを検出できることに気づきました（Asahi Linux ではデフォルト）。彼のパッチはプロセスが CPU の TSO 状態をクエリし、自身にフラグを設定できるようにする
を追加します。カーネルはコンテキストスイッチごとにプロセスごとのビットを保存・復元します。prctl() - カスタムカーネルの使用を避けたいと思っていたため、kprobes だけでこれを実装しようとしましたが、すべてのコンテキストスイッチで実行されるコードをパッチすることにリスクを感じました。ただし、カーネル内で TSO ビットを検出するのは容易なので、
ドライバーに「ニッチ」を追加しました。以前のものと同様に。TSO ビットが設定されている場合（QEMU が VM 起動前に設定）、Hector パッチからのゲッター/ seter を模倣するapple-dma-pci
の kprobe をインストールします。 setter は実際には何もしませんが、FEX はまだフラグをクエリして、より高速なモードに切り替えることができます。prctl() - 以下は異なる仮想化/エミュレーション層のパフォーマンス影響を示しています：この記事の残りの部分のために、以下のものに焦点を当てます。
- ホストパフォーマンス – これには、エミュレーション層なしで CPU から期待できる最高のパフォーマンスを示します。
- FEX で CPU TSO をオンにしたゲストパフォーマンス – これは x86 ゲームをプレイしようとする場合の CPU の最高のパフォーマンスを示します。問題なのは、これはネイティブホストパフォーマンスの約 50% にすぎないことです。
ベンチマーク
-
ソフトウェアエンジニアなら、これまでのストーリーを楽しんでいただけたでしょう。そうでない場合は、おそらくここで始めることを望むでしょう。あなたがおそらく決して問わないであろう質問に答えます：RTX 5090 を MacBook Air に接続するとゲームのパフォーマンスは向上しますか？AI 推論はどうでしょうか？
-
CPU の比較: ゲームパフォーマンスは GPU がどれだけ高速かを決定するだけでなく、CPU も重要です。マシンが何ができるかをレベルセットするために、まず CPU ベンチマークの比較から始めましょう。チャートを見ると、Apple Silicon Mac は非常に速いことがわかります。買える最も高速な消費向け CPU のいくつかであり、同様のインテルチップの電力消費の一部だけでそれを実現しています。
-
問題は、x86 を FEX 経由でエミュレートすることが、そのパフォーマンスの約 50% を最初から損なうことです。M4 MacBook Air はこれにより大きく影響を受けます。パフォーマンスは 2020 年インテルベースの MacBook Pro よりも悪くなります。一方、M5 Max MacBook Pro は decent な状態です。パフォーマンスは古いゲーミング PC と比較的近いもので、決して劣勢ではありません。
-
サイバーパンク 2077: M4 Air ネティブ macOS、M4 Air 上で eGPU を通じて ARM Linux VM で FEX を用いて x86 をエミュレート、2020 インテル MacBook Pro ネティブ Linux (VM なし、FEX なし) 同じ eGPU、M5 Max MacBook Pro ネティブ macOS、M5 Max 上で eGPU を通じて ARM Linux VM、そしてネイティブ PCIe で同じ RTX 5090 が接続された古いゲーミング PC(i5-12600K) の 6 つの設定で実行します。
- "+ Framegen" は eGPU/ネティブ PCIe 構成には DLSS 4x、ネティブ macOS 構成には FSR 2x を使用します（DLSS は NVIDIA 専用であり、macOS では利用不可）。
-
720p Low: GPU はほとんど汗をかいていませんが、CPU とエミュレーション/仮想化オーバーヘッドが支配的です。
- ネティブ macOS の M5 Max が 200fps で勝ちます。強力な CPU にて、エミュレーション/仮想化層から解放され、パフォーマンスは優れています。
- ゲーミング PC が 180fps と続きます。GPU にそれほど負荷がないため、デスクトップ CPU はあなたが期待するほど大きく前に出ることはできません。
- ネティブ M4 Air(61fps) は、実は M4 Air + eGPU (49fps) よりも優れています。720p Low では統合 GPU には十分な余裕があり、FEX + 仮想化のコストを節約できます。M4 Air でネティブに行くのが有益になるのはこの解像度だけです。
- M5 Max + eGPU (73fps) は M5 Max ネティブより遥かに低速です。エミュレーション/仮想化オーバーヘッドに縛られ、どれだけのパフォーマンス損失があるか（2.7 倍）が見られます。
-
1080p: GPU がより重要になりますが、統合 GPU も依然として軽い設定で続けます。
- ゲーミング PC は全体的に明確な勝者です。High で 161fps、RT Ultra で 105fps、DLSS framegen で驚異的な 407fps です。
- ネティブ macOS の M5 Max が eGPU を一切使用せずに 1080p High を 131fps で粉砕します。また RT Ultra でも 59fps または FSR framegen で 88fps を処理します。1080p でプレイして問題ない場合、このプロジェクトなしでもセットアップ済みです。
- 1080p High では M5 Max ネティブ (131fps) が M5 Max + eGPU (68fps) よりも速いです。720p と同じ話です。統合 GPU はこの解像度には十分で、エミュレーション/仮想化オーバーヘッドがダメージを与えます。
- ネティブ macOS の M4 Air は依然として RT Ultra でプレイ不可能（7fps）です。FSR framegen でも倍増するだけ（13fps）で、依然としてプレイ不可能です。
- eGPU を取り付けると、M4 Air を RT Ultra で 30fps、framegen で 119fps に持ち上げます。ネティブに対する大きな向上です。
- 2020 MBP + eGPU は M4 Air + eGPU と同等のパフォーマンスを発揮します。同じ GPU で FEX を考慮すると類似した実効 CPU です。
-
4K: GPU がボトルネックになります。
- ゲーミング PC が再び支配的です：RT Ultra で 100fps、DLSS framegen で 282fps。Thunderbolt から GPU にないオーバーヘッドがないことと、仮想化/エミュレーションペナルティなしが役に立ちます。
- ネティブ M5 Max は 4K RT Ultra で 25fps または FSR framegen で 42fps を管理します。ボーダーラインプレイ可能です。eGPU なしでも、M5 Max の統合 GPU はほぼ 4K でレイトレーシングが可能に近いです。
- M5 Max + eGPU は 4K RT Ultra で堅くプレイ可能な 47fps、framegen で 145fps です。
- ネティブ macOS の M4 Air は 4K では絶望的です。
- eGPU を取り付けると、同じマシンを RT Ultra で 27fps、DLSS framegen で 111fps に持ち上げます。これこそが GPU を接続するものの最も劇的な例です。完全にプレイ不可能から 4K で完全にプレイ可能になります。
- 2020 MBP + eGPU は再度 M4 Air + eGPU と比較可能。
-
まとめ:
- 720p ではネティブが eGPU に勝ります。GPU がボトルネックでない場合、FEX + 仮想化オーバーヘッドが GPU アップグレードよりも重要です。
- より高い解像度では、eGPU は M4 Air にとって不可欠です。Cyberpunk を「完全にプレイ不可能」（4K RT Ultra で約 3fps）から「完全にプレイ可能」（27fps または framegen で 111fps）にします。
- eGPU が同じである場合、M5 Max は M4 Air より約 30-70% 速いです。これは純粋に M5 の CPU 優位性の表れです。
- ネティブ PCIe のゲーミング PC は依然として M5 Max + eGPU より約 2 倍速いです。Thunderbolt + 仮想化 + x86 エミュレーションはネティブ PC に比べて多くのことをあなたに課します。それは避けられない通りがあります。
- M5 Max の統合 GPU は本当に驚くべきものです。eGPU なしでも、1080p High で 131fps、1080p RT Ultra で 88fps (FSR framegen) に到達できます。
-
Apple XDR ディスプレイでゲームをテストし、6K 解像度での実行が可能であることを発見しました。M5 Max + eGPU で framegen を使用しても、6K レイトレーシングであっても平均 128fps を得られます。このセットアップでゲームをプレイしましたが、ラグやスタッターを感じませんでした。eGPU がない場合、framegen でも約 20fps にすぎません。
-
GravityMark: これ以外に CPU をあまり使用しない GPU グラフィックベンチマークを見つけることができませんでした。これは Thunderbolt リンクのコストと、GPU パススルーソリューションで追加した Apple 特有のオーバーヘッドを分離する際に有用です。
- Thunderbolt を通ることは、このベンチマークでは GPU パフォーマンスの約 20% を失います。ゲーミング PC の結果でも確認できます：同じマシンと GPU でも PCIe スロットから Thunderbolt コネクションに変更すると約 20% のフレーム数を失うのです。PCIe-over-USB トンネルのコストです。
- デバイス間の Thunderbolt パフォーマンスは完全に予測できません。ゲーミング PC で最も速く、M4 MacBook Air で最も遅いことを期待していましたが、MacBook Air は確かに最も遅いが、2020 インテル MacBook Pro は Thunderbolt で 1080p で約 2%、4K で約 6% ゲーミング PC を上回ります。異なるハードウェアトポロジーは予期せぬ方法で展開されます。Thunderbolt ケーブルさえも数字を数％動かすことができました。
- M4 MacBook Air は最後に立ち留まります。ギャップを閉じるために調査すべき長いリストがあります：イントラップレイテンシー、リサイズ可能な BAR サポート、BAR アクセスレイテンシ（以前のアプレ Hypervisor.framework の問題）。現時点では、M4 Air eGPU はゲーミング PC 上の Thunderbolt で同じ GPU を実行するよりも約 13% 遅く、ネイティブ PCIe に挿入された GPU よりも約 31% 遅いです。
-
シャドウ オブ ザ トムレイダー: ネティブ macOS ポートを持つ別のゲーム。同じ 3 つの設定：M4 Air ネティブ、Linux VM を通じて eGPU で M4 Air、ネイティブ PCIe で接続された GPU とゲーミング PC。
- eGPU は M4 Air を 4K (ネティブで 8fps) からプレイ可能（40fps）にし、1080p のボーダーライン（26fps）から快適に 30 以上（42fps）にします。興味深くも、eGPU での 1080p と 4K はほぼ同一（42 vs 40fps）です—ボトルネックは FEX 下の CPU であり、GPU でなく、解像度を下げることは助けになりません。
- FEX が道にないゲーミング PC は、両方の解像度で約 2.5 倍速いです。
-
ホライズン ゼロ・ダAWN リマスター: これは私が試した中で DMA メモリ制限の上限に達した唯一のゲームです。720p でも最低設定でもベンチマークを開始できませんでした。1.5GB を超えるメモリを一度にマッピングしようとしました。これはこのセットアップがうまく機能しないのを防ぐ主要なプラットフォーム問題の一つを示しています。
-
DOOM (2016): 古い id Tech ゲームエンジンを非常に OpenGL に依存して使用します。十年前には、ゲームを DirectX ではなく OpenGL で実行する用意がある場合、DirectX（Microsoft）がプロプライエタリであり OpenGL が「オープン」標準だったため、他のプラットフォームへの移植が容易でした。現在 macOS 上で良好にサポートされていないため、CrossOver でも完全にプレイ不可能です。皮肉なことに Windows PC ではうまく動作しますが、Mac には eGPU セットアップなしでは文字通りプレイできません。
- 確かに動作します！ゲーム内ベンチマークがないため徹底的なテストは行いませんでしたが、ゲーム内パフォーマンスメトリックで 49fps を示すことができます。ゲームはかなりプレイ可能に感じました。フレームレートは変動しましたが、最高 60fps に達しましたが、常に 30fps 以上でした。パフォーマンスオーバーレイを見ると、CPU がボトルネックになっています、いつもの通りです。
-
Crysis は動作しますか？：あなたがたしただけに満足しています。2 つのプロファイルで Crysis Remastered を 1080p でテストしました：バンドルされた veryhigh.cfg プレセットと、リマスターに付属している有名な"Can it run Crysis?"プレセット（canitrunspec.cfg）。
- もちろん、M4 Air はゲーミング PC と比較できません。Crysis はシングルスレッド CPU パフォーマンスに非常に依存しています。2007 年には 96 コアのスレッドリッパーを持っていませんでしたが、それほど大きな問題ではありませんでした。今、エミュレーション層で多くのパフォーマンスを失うため、利用可能な CPU キャパシティの多くが使われていないことがとても痛いです。
- ゲーミング PC は最終的にほぼ 4 倍のフレームレートを達成しますが、M4 MacBook Air でもプレイ可能なフレームレートで Crysis を実行できます。
AI 推論
- GPU でできることはゲームだけではありません。いくつかのローカル LLM を試してみましょう。
- Qwen 3.6: Qwen はもっとも人気のある「オープンウェイト」大規模言語モデルの一つです。アリババクラウドが開発しました。35B パラメータのエキスパートミクスチャーバージョンをテストし、3B のアクティブパラメータを使用します。ローカル LLM 風景に詳しいなら、これらの量子化されたモデルバージョンが何十億もあることを知っているでしょう。フルサイズのモデルは通常消費者 GPU に収まることがほとんどですが、すべての重みを丸めて精度を低下させることで機能します。
- モデルの正確さを本当に測定しようとしているのではなく、各プラットフォームで最も速いバージョンを実行することに焦点を当てています。そのため、4 ビット「クアンティ」のモデルを使用します。NVIDIA GPU では NVFP4 バージョンを vLLM 経由で使用し、Apple Silicon では 4 ビット MLX クアンツを vllm-mlx で使用します。ベンチマーク実行は llama-benchy を使用して調整されます。完全には同じではありませんが、私が設置できた最良のリンゴ対リンゴの比較だと考えています。
- 比較すべき 2 つの指標はトークン生成速度（開始後の新しいトークンをどれだけ速く出すか）と最初のトークンまでの時間（Enter キーを押してから何か表示されるまでの待ち時間）です。
- ここではいくつかのことを見ることができます：
- プロンプトサイズが速度に意味のある影響を与えません。主にメモリバンドWIDTH で制限されており、各新規トークンの生成のためにモデル全体を GPU にストリーミングしているため、計算速度ではありません。
- Thunderbolt eGPU パフォーマンスは PCIe と非常に似ています。このステップの大部分の処理はカード上で起こり、コンピュータ上では起こりません。eGPU 構成でも約 9% のパフォーマンス低下があります。
- NVIDIA RTX 5090 は M4 Air より 6.5 倍速く、M4 Max Mac Studio より 2.1 倍速く、M5 Max MacBook Pro より 1.2 倍速いです。カードはすべての Mac を合わせた以上の電力をかなり使用するため、公平な戦いではありません。ただし、この GPU を Mac に取り付けると、本当にパフォーマンスに役立ちます。
- ここでは大きな Mac の問題が見られます：プロンプト処理（通称"prefill"）速度です。プロンプトが長くなるほど悪化します。4K トークンのプロンプトでもそれほど長くは見えませんが、M4 MacBook Air は解析に 17 秒かかり、リスポンス生成を開始する前に済ませる必要があります。一方、eGPU を取り付けると、150ms に過ぎません。120 倍速いです。長時間のチャットでは、実際のシステムでは以前のターンで話したものを再処理しない KV キャッシュを活用しますが、最終的に一度に LLM に多くのデータを渡す必要がある場合、それを解析する必要があり、Mac では遅くなります。
- Mac は良いメモリバンド性能を持っていますが、プリフェイジ段階は計算によって制限されています。5090 は単なるマックのいずれよりもはるかに多くの処理能力があります。見たくないでしょう。
- 見るべき他の軸はコンカレンシーです：一度に複数のリクエストをサービスした場合の追加の総スループット量。これはソロでチャットするのではなく、小さいチームのために LLM をホストする場合やバッチジョブを実行する場合にとって重要です。
- 5090 では、ここではすべての構成でほぼ線形にスケーリングします。1 つの同時リクエストから 4 つの同時リクエストに変えると、約 3 倍のスループットを得ます。それは 5090 がカード内の膨大な量の計算を持つためです。複数のリクエストをバッチしない場合、ほとんどが単に待機しています。したがって、このように同時リクエストを行うと、カードのより多くを活用します。
- Apple Silicon Mac ははるかに悪いスケーリング：M4 Max Mac Studio が 4 つの同時リクエストで約 2 倍になり、M5 Max MacBook Pro は約 1.7 倍だけです。M4 Air の統合 GPU はメモリバンドによって非常に制限されており、2 つの同時リクエストの測定値さえも単一のリクエストから区別するのが難しいほどノイズに満ちています。
- これは離散 GPU が単なる素朴な速度以上の興味深い理由のもう一つの理由です。テストでははるかに良いバッチング余裕を解放します。Apple Silicon MLX の実行は低電力のシングルユーザー推論用に最適化されており、高スループットサービングではありません。
Gemma 4: Gemma 4 31B は Qwen 3.6 と対照的に便利です。Google によって設計された稠密な 31B モデルであり、疎なエキスパートミクスチャーではないため、各トークンは 30 億のパラメータ全体をフローさせる必要がありますが、Qwen のように各トークンで 3B をアクティブにするだけです。これはより重いワークロードであり、約 10 倍の計算量になります。プラットフォームが追いつけるかをストレステストです。
- M4 Air の統合 GPU はこれらのチャートから除外しました。Gemma 4 でのパフォーマンスはテスト範囲以下でした。2 または 3 トークン/秒以上を得ることはできませんでした。
- すべての 3 つの vLLM バック設定は約 50 t/s で数％以内で一致します。パフォーマンスは Qwen 3.6 と比較して約 3 倍遅く、Gemma が各トークンで約 10 倍のパラメータをアクティブにするため、当然です。
- Mac は大幅に落ちます：M4 Max Mac Studio で約 22 t/s、M5 Max MacBook Pro で約 27 t/s—Qwen で管理したもののおよそ 4 分の一。Qwen と同じパターンです。M4 Max はさらに遅くなり、4K トークンのプロンプトを解析するのにおよそ 21 秒かかります。M5 Max はそれらを約 7.5 秒に切り減らしましたが、RTX 5090 は常に 400ms 以下です。ネイティブ MLX と eGPU のギャップは Qwen よりもさらに広いです。
- Gemma ではコンカレンシースケーリングがさらに劇的です。vLLM 設定は 4 つの同時リクエストで約 3.5 倍のスループットに達し（Qwen は約 3 倍）、両方の M4 Max Studio と M5 Max MacBook Pro は 2 つの同時リクエストで約 2 倍にスケーリングしますが、そこから 4 リクエストまでほとんど動じず、MLX バックエンドがその時点で何らかのバッチングを飽和させていることを示唆しています。
これを実行できますか？
- 私は「このものをダウンロードすれば OK です」という回答を望みますが、残念ながらそれは単純ではありません。このプロジェクトには Apple からの特別なエンタイトルメントが必要です。私はこれを申請し、授与に対してオープンかもしれないと聞きましたが見ていないばかりで、待機時間がかかる月単位と伝えられています。
- その間、ドライバーの独自のバージョンを構築できます（署名証明書アカウントには Mac が必要ですが、SIP を無効にするか、低セキュリティモードを使用する必要はありません）。それをロードできます。試してみたい場合は、ここにコードを取得できます。それに付随するランチャーは自動的に特別な
ドライバーがインストールされた事前構築 Ubuntu イメージをダウンロードします。独自に Linux ディストロを実行する場合は、パススルー部分を機能させるために VM へそれを手動でインストールする必要があります。apple_dma - また、全体の安定性が最高ではないことも警告します。FEX には Steam がループでクラッシュするバグがあります。何らかの理由でこのセットアップではより悪いです。動作している場合でも、特定のゲームを開始するのに分かかることがあります。DMA マッピング制限のため、マッピングが時間とともにフラグメントすることがあり、新しいゲームを実行するためのスペースを失う可能性があります。その後、Linux VM を停止し、GPU を差し替えて再挿入する必要があります。すべての DMA マッピングをクリアして再試行するためです。
- このセットアップで最も信頼できることは AI であり、それは本当にうまくいきます。OpenClaw セットアップとローカル LLM を望む奇妙な人の一人であれば、iMessage ボットとして同じ Mac を AI サーバーとしても使用できます。
- アップストリーム QEMU と連携してパッチを統合しようとしています。それがうまくいくかどうかは未定ですが、理想的には UTM などのメインストリーム QEMU デイストリビューションにこれがそのまま動作するものになるはずです。
- 最新情報: インストールが容易になった際、いつでも更新します。以下に登録してください。
結論
- さて：ゲームできますか？はい、十分な努力で。仮想 DMA デバイス、kprobes を介して NVIDIA ドライバーへのパッチ、ハードウェア TSO モード、大きな QEMU パッチ、DART の 64k 上限を下りるためのマッピングコエリセーラー…そしてそのすべてを終えた結果、MacBook Air は確かに RTX 5090 で Linux VM に Cyberpunk, Crysis, Doom を実行します。それはばかげたプロジェクトでした？それもはいです。
- ただし、同じ GPU の通常の PCIe スロットを持つ「本当の」PC はゲームに依存して 2-4 倍速いです。ここには多くの層があり、パフォーマンスを低下させます：FEX が x86 から ARM を翻訳、Proton が Windows から Linux を翻訳、BAR 書き込みが
の厳格なデバイスメモリ順序代償を支払うこと。また、Horizon Zero Dawn のようなゲームは DART のマッピング制限を超えてしまい、すべてを開始しないこともあります。hvf_vm_map() - より有用な発見は AI 推論がどのように機能したかです。CUDA は arm64 Linux でネイティブで動作し、M4 Air でのプリフェイジは約 100 倍減少し、単一ストリーム Qwen トークン生成は約 22 から約 155 ト/秒に向上し、コンカレンシーは実際にスケーリングします。600W eGPU を 22W のラップトップに取り付けることは、このワークロードで M4 Max Mac Studio に勝ちます。ローカル推論がホビーストの奇妙な人の領域の外でも本当に興味深いでしょうか？まだ不確かです。
- Linux が Apple Silicon 上で Thunderbolt サポートを得ると、多くの問題が収縮します：BAR レイテンシーペナルティなし、DMA リミットなし、VM オーバーヘッドなしなど。それはいつかは起こるかもしれません。
- 現時点では、これは「何が可能か」というプロジェクトであり、「買うべきか」ではありません。もし次世代の Mac がエミュレーション層のコストを超えて速度向上を達成するかどうかは驚きではありません。また、将来には ARM64 ネイティブゲームが増えるはずです。ゲームがネイティブであれば、Mac はおそらく私のゲーミング PC を追い越すかもしれません。
- 続報: 追跡して興味深いもの：
- Apple がエンタイトルメントを許可した際/時にインストールしやすいバージョンをリリースする。
- Thunderbolt 5 eGPU ドックを試す（TB4 のみテスト）。Gigabyte は現在統合型 5090 を備えたものを販売しています。M5 は TB5 をサポートします。
- Apple が BAR マッピング問題のための HVF API を修正した場合、再テストする。
- イントラップレイテンシーを測定し、それが助けるトリックがあるかを確認する。
- GravityMark をプロファイルして、具体的に何をしているかを特定し、なぜ遅いのかを理解しようとする。
- アップストリーム QEMU と連携してこの仕事を統合しようと続ける。
クレジット
- 私が手伝ってくれた数人の人に感謝したいだけです：
- Anees Iqbal は Apple からエンタイトルメントを取得できたと指摘し、私にプロジェクトを試すように鼓舞しました。私は彼が最初に提案したよりも別の技術方向に進みましたがかっこいいアイデアでした。
- Connor Sears は彼の最大限の M5 Max MacBook Pro でいくつかのことをテストすることを許してくれました。
- Pat Nakajima は私のために M4 Max Mac Studio でいくつかの AI 推論ベンチマークを実行し、またポストのエディットを行いました。彼は私に「エグゼクティブプロデューサー」クレジットを与えることを主張しました。したがって、このブログポストは Pat Nakajima がエグゼクティブプロデュースしたと述べる必要があります。
- Patrick Gibson は私の Mac Studio でいくつかのベンチマークを実行してくれました。
- Mohamed Mediouni は
メーリングリストで最初のレビューを行い、アプローチに対して一般的なフィードバックを提供し、非常に助けられました。そのような奇妙なニッチプロジェクトにおいて、アドバイスを得るのは難しいです。qemu-devel