Re: [情報] 資料顯示黃牛漸漸對「PS5主機」降低興趣
現在遊戲的繪圖 pipeline 可以從下面的文件中了解
http://intro-to-dxr.cwyman.org/presentations/IntroDXR_RaytracingShaders.pdf
不管是 PC/XSS/XSX/PS5或是 Xbox one/PS4 基本都是差不多的
現在主要在看 GPU 性能的 FLOPs 基本就是這些可程式化 Shader 的
運算能力,不管是那個 shader 都是用同樣的邏輯單元去處理。
如果把多邊型物件的運算,跟像素的生成分成兩個部分來看的話。
前者處理了畫面中的 animation 跟頂點這些計算,後者則是靠這些
資訊去生成對應的像素圖型,並對像素做後處理。
如果只看這部分那其實這個世代的主機,跟上個世代並沒有根本的
差異。或許可以說在 pixel 的後處理上,這個世代加上了 hardware RT
但上個世代並沒有。可是以 UE5 的 Lumen 來說是 software RT 並沒有
使用 RT 核心去處理。雖然有很多限制但是一樣有類似的效果。
所以雖然硬體進步了但是遊戲本身並沒有太大的差異,因為繪
圖的 pipeline 並沒有太大的差別。
接下來的遊戲畫面要有根本的進步,可能會需要走向 UE5 的
處理方式。或是說 primitive/mesh shader 的運作上面。
https://blog.siggraph.org/2021/04/mesh-shaders-release-the-
intrinsic-power-of-a-gpu.html/
以 UE5 來說 Nanite 跟 UE4 的差異是在多邊型的規模跟處理上面,
https://docs.unrealengine.com/5.0/en-US/nanite-virtualized-
geometry-in-unreal-engine/
Nanite Mesh 的基本要求是沒有不同距離的 LOD ,不管畫面的遠近,他們
都使用同樣細節的多邊形跟材質來處理。然後在primitive/mesh shder 的處理
上把超過 pixel 數量的多邊型給刪除掉。讓其後的 pixel shader 不需要去
處理那些過多且不必要的多邊型,因為畫面無法顯示那些多邊型。
只到這個部分其實就算是 Xbox one/PS4 不靠 mesh shader 也可以做到。雖
然說可能這樣一來在一開始的頂點運算上就會消耗掉太多的資源,後面
的像素處理就會沒有足夠的資源,解析度或是 fps 會被犧牲掉。但是並
沒有根本上的硬體限制去限制上一代的主機做這樣的事。
真正影響上一代主機做這件事的是主機的記憶體容量,跟硬碟資料的存
取速度,以及資料的壓縮/解壓縮能力。
UE5 的手冊中談到了
Nanite and Virtual Texturing systems, coupled with fast SSDs,
have lessened concern over runtime budgets of geometry and
textures. The biggest bottleneck now is how to deliver this
data to the user.
Data size on disk is an important factor when considering
how content is delivered — on physical media or downloaded
over the internet — and compression technology can only do
so much. Average end user's internet bandwidth, optical media
sizes, and hard drive sizes have not scaled at the same rate
as hard drive bandwidth and access latency, GPU compute power,
and software technology like Nanite. Pushing that data to users
is proving challenging.
他們文件中提供的例子中在多邊型的模型上所須要的容量是低多邊型
的十多倍。如果說當遊戲的畫面要保持著高多邊型跟高解析材質的水
準,那就須要很大的記憶體來存放。很可惜的記憶體並不是無限的。
所以這時高速的 SSD 跟即時的資料解壓縮能力就變得更為重要。因為
遊戲引擎需要不斷的刷新玩家在接下來幾分鐘或是幾秒鐘可以接觸到
的東西,以保證遊戲本身的順暢。
這部分是這個世代可以做到,但是上個世代的主機則沒有辦法的部分。
並不是說 GPU 的運算量有多少就可以改變的地方。
遊戲引擎的更新所需要的時間往往是更久的,至今應該還沒有遊
戲真的這樣去開發,所以變成了就算是用 4090 在遊戲上面得到的,就
是更高的 fps,或是更多 Deferred Renderer 的效果。可是對用比較低等
級硬體的玩家來說,能玩到的遊戲沒有根本的差異。因為多邊型跟材質
並無太大差異。
另一方面是如果廠商要這樣去開發遊戲,投入的成本規模跟人力也
會伴隨著提升,在當下的市場環境中要看到立即的轉變並不現實。
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 167.88.60.249 (美國)
※ 文章網址: https://www.ptt.cc/bbs/PlayStation/M.1668849356.A.13F.html
推
11/19 17:23,
1年前
, 1F
11/19 17:23, 1F
推
11/19 17:24,
1年前
, 2F
11/19 17:24, 2F
推
11/19 17:26,
1年前
, 3F
11/19 17:26, 3F
→
11/19 17:26,
1年前
, 4F
11/19 17:26, 4F
推
11/19 17:30,
1年前
, 5F
11/19 17:30, 5F
→
11/19 17:30,
1年前
, 6F
11/19 17:30, 6F
→
11/19 17:30,
1年前
, 7F
11/19 17:30, 7F
推
11/19 17:38,
1年前
, 8F
11/19 17:38, 8F
推
11/19 18:28,
1年前
, 9F
11/19 18:28, 9F
推
11/19 18:45,
1年前
, 10F
11/19 18:45, 10F
推
11/19 19:20,
1年前
, 11F
11/19 19:20, 11F
推
11/19 19:34,
1年前
, 12F
11/19 19:34, 12F
→
11/19 19:50,
1年前
, 13F
11/19 19:50, 13F
→
11/19 19:51,
1年前
, 14F
11/19 19:51, 14F
→
11/19 20:27,
1年前
, 15F
11/19 20:27, 15F
推
11/19 20:41,
1年前
, 16F
11/19 20:41, 16F
→
11/19 20:41,
1年前
, 17F
11/19 20:41, 17F
→
11/19 20:42,
1年前
, 18F
11/19 20:42, 18F
→
11/19 20:42,
1年前
, 19F
11/19 20:42, 19F
→
11/19 21:20,
1年前
, 20F
11/19 21:20, 20F
→
11/19 21:20,
1年前
, 21F
11/19 21:20, 21F
→
11/19 21:24,
1年前
, 22F
11/19 21:24, 22F
推
11/19 21:36,
1年前
, 23F
11/19 21:36, 23F
推
11/19 21:58,
1年前
, 24F
11/19 21:58, 24F
→
11/19 21:58,
1年前
, 25F
11/19 21:58, 25F
→
11/19 21:58,
1年前
, 26F
11/19 21:58, 26F
推
11/19 22:41,
1年前
, 27F
11/19 22:41, 27F
→
11/19 22:41,
1年前
, 28F
11/19 22:41, 28F
推
11/19 22:50,
1年前
, 29F
11/19 22:50, 29F
→
11/19 22:54,
1年前
, 30F
11/19 22:54, 30F
推
11/19 23:10,
1年前
, 31F
11/19 23:10, 31F
→
11/19 23:10,
1年前
, 32F
11/19 23:10, 32F
推
11/19 23:13,
1年前
, 33F
11/19 23:13, 33F
→
11/19 23:13,
1年前
, 34F
11/19 23:13, 34F
推
11/20 00:06,
1年前
, 35F
11/20 00:06, 35F
→
11/20 00:06,
1年前
, 36F
11/20 00:06, 36F
→
11/20 00:08,
1年前
, 37F
11/20 00:08, 37F
這個數字對現有的遊戲讀取或許有比較大的意義。但是對只在當下讀取所要資
料的模式意義或許並不大。當遊戲本身的資料量過度的膨脹且分散時,限制遊
戲存取資料的不是最大速度。而是如何能快速的把零碎的資料放到記憶體中。
所謂的瓶頸看的不是最快的而是最慢的。在這個時候資料的壓縮跟即時解壓縮
能力,比起 IO 的最大速度要來的更重要。因為限制 IO 的,可能是每秒存取
的檔案數量,而不是最大傳輸量。
推
11/20 01:21,
1年前
, 38F
11/20 01:21, 38F
→
11/20 01:22,
1年前
, 39F
11/20 01:22, 39F
→
11/20 01:24,
1年前
, 40F
11/20 01:24, 40F
→
11/20 03:21,
1年前
, 41F
11/20 03:21, 41F
→
11/20 03:21,
1年前
, 42F
11/20 03:21, 42F
推
11/20 06:48,
1年前
, 43F
11/20 06:48, 43F
推
11/20 06:49,
1年前
, 44F
11/20 06:49, 44F
→
11/20 06:49,
1年前
, 45F
11/20 06:49, 45F
→
11/20 07:09,
1年前
, 46F
11/20 07:09, 46F
→
11/20 07:10,
1年前
, 47F
11/20 07:10, 47F
→
11/20 07:10,
1年前
, 48F
11/20 07:10, 48F
→
11/20 07:10,
1年前
, 49F
11/20 07:10, 49F
※ 編輯: pupunin (167.88.60.234 美國), 11/20/2022 07:47:56
推
11/20 08:42,
1年前
, 50F
11/20 08:42, 50F
推
11/20 09:13,
1年前
, 51F
11/20 09:13, 51F
→
11/20 09:47,
1年前
, 52F
11/20 09:47, 52F
→
11/20 09:48,
1年前
, 53F
11/20 09:48, 53F
→
11/20 09:48,
1年前
, 54F
11/20 09:48, 54F
→
11/20 09:48,
1年前
, 55F
11/20 09:48, 55F
→
11/20 09:50,
1年前
, 56F
11/20 09:50, 56F
→
11/20 09:55,
1年前
, 57F
11/20 09:55, 57F
→
11/20 09:55,
1年前
, 58F
11/20 09:55, 58F
→
11/20 11:47,
1年前
, 59F
11/20 11:47, 59F
→
11/20 23:36,
1年前
, 60F
11/20 23:36, 60F
討論串 (同標題文章)
完整討論串 (本文為第 3 之 3 篇):