BUG REPORT - iray texture memory consumption (ticket 248829, status SOLVED)
Padone
Posts: 3,789
I filed a ticket to the Helpdesk and I'll let you know of any news.
DS 4.9.4.117 pro, nVidia driver 382.53, Windows 8.1 x64
The texture memory consumption reported in the log is wrong. I'm pretty sure the bug is it counts the textures multiple times even if they are used once. But please verify it.
steps to reproduce the bug:
1) Load G3F and render with iray. The log reports "Texture memory consumption: 354.251 MiB". That seems good you can verify it with the GPU-Z free utility to monitor the card.
2) Now load another two G3Fs so to have three of them on the scene. The texture memory consumption must be the same since the textures are shared. You can also verify that with GPU-Z. Nevertheless the log reports "Texture memory consumption: 1.03784 GiB". So it seems to me it counts the textures three times even if they are used once.
Having a good measure of texture memory is essential in production to plan the scenes so that they can fit the card. Without a good measure you never know if the scene will render or will roll-back to CPU. So please fix it.
Daz 3D is part of 
Connect
DAZ Productions, Inc.
7533 S Center View Ct #4664
West Jordan, UT 84084
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2025 Daz Productions Inc. All Rights Reserved.
Comments
As far as I am aware the memory reports are coming from Iray, not generated by DS.
I imagine the reply to your ticket will come back as "working as designed." The number reported by Iray is for uncompressed textures. Iray compresses textures on-the-fly according to the rendering settings you've made, and this process is wholly outside D|S. The number Iray provides is useful so you can consider methods to manually reduce texture memory consumption, such as removing textures when a procedural shader works just as well, or reducing texture size for assets that don't need the resolution, or reducing bit depth (e.g. using 8-bit image files versus 16) and eliminating any trasnsparency channel.
@Richard
Yes may be it's a bug in iray rather than DS. I just hope it's not so they could fix it.
I guess DS asks to iray the wrong way. That is, it asks for every texture it finds on the scene, even repeated textures, then sum up. This is wrong. You have to check first which textures are unique from the file name, then ask to iray only them, then sum up. But this is just a guess that's why I ask them to verify.
@Tobor
I have to disagree about them being uncompressed values. As I said in my example if you use three G3Fs you should get the same memory size as one G3F, since textures are shared. This is true both for compressed and uncompressed textures.
Not necessarily. There may be more than one "instance" of the map in memory. I'm not in fromt of a DAZ box at the moment, but I believe there is a setting for this (memory vs. speed).
- Greg
@algovincian
If you are referring to the "instancing optimization" in the iray render settings, then this is for geometry instancing not for textures. Textures are always shared, it would not make really sense for the render engine to duplicate them. While instanced geometry may be duplicated or "baked" so to avoid computation at the cost of memory. This is what the iray option does.
My bad - been a little brain-dead lately . . .
- Greg
I agreee with you that the value is displaying combined memory usage for textures that may be instanced in memory once Iray processing begins (as can be demonstrated in a GPU utility) , but nevertheless, the value is "raw" and does not take into account any optimization that may be taking place. The value shown is from the Iray scene database collector, a process separate from actual rendering. I doubt that the value Iray is reporting for texture consumption is incorrect; it's simply not the value you are expecting.
As Richard notes, this value comes from Iray itself. It's one of the many callback messages Iray sends during processing. D|S has no control over the content of these messages, as Iray is something of a black box in this regard.
Whether or not nVidia would consider revising what the number indicates would depend on their original intent. I believe it was done this way as a general indicator of optimization. A GPU utility will show how much actual memory is being consumed, and this comes within 10-15 seconds of these other callback messages. It's not like you're left in the dark. Perhaps the number shown is specifically for the benefit of indicating how much optimization is being performed.
did you restart studio inbetween checking...
I run gpu shark on another monitor..
and dazs communication with iray does not remove textures at the end of a render... sends them over again ... render a scene a few times and you'll end on the cpus.. which can be drag unless you're you've got something locking on to studio so it's cpu usage is limited...
@Tobor
If for "raw value" you mean the sum of all the textures in the scene, even when obviously repeated such as the same texture in two different materials and/or objects, then I agree with you this seems to be the value reported in the log. As for it being a "correct value" I strongly disagree. The textures are shared. This is normal behaviour from OpenGL to 3Delight to iRay. This has nothing to do with compression or optimizations.
As for DS having no control over these values, it may be. I just hope it's not so they can fix it. But to be honest I doubt there could be such a bug in iray. It's more likely that DS is just adding up wrong as I explained before. I apologize I'm becoming repetitive here ..
@Alan
Yes iRay is lazy with the card memory so measures are not precise and restarting DS may help. Nonetheless you can tell the difference between 350M and 1G as in my example so the "gross weight" is there.
Anyway I don't have your behaviour here. I can render the same scene and/or different scenes as many times as I wish without restarting DS, provided they fit the card. No cpu reversing.
As Richard and I have noted, D|S isn't providing these calculations. It is echoing strings of text received by the Iray database layer API.
Regardless of whether it's something Daz can change, I'm still questioning the importance of it. The log is meant as an advisory, the same as the sensor data from GPU-Z. You're getting two pieces of useful information: memory footprint as defined by the scene graph, and actual memory allocated to VRAM. That these values are different, and by the degree of their difference, is itself helpful information you can use to your advantage. This would be particularly true as Iray is capable of altering scene components on-the-fly for interactive rendering, making memory consumption values dynamic, It could also be beneficial information in cluster-based workflows.
In any case, please let us know the results of the your support ticket. This type of information benefits us all in the better understanding of maximizing D|S and Iray.
UPDATE: here is the reply by Ryan Wilburn and my reply below
Ryan Wilburn Yesterday at 22:26
Hey Alessandro,
While I do understand your line of thinking in the matter (354.251 MiB for three identical figures instead of 1.03784 GiB), this is unfortunately not the case. If you load three figures into a scene, regardless of similarities or shared textures, three separate instances of a character must be loaded with three separate instances of files for said characters.
I have filed a feature request for this, however, and passed this request along to our Dev team. Unfortunately, I cannot guarantee whether or not this feature will be implemented - as the Dev team has final say and I am not involved in these discussions. I would suggest keeping an eye on the forums for any updates regarding this.
Please let me know if I may offer any further assistance.
Thank you,
Ryan
Alessandro Padovani Today at 15:21
Obviously you didn't check the procedure to reproduce the bug. It's not "my line of thinking", it's what's reported by gpu-z.
When you load the same character multiple times on the scene I agree with you that the geometry is duplicated, but the textures are always shared. Again, you can verify it with any gpu utility. I'm not asking you to believe me, I'm just asking to check before replying otherwise.
For example, I reported below the values you get with 1x G3F and 10x G3F on the scene
1x G3F
log: 354 Mb texture, 13.7 Mb geometry
gpu-z: 207 Mb overall
10x G3F
log: 3.46 Gb texture, 137 Mb geometry
gpu-z: 385 Mb overall
Furthermore, I believe the log counts the same texture multiple times even if it is used in the same figure for multiple materials. For example the G3F uses the same diffuse texture for face, lips, eyesocket and ears. If I leave the diffuse texture only on the face I get a different log.
1x G3F
log: 324 Mb texture, 13.7 Mb geometry
gpu-z: 207 Mb overall
UPDATE: another reply .. I'm not going on with this since it's clear to me it would be useless. Also they changed the status to SOLVED. At least it's been reported so may be there's hope.
Ryan Wilburn Today at 17:58
Hey Alessandro,
I did attempt this on my end and I was unable to replicate your results. Regardless of this, a feature request has been filed and this matter is now out of my hands. Please be sure to keep an eye on the forums for announcements or any information regarding this in matter in the future.
Thank you,
Ryan