It doesn't need to be - consoles have been at the forefront of adopting non-standard data layouts for - basically their entire existence - that used to be one of the defining advantages of the medium over PCs in particular.
And yes we lost that edge somewhere along the way, but nothing says it can't be revitalised if something truly game changing was available.
That being said - people grossly overestimate the impact of texture compression - from NVidia's own work at best we're talking a 2-3x improvement to the traditional pipeline when fine-tuned optimisations are used on both sides (not just on one to make the other look good/bad). Which don't get me wrong - is meaningful - but it's not going to turn 300GB games into 50GB. You might get 200GB, on a good day.
Eh - again not the first time we've seen consoles do something like this. Hell even going back as far as PS1 - it was the consoles that first introduced concept of compressed data on discs that was runtime unpacked (not by some installer process), saving memory and improving load-times in the process. Not to even mention the crazy lossy packing used to fit things onto N64 carts, or even older 2d era hardware.
But again, I just don't think this is the magic bullet nearly as much as GPU corpos want you to believe.
I think we agree in principle. The reason I brought up the launch window was because we were talking about a reduction in SSD requirements. And if that doesn't happen across the board at launch, Pro users will likely have to downsize the number of games they maintained prior to the PS6.
Like you said, there is a lot of exaggeration and marketing fluff over the gains achieved. They are often ignoring the additional gain Oodle already brings to BCn, at least from a storage standpoint. And devs aren't going to rush to overhaul their pipeline over 2-3x gains. It can take over a minute to train these MLPs to compensate for any perceivable loss in detail. Per texture! Until that training time comes drastically down, or the workflow changes to accommodate that latency, realtime editing and previewing becomes a pain.
NTBC might be the easy button here, as they can use BC textures during dev till the very end before a final neural training and compression pass for game builds. Just like Oodle. But i feel there are still some dev training/comfort level roadblocks and performance unknowns that may affect early adoption. But all the gains in VRAM bandwidth are out the window along with building really complex materials that can't be reasonably achieved with BC. So I'm still not sure to what extent a halfway solution like that will take hold.
But since NTC will objectively be better in the near future on all fronts, I do see it pushing other standards gradually into obsolescence in the long run. In our land of diminishing returns, even 2-3x is too good to ignore. It's no magic bullet for sure. Just one more thing that replaces the old thing eventually.
Thanks for explaining it to me. I just don't understand that part :
I thought PS5 I/O could only get the data to vram. So it must get there before the GPU does anything to it, right? But yes you are right using Oodle in any part of that pipeline seems useless, even if that was possible.
My main problem with NTC / NTBC is the performance cost of doing it during gameplay which was the whole point of PS5 I/O complex: loading and uncompressing assets without any CPU or GPU performance cost. But here we are talking about doing inference in real-time, which could be done on PC powerful GPUs, but not sure how it would impact performance on much weaker console GPUs.
I think I overly simplified that part and misstated it as a result. Good catch. The data would go to the RAM first. Then picked up for inference during level load (or load initiated by the level streaming system) and then transcoded to BC before storing again in RAM for the remainder of its time in memory. As you can tell, that's an additional hop and has no gains on VRAM bandwidth or usage. It's a slight loss actually, but with the benefit of lowered SSD storage requirements and using standard BC in memory during gameplay i.e no bleeding edge filtering solutions needed.
But here we are talking about doing inference in real-time, which could be done on PC powerful GPUs, but not sure how it would impact performance on much weaker console GPUs.
This is where cooperative vectors and neural arrays come into play. The current PS5 pro AI cores are only used less than 10% of the frame time for PSSR. The rest of the time, it's just idling. It's the case in the PC space as well. AI cores have been heavily overprovisioned as there's no other way to get good performance during the upscaling stage. And register pressure and L1 stalls has really held back to what extent neural rendering becomes mainstream even in the PC space, where Nvidia and Intel already support cooperative vectors.
All of this, at least on paper, will change in the next few years. It actually seems like Neural Arrays will be more capable than Blackwell Tensor cores, as it has its own dedicated interconnect that's faster than L1 and a shared scratchpad memory that can dramatically reduce contention for registers. They can effectively run as a cluster to execute larger, more complex models. And it allows the AI cores to run in parallel
throughout the frame time while the shader cores perform traditional render tasks, which mean all these additional neural rendering techniques can be added on with minimal overhead.
Inference on load has no performance cost, but it only reduces texture size on disk.
Technically, the inference itself still has a performance cost. It's just much smaller as it doesn't have to keep repeating it again. And then everything else would work just the way it always did, post-inference.
Most likely we will only see Inference on load this generation.
Why though? If Ubisoft could already roll out their (smarter imo) version of Inference on sampling in a reasonably sized game, I don't see why inference on sampling will not be adopted across the board mid-gen, especially with the new architecture that would effectively negate or trivialize the performance cost.
.
.
.
. Keep sending interesting links 
