@archo Yeah but at sensible resolutions, the higher-rez textures will never be loaded. So all they're wasting is disk space and their own production time. Whereas PBR is burning my precious DRAM for minor LSB differences. Boooooo.

(I say this with honest love to all my PBR shader writers)

(it's a joke. This is a bit)

(or is it)

@TomF Texture loading time from disk and download time/bandwidth would be wasted as well, which seems relevant with modern 150 GB games. (Also not a lot of such games fit on 1 TB consoles.)

But I suspect for high res textures there could be a way to stream the biggest mips on-demand from the CDN to the GPU based on what the GPU needs which AFAIK nobody's doing yet. PBR seems uniquely disadvantaged in this regard (but at least the number of parameters doesn't seem to be growing infinitely).

@dotstdy @TomF IIRC there was also some software that used a virtual file system to download Steam game files on-demand (I forgot the name), which together with local mip streaming from separate files would work similarly.

The part I was specifically thinking nobody's done yet was detecting which mips are actually being requested by the pixel shader. It seems this wasn't mentioned in the video but I'm curious if they've been experimenting with something like that as well.

@archo @dotstdy It's called "virtual texturing" and it's been tried many ways over the years. My favourite talk is this one by Sean Barrett: https://www.youtube.com/watch?v=MejJL87yNgI

Also called "megatextures" and implemented in the "id Tech 5" engine and used in a bunch of games, most notably Rage.

I don't remember if it's persisted in newer engines like UE5. There's a certain overhead to using it, and I think most of the time analytic solutions are just as effective and cheaper e.g. https://tomforsyth1000.github.io/blog.wiki.html#%5B%5BKnowing%20which%20mipmap%20levels%20are%20needed%5D%5D

@archo @dotstdy Hardware implementations go as far back as 1998 when we showed a Permedia3 streaming a giant dataset, all demand-paged in only when the pixel shader requested the data.

The problem with all these demand-paged approaches is you get this gigantic stall in the middle of rendering your scene.

@archo @dotstdy So you need to solve this with two things:

1. have a fallback, i.e. lot the pixel shader use the mipmap level it has, not the one it wants, and fetch the desired data async.

2. predict what the shader will want and prefetch aggressively. OK, but how do you do that? You use the analytic methods. But this reduces the advantage of the pixel shader method, but the costs are still there.

@TomF @dotstdy Oh yeah I'm aware of VT, was specifically talking about detecting shader demand in the context of streaming content from the internet (not even as granularly as VT impls do it, whole mips would be fine), sorry for the confusion.

It seems as if the solutions have been implemented 90% from one end (megatextures going from disk to GPU) and 90% from the other end (mips downloaded from a CDN depending on upcoming content/possibly draw calls) but haven't seen an end-to-end solution.

@archo @dotstdy Got it. Xbox games can download in the background, and will stop if you hit a chunk that hasn't arrived yet, but doing mip-by-mip would indeed be pretty aggressive!

I bet Flight Simulator does this. It streams the entire world, so it kinda has to, right?