GPU - Max Texture Resolution

[am_wilkins]

Hello,

I was doing some testing with the "GPU Settings - Max Texture Resolution" and noticed it wasn't doing anything. Maybe I'm misunderstanding it's purpose but I thought it would be able to "clamp" the texture resolution at a certain maximum like 128, 515, 1k for example. So the pre-existing TX files would only use those mip-map levels.

Sort of like a global Mip-Map bias which I see is not supported on the GPU.

In the render tests with around 890 image files, I tried various Max Texture Res settings and the texture VRAM amount nor visual quality of the render didn't change at all.

Test_01 - 0 Max Texture Res (Mostly 1k textures)
R8147| 00:09:34 13041MB | texture cache 4588.98MB
R8218| 00:09:35 13041MB | ImageInputs : 886 created, 795 current, 795 peak
R8219| 00:09:35 13041MB | Total pixel data size of all images referenced : 10.6 GB
R8220| 00:09:35 13041MB | Total actual file size of all images referenced : 2.3 GB
R8221| 00:09:35 13041MB | Pixel data read : 3.3 GB

Test_02 - 512 Max Texture Res

R8296| 00:09:25 13028MB | texture cache 4596.98MB
R8367| 00:09:25 13028MB | ImageInputs : 886 created, 795 current, 795 peak
R8368| 00:09:25 13028MB | Total pixel data size of all images referenced : 10.6 GB
R8369| 00:09:25 13028MB | Total actual file size of all images referenced : 2.3 GB
R8370| 00:09:25 13028MB | Pixel data read : 3.3 GB

Test_03 - 128 Max Texture Res

R8456| 00:07:52 13104MB | texture cache 4586.98MB

R8527| 00:07:52 13105MB | ImageInputs : 886 created, 795 current, 795 peak
R8528| 00:07:52 13105MB | Total pixel data size of all images referenced : 10.6 GB
R8529| 00:07:52 13105MB | Total actual file size of all images referenced : 2.3 GB
R8530| 00:07:52 13105MB | Pixel data read : 3.3 GB

Is the render setting perhaps not working?
Or do TX files need to be re-created with this setting adjusted to set the upper limit of mip-map levels?

all the best,
amwilkins

--

Houdini Core Version 20.5.410
Arnold Core: 7.3.6.0

HotA: 6.3.6.0

CPU: AMD Ryzen TR 3990x / 3970x

RAM: 128GB
GPU: NVIDIA RTX 4090 / RTX A4000
OS: Windows/Linux

[thiago.ize]

You're right, it does appear to no longer be working. I've logged this with the internal ticket ARNOLD-16272 for fixing this. Thanks for reporting this bug.

[am_wilkins]

Okay, thank you Thiago.

[thiago.ize]

The just released 7.4.3.0 arnold core has removed this parameter:

• Removed options.gpu_max_texture_resolution parameter: The GPU maximum texture resolution feature was removed in a previous version of Arnold, so the parameter no longer did anything. (ARNOLD-16272)

[RGhost77]

... and sadly broke MAXtoA 5.8.3.0 by not remove this parameter from UI. 😞
GPU rendering stops with :
[MAXtoA]: Failed to set parameter 'gpu_max_texture_resolution' of type 01 on node 'options'.

[Stephen.Blair]

I'm not getting any errors or messages like that in 3ds Max 2026.1 and MAXtoA 5.8.3

In 3ds Max 2025, I get the maxtoa error message during scene export, but that doesn't stop the render and the output is rendered out.

[RGhost77]

@Stephen.Blair You right, my bad. Another error stops render in my case. 

[am_wilkins]

Thank you for the update!

Out of interest, why was the feature removed?
I hadn't attempted to use until we got deeper into GPU testing, but wouldn't it have assisted in cases where perhaps a scene is running out of memory and this could globally cut back on some of the texture cache memory?

[thiago.ize]

Yes, that would be one way to lower memory usage, at the cost of blurrier textures. Arnold is already picking the lowest res texture mipmap that won't look blurry, so using this to lower memory would for sure make the rendered textures look blurrier. If that really is a worthwhile tradeoff, you can still adjust the mipmap bias for certain textures for which you think the blur would be less objectionable. If you want it all to be blurrier, you can also lower the options.texture_max_sharpen which will make everything uniformly blurrier.

We removed this option because it hadn't been used by anyone in a long time (no one reported it broken, even though it was). Whenever possible, we prefer a simpler to use renderer with fewer options.

[am_wilkins]

Okay thanks for the info Thiago, that makes sense.