Yep, I agree with this, this is super important to be as efficient as possible with memory.
One solution for GPUâs could be to generate and cache the .tx files in the same folder as the textures and then use those based on distance from camera, size on render and occlussion.
Not sure if it could be possible without a pre-process per frame.
It is already what OIIO is doing. Except this part of OIIO doesnât support gpu properly ? The texture lookup is CPU based I believe. Steffen will be more trustworthy than me to explain why the current solution is not very GPU friendly hehe.
Sorry, but Iâm not the maintainer of the branch. Similar name but the guy who does this is @StefanW 
Hooo damn, sorry for mixing up your names on the forum haha, and thanks for tagging the right one
Yep, @StefanW already explained the problem in a previous post.
The current difference with what Iâm saying is that the GPU cannot dynamically load the different textures (more or less) so it cannot leverage the current implementation, this is an approximate explanation of what I understand what the problem with this is 
Thatâs why I proposed what I proposed, is some kind of pre-processing because it cannot be done at render time
The Cycles_Texture_Cache branch uses a rather sophisticated method for texture caching just like the commercial renderers Iâve been using so far. They convert the textures from all sorts of formats (8-bit, 16-bit, JPEGs, PNGs, TGAs, TIFFs, EXRs, ⌠you name it) to an image format that supports mip-mapping and tiling.
One of the readily available open source tools for this is e.g. maketx from the OIIO library.
Mip-mapping means that after the conversion the image file contains a sequence of scaled down versions of itself. In case of a 2k square texture this means that it also contains these mip-map levels:
2048x2048 1024x1024 512x512 256x256 128x128 64x64 32x32 16x16 8x8 4x4 2x2 1x1
These are accessible without having to load the whole image file. The smaller the texture is in the rendered result (e.g. because itâs farther away from the camera) the smaller the mip-map level thatâs actually loaded can be. This way an 8k texture might only weigh in like a 512px texture and consume a lot less memory.
Tiled images have another advantage: During conversion theyâre split into square âtilesâ that can also be separately accessed by the loader. In the default case of maketx these tiles are 64x64 pixels in size.
If e.g. only a part of a texture is visible in the rendered image, only these tiles need to be loaded and stored in memory.
Mip-mapping and tiling in combination can allow you to render scenes with terabytes of textures on a machine with a lot less RAM. Depending on the implementation of the texture cache, the parts of the textures that are currently in use can be swapped in and out of memory dynamically.
Iâm not a software developer myself but all of this doesnât only sound complicated, it for sure is not a trivial task to build into a renderer properly.
Luxcore or rather its Blender integration BlendLuxCore have added a very clever and neat method for texture scaling thatâs not quite as elaborate as the one just described: Itâs also pre-converting the textures to mip-mapped versions and only loads the needed sizes. It doesnât support tiling or dynamic swapping as far as I know, but it can help a lot in scenes with many and/or big textures.
Hereâs a thread in their forums about this Scene texture maps resize policy - LuxCoreRender Forums
Itâs already ready to test in the latest Alpha builds and works quite well, without the need for the renderer to support all that complex mip-map / tiling stuff.
If I get it right no special changes had to be made to LuxCore (the renderer itself) to support this. Maybe this could be a (preliminary?) solution for Cycles as well.
This is the way. This method is production proven by the industry in a certain renderer that is named after Schwarzenegger.
I used it a lot in the past and the difference in render times and also memory efficiency using many big sized textures was amazing.
In a perfect world this would be the best solution, yes. Stefanâs texture cache implementation already works very very well. but its main hurdle is GPU support which is not that easy to solve AFAIK.
The solution BlendLuxCore has implemented has the big advantage that it doesnât need any changes from the rendererâs side but only in the way the textures are prepared before being sent to the renderer. It works with CPU and GPU out of the box.
Is this solution being considered by the branch developer?
I donât know but I guess not. He developed a full blown texture cache solution for CPU rendering and I hope he will find time and motivation to develop this further so it can be integrated into master. But no info on that at all on my side.
We will have to wait for him to maybe answer this thread. Fingers crossed
I was looking at this with interest I noticed that it is not merged with the new cycles-x master which could be a lot of work as there has been significant changes. Is work still continuing on this? If it is I will certainly try to get it considered
Youâd need to ask @StefanW for further info.
I hope that this will be developed further and one day be merged in master, too
I hope I can find the time to continue this work. Merging this with Cycles-X is a bit of work, but not impossible.
This would catapult rendering in Blender to the next level 
That would be amazing, and a big step for Blender.
Did you find any solutions regarding the gpu support of this feature ?
Nvidia has some sample code in their latest Optix SDK that should help, it implements at least parts of whatâs necessary. I have not tried it out yet, I only saw the documentation for it. Getting this to work on GPUs from other vendors will be the real challenge after that.
Well, this is still fantastic news. We are seeing the light at the end of the tunnel
Thanks a lot Stefan, hope you can find some time to work on this.
On the other vendor side AMD has HIP which is similar to CUDA by design and those code paths are now very similar in Blender 3.0. In fact the CUDA/HIP path should be similar to the CPU version. Ideally we want all these vendors to use essentially the same or similar code.
Late to the party, but hoping that there is some progress on the GPU side of texture caching support. This type of progression feels in line with the Blender 3.X/Cycles X direction of optimizing Blender/Cycles for production work if you can get texture caching on GPU functional (fully acknowledging the technical task I imagine is involved so I know weâll have to have patience as other priorities exist). The memory savings would certainly benefit all users, especially those who have smaller GPUâs in the 4-8GB range where saving a few GBâs on textures is a huge deal. Major kudos to @StefanW for even keeping this on his radar to the extent that he can.
Hey @StefanW - is this still being worked on? I couldnât find this in the new development system, so am curious about the state of affairs.