Microsoft、ゲームデータ読み込みを改善する「DirectStorage 1.1」をリリース 39
ストーリー by nagazou
リリース 部門より
リリース 部門より
Microsoftは7日、ゲームのロード時間を短縮するための「DirectStorage 1.1」をリリースした。最近の3Dゲームは小さなデータを大量に読み込む処理が多用されており、加えてファイルサイズを減らすため圧縮されていることが多い。そのため、一般的なファイル読み込み関数と展開処理ではCPU負荷が爆発的に高くなるのだという。DirectStorageではGPUを用いた圧縮データの展開（GPU decompression）がサポートされ、GPUを積極的に活用することで、CPU負荷を劇的に引き下げることができるとしている。Windows 10と11で利用可能だが、各社GPUの最新ドライバーを利用する必要があるとのこと（DirectX Developer Blog、窓の杜）。
アボカド (スコア:1)
サンプルが🥑なのはなんでさ
Re:アボカド (スコア:2, 参考になる)
このアボカドモデル自体は、DirectStorageというより、デモ開発に使用したgITF 2.0の表示用サンプル (2017年)。
https://github.com/KhronosGroup/glTF-Sample-Models/tree/master/2.0/Avocado [github.com]
経緯は、この方のツイートにあり、Microsoftの寄贈。
https://mobile.twitter.com/cx20/status/1205677259668914177 [twitter.com]
で、なぜ、そのチョイスなのか？という話になると、
#4358965 [srad.jp]さんの言う通り、gITF 2.0デモ用モデルが作成された2017年にアボカドが小流行していたことに由来する可能性が高い。
Re: (スコア:0)
モデ権ないので付けられないけど、参考になりました。
レナみたいな権利問題も起きないだろうし。
Re: (スコア:0)
> KhronosGroup
DirectStorageに飛びつく人が少ない理由が分かっちゃった気が…。
さらに言えば、2017年って「ペイント3D」の年だよね。
OpenGLもWebGLもglTFもKhronosGroupは2017年が最新で時間が止まってる…いやPBRの拡張は昨年もあったけど。
3Dモデルアセット流通を推進しようとした業界の痕跡がこんなところに…、
というかWebGL対応はちょっとずつ進んでるから(メタバース狙い？)、これからちょっと巻き返すのかな？
＃gITFではなくglTFね。OpenGLのgl。
Re: (スコア:0)
OpenGLはVulkan、WebGLはWebGPUという後継がすでにあるか開発中なので進歩が止まっているのは当然なのでは。動きが遅いのは標準化団体あるあるでむしろHTMLが異常
Re: (スコア:0)
ここ数年、メキシコ産アボカドが流行ってるらしい。
有名人のインスタで支持増やしたとか…。
https://avocadosfrommexico.com/blog/entertaining/how-the-avocado-becam... [avocadosfrommexico.com]
2014年頃には、オリーブオイル代替品になる、とか、
今年の10月に、アボカド熟成度スキャナが開発された、
と話題になったくらいには認知されている。
#下ネタ由来や開発者自身に因る揶揄で
Re: (スコア:0)
> #下ネタ由来
日本での、まりもっこり人気の立ち位置にありそう。
Re: (スコア:0)
TarZさんのファンという可能性。
https://srad.jp/comment/1375062 [srad.jp]
対応ゲームが全然でないのはなぜ？ (スコア:0)
いつになったらゲーム側が対応してくれるのかな？
開発者向け提供開始が去年の7月でまだ対応タイトルがないのをみると既存ゲームを後から対応させるのは難しいのでしょうか？
Re:対応ゲームが全然でないのはなぜ？ (スコア:1)
今年のニュースで、市販エンジンでは以下のような感じだから、先は長そう。
・2022/7 Unreal Engine 「計画はあるが、いつとは言えない。」
https://www.neowin.net/news/epic-games-confirms-microsoft-directstorag... [neowin.net]
・2022/3 Unity「エンジンが恩恵を得られる領域と実装にかかる負担を調査中。DirectStorageの実装は簡単ではない。」
https://forum.unity.com/threads/will-unity-support-directstorage.1255269/ [unity.com]
内製エンジンでは、ゲーム発表時には分かるんだろうけど…。
Re: (スコア:0)
内製エンジンだとクロスプラットフォーム対応がめんどいのでMSのファーストパーティースタジオ以外やらないと思う。
Re: (スコア:0)
スクエニのFORCEPOKENは内製エンジン（ルミナスエンジン）だけどDirectStorage対応表明してる
来年ぐらいからのマルチタイトルなら対応も増えてくるんじゃないかな
XBOXで出るタイトルなら似たような仕組みで実現されてるだろうから、対応自体は難しくないだろうし
ただDirectStorageが使える環境なんて限られてるから、どっちも対応させてテストやら考えたら割に合わないとは思う
Re: (スコア:0)
> クロスプラットフォーム対応がめんどい
これに尽きるんじゃないですかね。
Re: (スコア:0)
内製エンジンだとバグってても自社製品に影響するとこだけ直せばいいからね
Re:対応ゲームが全然でないのはなぜ？ (スコア:1)
ある程度パフォーマンス最適化してるゲームだと、既に「小さなデータを大量に読み込む処理」なんてやってないからなぁ。
古いゲームや出来の悪いゲームは平気で数万ファイルとかあるけど、まともな開発のゲームは数十GBの容量でもファイル数は数百ぐらい。データは大抵少数のデータベースファイルにまとめてある。
そういう事情なのでゲームエンジン側も積極的に対応する意味が無いのかもしれない。
対応したところで、出来の悪いゲームは使わないし、出来のいいゲームは既に必要としていない。
Re: (スコア:0)
MOD界隈の住人としては耳が痛いなぁ
Re: (スコア:0)
既存のゲームだとコストの問題が大きい 対応した方が良いんだろうけど別になくてもいいよねってぐらいなら対応しないのが普通
Re: (スコア:0)
こういうのってエンジン側がやってくれるからゲーム屋は特に何もしなくて良いけど、既存ゲームでその辺アップデートするのは辛いよね。って感じかな。
Re: (スコア:0)
検証が面倒だしマルチプラットフォームだと結局個別対応になるからやだなみたいな感じだろう。
普通はCPU負荷＜GPU負荷なのでは？ (スコア:0)
今のゲームで「CPUがボトルネックになってパフォーマンスが出ない」っていうケースって多くない気がするのですが。
最新のAAAゲームでをSandyBridgeで…とかだとありそうだけども。
逆にGPUの性能不足で、というのはダイレクトにありますよね。
最近のモダンなCPUを積んでいれば、DirectStorageでGPUの処理が増えたら、逆にパフォーマンス落ちそうな気がするんですけど、どうなんでしょう。
教えて詳しい人。
Re:普通はCPU負荷＜GPU負荷なのでは？ (スコア:1)
大きいのは最初やシーン切り替え時のロード
ここはSSD→VRAMにモデルやテクスチャを転送するのが処理の殆どでGPUは遊んでる
CPU経由だとバスの負荷も高いし、今の読込速度ってGB/sレベルだからその展開ってCPUフルに使っても追いつかないぐらいヘビーだったりする
だからCPUを介さずに読み込めれば、圧縮も合わせて転送速度以上の性能が実際に出る
あとはUE5のNaniteのようなストリーミング技術を使った仮想ジオメトリかな
ローポリ→ハイポリへの切替がより高速に出来るから見た目の品質も上がるし、不要なモデルはとっととメモリから追い出すとかも出来るからVRAMの利用効率も上げられる
とはいえこっちは「DirectStorage必須」みたいな領域だから、基本的にはPS5/XBOXのCS向けって感じだろうけど
Re: (スコア:0)
>>基本的にはPS5/XBOXのCS向けって感じだろうけど
CSで行われている事を
PC向けにAPI整えて出来るようにしただけだから合ってる
Re: (スコア:0)
CPU側もGPU側もメモリが限られるPS5/XBOXには意味のある技術だけど、PC向けだとメモリ増やしてキャッシュに乗せればOKだからなぁ。
CPU側のメインメモリでも数十GB/sと最速レベルのSSDの10倍速いし、SSDと違ってランダムアクセスでもそれほど遅くならない。
最近のPC向けAAAタイトルだと、データは1ファイルにパックしてあり、起動時にSSDからメインメモリにシーケンシャルに高速転送してる。
メインメモリが大量にあることを前提に、容量さえあれば分割リードとかは必要なく大部分のデータをメインメモリに保持する。
VRAMには必要な分だけしかロードしてないけど、メインメモリにデータがあるのでストレージ速度には足を引っ張られない。
Re: (スコア:0)
ValheimやCoreKeeperのようなUnity製のインディーゲームはほぼCPUネックでフレームレート上がらなくなりますよ。
ちょっとした規模の建築をしただけで3080積ん出ても30FPS切る状況なんて当たり前のようにあるので辛いです。
まぁこういう場合大抵1コア2スレッドにしか負荷がかかってなくてUnity側の問題なのかなとも感じますけど…
Re: (スコア:0)
そういう場合は単にソフトが糞ってだけ
Re: (スコア:0)
そりゃ何でも遅いソフトに当てはまる話ね
今回は律速部分がIOなら効果がある
糞でもなんでもこういう技術で速くなるなら実装してほしいです
どうせ自分じゃ直せないんでしょうから
Re: (スコア:0)
そうでもない
Re: (スコア:0)
ググレカス
Re: (スコア:0)
ググレカス
Re: (スコア:0)
現代的なゲームはデータをCPUで読み出し解凍し加工するにせよしないにせよ再圧縮してGPUに転送しGPUで伸長してデータを使うというふろーになります。未来のゲームではデータをGPUで読み出してGPUで展開してGPUで使います。単純に無駄な工程が減るのでレイテンシを削減できるわけです。大抵は処理時間よりデータ読み出しの方に時間が
Re: (スコア:0)
ここは酷いインターネッツですね
Re: (スコア:0)
UnrealEngineなんかは、レガシー引きずってる影響で分散処理がヘボヘボなので、大量のキャラが動き回るようなことをやるとすぐにGameThread(ゲーム処理のスレッド）が膨れ上がってパフォーマンスが出なくなります。
他のゲームエンジンも大抵そうなんじゃないですかね。「ゲームに必要なのはシングルスレッド性能」なんて今でも言われますし。
あとはUIに大量の要素を適当に置くと意図しないところで再描画用の計算が走ったりとか。
Re: (スコア:0)
シングルスレッド命と言われるのにスレッド数が膨れ上がって遅くなるというのは矛盾しているような…
Re: (スコア:0)
膨れ上がってるのはスレッド数じゃなくてGameThreadに積まれる処理だよ
Re: (スコア:0)
GameThreadという単一のスレッドで全部処理していてそこが重くなって律速になるということ。
この辺とか参考になりますかね
https://qiita.com/EGJ-Takashi_Suzuki/items/33449c17c61d1ed30079 [qiita.com]
ついでに影処理もライトの形態によっては特殊なことをしていて、範囲内の全ての動くオブジェクトに対して一枚ずつレンダーターゲット（のエリア）を割り当ててシャドウを書くとかをRenderThreadという単一のスレッドでやっているので、
こちらも数が多くなると重くなる
#こういうノウハウを知らずに作ると酷いことになる
結果的に使われることはないだろうね。 (スコア:0)
全体には影響しない。
Re: (スコア:0)
既に実装を宣言してるゲームが存在するのに？
Re: (スコア:0)
メモリが少ないグラボは 入出力の高速化でカバー出来るというのは 十分メリットだと思うけどね 1.1で圧縮､展開に対応した事で更に高速化出来るし
そこそこのグラボでもそんなにパフォーマンスが落ちないように出来ると言えば解るかと
Re: (スコア:0)
テスクチャ等が統一されにくいMMO系ネトゲで人がいっぱい居るときレイドとかで引っ掛かりが減りますみたいなメリットが有りそう。
後は、オープンマップ系の逐次ロードが早くなればそれはそれで快適になるだろうね。コケなくて済むよ！
# MMO系は魔法やら装備やら種類が多種多様だからVRAM負荷高めになりやすい。