Fadis
banner
fadis0.bsky.social
Fadis
@fadis0.bsky.social
GitHubのREADMEに書かれたFAQによると、作者は「これでDirect3D 7を使うどんなゲームも動くの?」という問いに対して、「残念ながらそうではない。この時代のDirect3Dは古いバージョンのDirectDrawやGDIとごちゃ混ぜにして使われる事があり、そうしたソフトウェアは意図したように動かない」としている
November 9, 2025 at 12:55 AM
D7VKはDirect3D 7のAPIを生やしてDirect3D 9に翻訳し、それをDXVKを使ってVulkanに翻訳する事で現代のPC上のWineでDirect3D 7を喋る黎明期の3Dゲームを動かそう、という物。 作者はWindowsでも動くかもしれないがテストはしていない、としている
github.com/WinterSnowfa...
GitHub - WinterSnowfall/d7vk: Vulkan-based implementation of D3D7 for Linux / Wine, spun off from DXVK.
Vulkan-based implementation of D3D7 for Linux / Wine, spun off from DXVK. - WinterSnowfall/d7vk
github.com
November 9, 2025 at 12:55 AM
1999年に登場したDirectX 7の3Dグラフィクス用コンポーネントDirect3D 7は頂点処理のステージがハードウェアで処理されるようになった最初のDirect3Dで、この頃からGPUによるアクセラレーションをあてにしてがっつり3Dグラフィクスで描くPCゲームが増えた
November 9, 2025 at 12:55 AM
現在DXVKにはDirect3D 8、9、10、11の実装がある。これとは別に開発されたDirect3D 12をVulkanに変換するレイヤーvkd3d-protonと合わせてDirect3Dを喋る多くのソフトウェアをWineで動かす事ができる。ただDirect3D 7以前を喋るアプリケーションに対する変換レイヤーは無かった
github.com/HansKristian...
GitHub - HansKristian-Work/vkd3d-proton: Fork of VKD3D. Development branches for Proton's Direct3D 12 implementation.
Fork of VKD3D. Development branches for Proton's Direct3D 12 implementation. - HansKristian-Work/vkd3d-proton
github.com
November 9, 2025 at 12:55 AM
DXVKはDirectXのDirect3DのAPIの呼び出しをVulkanに翻訳する変換レイヤー。Wineと組み合わせる事でDirect3Dを喋るWindows用のゲームをWindowsでなくても実行できるようになる。DXVKはWindows向けのゲームをSteam OS上で動かす上で重要な役割を果たしている
github.com/doitsujin/dxvk
GitHub - doitsujin/dxvk: Vulkan-based implementation of D3D8, 9, 10 and 11 for Linux / Wine
Vulkan-based implementation of D3D8, 9, 10 and 11 for Linux / Wine - doitsujin/dxvk
github.com
November 9, 2025 at 12:55 AM
今回KosmicKrispがVulkan 1.3の規格を完全に満たした事で、Vulkan 1.3で標準でサポートされている機能の範囲で書かれたアプリケーションであれば、コードを変更せずにAppleのデバイスにそのまま持っていけるようになった。KosmicKrispを動かすにはmacOS 15以上が必要でiOSはサポートされていない
November 2, 2025 at 1:03 PM
時が流れてMetalでも比較的新しいバージョンのmacOSではVulkanが標準で要求しているのと同等の機能が一通り備わるようになった。そこで要求するOSのバージョンを引き上げてVulkanの規格を完全に満たすように新しい変換レイヤーを実装するKosmicKrispの開発が始まった
November 2, 2025 at 1:03 PM
これは辛いので、Appleのデバイス向けのコードをVulkanで書けるように、VulkanをMetalに翻訳する変換レイヤーMoltenVKが開発された。ただMoltenVKが作られた当時のMetalはVulkanが標準で備えているいくつかの機能を欠いていた為Vulkanの規格を完全に満たす事ができなかった。
MoltenVKを使う場合Appleのデバイスで動かない機能を踏まないように注意してVulkanのコードを書く必要があり、クロスプラットフォーム辛い問題を完全に解決する事はできなかった
November 2, 2025 at 1:03 PM
GPUを使うソフトウェアを作る為のランタイムVulkanは多様なプラットフォームでサポートされていて、GPUを使うアプリケーションをクロスプラットフォームで開発したい場合に最も適した選択肢になっている。
ただAppleがAppleのデバイス向けに用意するGPUのドライバはMetalのAPIしか生えていない為、クロスプラットフォームの対象にAppleのデバイスが含まれている場合、Appleのデバイス用のコードだけ専用に書き直す必要があった。
November 2, 2025 at 1:03 PM
今回Vulkanに追加された拡張はGDEFLATEの展開を自前のシェーダーで書かなくても専用のコマンド一発で行えるようにする。厳密には以前からNVIDIAがベンダ拡張として提供していた物がマルチベンダ拡張になった物のようなので、NVIDIA以外のGPUでも使えるようになるのではないか、という期待が持てる。
専用のコマンドになったという事はGPU側は圧縮されたデータの展開を汎用の演算器ではなく専用のハードウェアで行っても良いという事になる。GDEFLATEは専用のハードウェアが無くても展開できるように作られた形式だが、今後もっと手の込んだ圧縮アルゴリズムが追加されるのかもしれない
October 28, 2025 at 4:33 PM
GDEFLATEでは圧縮対象を64KiBのページ単位で分割して圧縮する。1ページを1つのSubgroupが展開し、複数のSubgroupを使って圧縮されたデータを展開する。NVIDIAはこの方法で3.5GB/s程度しか出ないPCIe Gen3のSSDから12GB/sでデータを読めたとしている developer.nvidia.com/blog/acceler...
Accelerating Load Times for DirectX Games and Apps with GDeflate for DirectStorage | NVIDIA Technical Blog
Load times. They are the bane of any developer trying to construct a seamless experience. Trying to hide loading in a game by forcing a player to shimmy through narrow passages or take extremely slow…
developer.nvidia.com
October 28, 2025 at 4:33 PM
以前読んだビット列のバッファはストリーム毎に独立して持ち、他のストリームで既に出てきたビット列だったとしても自身のストリームで初登場のビット列は新出としてエンコードされる。この結果GDEFLATEはすっぴんのLZSSより少し圧縮率が悪くなる。
GDEFLATEの32本のストリームは32スレッドのSubgroupで処理する事を意図している。個々のスレッドが個々のストリームからトークンを1つ処理し、Subgroup演算で展開結果を書き込むオフセットを求める
October 28, 2025 at 4:33 PM
通常のLZSSはビット列を読んで、それが以前読んだビット列と同じなら以前出現した位置と長さに再登場を表す最上位ビット1を付けて出力する。新出のビット列なら最上位ビット0を付けてビット列をそのまま記録する。同じパターンが何度も現れていると再登場で表現できる部分が増えて圧縮率が上がる。
GDEFLATEはこのLZSSのトークンを32本のストリームに分けて記録する。展開時には32本のストリームがトークンを1つ展開する度に展開結果がストリームのID順にシリアライズされるので、そのように展開して正しい並び順でデータが展開されるように32本のストリームに順番にトークンを追加する
October 28, 2025 at 4:33 PM
GPU側でのデータの展開はPCI-Expressの帯域を使い切る勢いで圧縮されたデータが飛んできたとしてもボトルネックにならないくらいの速さで行える必要がある。従ってGPU上で沢山のスレッドで並列で展開してスケールするような形式で圧縮されている必要がある。
既存の可逆圧縮アルゴリズムの多くはシーケンシャルに展開する前提で作られていてスケーラビリティに難があった。2022年にNVIDIAが発表したGDEFLATEはLZSSをベースにGPU上で高速に展開できるように工夫した可逆圧縮形式で、MicrosoftのDirectStorage 1.1と組み合わせて利用可能だった
October 28, 2025 at 4:33 PM
GPUの計算能力に対してPCI-Express x16の帯域は非常に細い為、現代のGPUの性能を引き出すにはいかにPCI-Expressにでかいデータを流さずに計算をするかが重要になっている。データをストレージから読む必要がある場合NVMe SSDはPCI-Express x4に繋がっている為この問題はより深刻になる。
この為GPUに送る必要があるデータの中でも大きくなりがちな画像に関しては非可逆圧縮をかけた状態でPCI-Expressに流し、GPU側で展開する圧縮テクスチャが古くから用いられてきた。ただこの手法は非可逆なのでデータが少しくらい化けても問題ないケースにしか適用できない
October 28, 2025 at 4:33 PM
Linux 6.18ではsuccess_hookコールバックが追加された。このコールバックはvm_area_structがプロセスの仮想メモリに追加された後で、双方向リストの中にあるvm_area_structがconstで渡ってくる。/dev/zero等一部のドライバがこの仕組みが無いとmmap_prepareに移行できないらしい
October 24, 2025 at 3:10 PM
openコールバックでメモリをマップしてvm_area_structに必要な情報を書いて返すと、プロセスの仮想メモリへの追加が試みられる。追加が失敗するか、munmapされるとcloseコールバックが呼ばれる。他のvm_area_structへの操作はできず、メモリマネージャが知らない所での書き換えもできない
October 24, 2025 at 3:10 PM
mmap_prepareはプロセスの仮想メモリに実際にvm_area_structを追加する前に呼ばれる。引数のvm_area_descに含まれるvm_operations_structにopenコールバックをセットしておくとvm_area_structが渡ってくるが、この時点でこのvm_area_structはプロセスの仮想メモリに追加されていない
October 24, 2025 at 3:10 PM
そして、mmapが失敗した時に正しく仮想メモリの状態を元に戻せていなかった事に起因する脆弱性が見つかった。これを受けてLinux 6.17ではfile_operationsに自由すぎるmmapコールバックを置き換える新しいコールバックmmap_prepareが追加された
bugzilla.redhat.com/show_bug.cgi...
2328791 – (CVE-2024-53096) CVE-2024-53096 kernel: mm: resolve faulty mmap_region() error path behaviour
bugzilla.redhat.com
October 24, 2025 at 3:10 PM
コールバックが失敗を返した場合、Linuxのメモリマネージャはコールバックに渡していたvm_area_structをリストから外し、プロセスの仮想メモリの状態をmmapを試みる前の状態に戻さなければならない。
ここで厄介なのがvm_area_structを触れるmmapのコールバックは、渡ってきたvm_area_structに限らずそのプロセスのvm_area_structのリスト全体を書き換え可能である、という点。この結果メモリマネージャ側が何をmmapしているのか把握して処理を切り替えないと正しく状態を戻せなくなっている
October 24, 2025 at 3:10 PM
file_operationsにはファイルに対してmmapが要求された時に呼ばれるコールバックmmapが用意されている。Linuxではプロセスに割り当てたメモリはvm_area_struct構造体の双方向リストで管理される。mmapが要求されるとまず新しいvm_area_structがリストに追加され、それがコールバックに渡ってくる。
コールバックはプロセスが要求されたファイルの内容にアクセスできるように必要な操作を行った上で、ファイルの内容をマップした領域の情報を渡ってきたvm_area_structに記録する事が求められている
October 24, 2025 at 3:10 PM