Tiled EXR / texture caching support?

I am bumping this thread as I believe texture caching is definitely needed in Cycles X at some point, even if it is CPU only for now.

@SteffenD I saw you kept updating your texture_cache_branch, any news as a possible merge at some point into the master ?

4 Likes

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.

4 Likes

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 :wink:

Hooo damn, sorry for mixing up your names on the forum haha, and thanks for tagging the right one :wink:

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 :slight_smile:
That’s why I proposed what I proposed, is some kind of pre-processing because it cannot be done at render time :slight_smile:

1 Like

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.

11 Likes

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.

1 Like

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 :wink:

6 Likes

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 :slight_smile:

4 Likes

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 :slight_smile:

2 Likes

I hope I can find the time to continue this work. Merging this with Cycles-X is a bit of work, but not impossible.

18 Likes

This would catapult rendering in Blender to the next level :heart_eyes:

1 Like

That would be amazing, and a big step for Blender.

Did you find any solutions regarding the gpu support of this feature ?

1 Like

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.

11 Likes

Well, this is still fantastic news. We are seeing the light at the end of the tunnel :wink:

Thanks a lot Stefan, hope you can find some time to work on this.

1 Like

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.

2 Likes

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.

7 Likes