@MrFox Until we see what some virtual texture steaming systems look like, it's going to be really hard to know. It does seem like partially resident solutions will become more of the norm if games engines start using 8k textures. It just doesn't make sense to do anything other than tiles/mip-regions otherwise RAM requirements will explode.
Current Generation Hardware Speculation with a Technical Spin [post GDC 2020] [XBSX, PS5]
- Thread starter Proelite
- Start date
- Status
I think 16 GBs + SSD ensures everything will be streamed as much as possible. The games that stream best will be the best looking by far.
It'll be interesting to see exactly how BCPACK works. Is it just RDO + some other form of compression? Or is it an entirely different and lossless approach? If it's lossless then that'll make for some interesting comparisons since if the PS5 I/O bandwidth figure is based on using RDO (and my money is on that being true) then the result would be higher quality textures on the XSX vs the PS5 when utilising that kind of throughput. Given the crazy high compression ratio's Microsoft are claiming though then it seems unlikely that it's entirely lossless.
That would also have interesting implications for the PC which if the above holds true would mean that PC games not using texture compression (on top of BCn) in order to save CPU time would at least enjoy higher quality textures, even if that is only a minor consolation at the cost of less effective IO bandwidth use and larger install sizes.
But then we have BC7prep which opens up a really interesting possibility... Not from BC7prep itself (which is great, but applicable to all platforms equally), but from what it shows is possible, i.e. realtime async GPU based texture decompression on the compute cores.
If that's possible for BC7prep than why not for BCPACK? I imagine the computational requirements could be quite different, but based on the figures above BC7prep takes around 1TF for 6-12GB/s of data, and we also have Microsoft's comparison of 3 Zen2 cores for 2.4GB/s of BCPACK. I don't really have any idea how they calculate that requirement or how it would translate into a GPU requirement, but if it's using AVX256 as the basis then 3x Zen2 cores at 3.6Ghz = 384 GLFOPS which comes in at 960 GFLOPS for 6GB/s, or very much in line with the BC7prep requirements.
So this does open the tantalizing possibility of using BCPACK in the PC space utilizing GPU decompression which might be relatively lightweight and widely supported. And the result of that would be not only the storage space savings, but also 2x the IO throughput vs the drives base speed assuming the non-texture data was still decompressed on the CPU (now a much cheaper and more manageable operation). 14GB/s I/O by the end of this year here we come?
That would also have interesting implications for the PC which if the above holds true would mean that PC games not using texture compression (on top of BCn) in order to save CPU time would at least enjoy higher quality textures, even if that is only a minor consolation at the cost of less effective IO bandwidth use and larger install sizes.
But then we have BC7prep which opens up a really interesting possibility... Not from BC7prep itself (which is great, but applicable to all platforms equally), but from what it shows is possible, i.e. realtime async GPU based texture decompression on the compute cores.
If that's possible for BC7prep than why not for BCPACK? I imagine the computational requirements could be quite different, but based on the figures above BC7prep takes around 1TF for 6-12GB/s of data, and we also have Microsoft's comparison of 3 Zen2 cores for 2.4GB/s of BCPACK. I don't really have any idea how they calculate that requirement or how it would translate into a GPU requirement, but if it's using AVX256 as the basis then 3x Zen2 cores at 3.6Ghz = 384 GLFOPS which comes in at 960 GFLOPS for 6GB/s, or very much in line with the BC7prep requirements.
So this does open the tantalizing possibility of using BCPACK in the PC space utilizing GPU decompression which might be relatively lightweight and widely supported. And the result of that would be not only the storage space savings, but also 2x the IO throughput vs the drives base speed assuming the non-texture data was still decompressed on the CPU (now a much cheaper and more manageable operation). 14GB/s I/O by the end of this year here we come?
I think in the next gen more than ever, art will be more and more the defining aspect of what a game looks like. I think in the current gen we can still “blame” some technical limitations here and there, but the more we progress and the more these limitations go away, the best looking games will be the ones that have the most resources thrown at artists instead, which is a great place to be.
@pjbliverpool Have their been any details on BCPack yet?
I think this has been the case for a while now. You can hit all of the tech checklist items, but it doesn't mean your game will look good. I think you're right that it'll be increasingly true as the cost of games goes up and up. There will be very few that can afford the working hours it takes to create the top end games.
Yes I agree. Even now it’s obvious that the most impressive games are the ones with the budget and manpower to allow for a certain vision to come alive.
And yet there have been some gems that came from indie, lower budget studios, and I think we could see some very nice surprises in this coming gen.
Not every game needs GOW kind of production values, and I for one am excited to see what small indie developers can do with smaller games using RT effects, fast streaming and the huge CPU power we now have. Heck, I played the heck out of Dead Cells, still do.
Exciting times!
Not that I'm aware of other than what Microsoft told us at the XSX reveal.
Silent_Buddha
Legend
Unfortunately, better art assets require more time. You can reduce that with more artists, of course. But the end result will still be a large increase in the cost of a project.
Some form of hybrid RT might reduce costs on the lighting side, but if a project is going to take full advantage of SSD and much greater asset variety and fidelity, that's going to cost way more than any cost savings on lighting.
Heck, we already see studios that struggle to maintain consistent art asset quality on the current gen (FF7R, for example). The next gen is going to see that balloon significantly.
We may see a move to more procedural generation of assets, but that has its own pitfalls and problems.
Regards,
SB
I think using UE4 with Quixel Megascans is the answer to cost efficient next gen asset creation for a great amount of devs big and small. You get over 10,000 of high quality scanned assets captured from all over the world with new ones rolling in everyday. I'm not saying it'll cover the entirety of asset creation pipeline but a good chunk of it would be, then you just build your unique assets on top of them. Next gen hardware are strong enough to render and stream those LOD0 models on the fly as it is so breaking them down to multiple LODs would be minimized by heaps.
Yeah but not all games need photoreal graphics, in fact I'd say most games do not have them not because of tech constrains but simply because it isn't part of the artists' vision for the game.
"You have to understand that this famous SSD has a speed comparable to that of the PS4’s RAM, which is just incredible!"
Credibility reset to zero...
Maybe he meant PS3? Or just a typo? Surely a developer knows this sort of stuff?
Maybe a typo and he was thinking PS3... At least on GPU side the memory bandwidth theorical maximum is comparable 22 GB/s for PS5 SSD and 22,4 GB/s for RSX to VRAM.
Even then, the latency is 3 orders of magnitude lower for DRAM vs NVMe. They simply aren't comparable.
PS3's ram probably also maintained that 22gb/s figure more often then the PS5's ssd, which most likely almost never will, between 5 and 9gb/s, perhaps, seems more realistic.
But this is the storage. I think he speaks mostly about bandwith. He never talks about latency. He never said SSD replace RAM just than the bandwidth is impressive. What many developers seems to told, this is than for being rendered an asset need to be in RAM and it was difficult to have high quality in RAM because of slow HDD.
https://cbloomrants.blogspot.com/2020/06/oodle-texture-slashes-game-sizes.html
This is a game data test from a 2019 games and probably a best case utilisation but here for this set of texture the speed reach 17.4 GB/s. This is compression it will vary from games to games but maybe Mark Cerny and Sony engineering teams did not overengineered the data decompressor.
If it is a Sony game, I suppose this is Days Gone.
Last edited:
- Status
Similar threads
- Locked
