Trouble with DS connecting to GPU
jaebea
Posts: 454
This problem just started. I have been using the 4.9 Beta (not RC). When I render, sometimes IRAY will connect to the GPU and sometimes it ignores it and just uses the CPU. Yes, I can the box checked for GPU ONLY. I want my CPU freed up to do other things. I got a GPU meter to confirm what I was seeing and it's true. I have a GTX970. It works fine in 4.8, but of course it's slower. Anyone else had this problem?
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
Are your drivers up to date?
What about scene size? Do you have something to check the amount of video card memory being used? What does the Studio log file say (Help > Troubleshooting > View Log File)?
It's not running out of RAM?
I read your responses and did some testing last night. I started with a simple scene...a photo background, a g3 with hair and a dress. Video card did just fine. Stepped it up with some of the scenes in the animation I'm working on. GPU rendered them before and rendered them now. Then I brought in the scene I have been working on.....Blooming Alley. Fully loaded up with all the trees and shrubs is so memory intensive, it chokes my 16g of ram. I can hardly move anything because it drags so much. Fully loaded, my GPU won't render it. But after I try, my GPU won't render anything and I have to completely reboot the computer. I wanted to put 2 people in that scene but that's not going to work. Will have to do some work-arounds I had no idea that a heavy-laden scene would overwhelm the GPU.
Yes, after the GPU runs out of RAM it won't be used again in that session - though I thought restarting DS was all that was needed in most cases.
Most scenes 'weight' comes from large textures. Look at the elements of that scene, and see what textures you can resample (in an image editing program) down to a lower size to save on memory. If something is far away, or out-of-focus, or small in the scene, it doesn't need 4k x 4k textures. Heck, it probably doesn't need 1k x 1k size.
I wish DS had a mechanism to use multiple textures for the various channels in a surface, and select between them with a single 'detail level'.....or would auto-create mipmaps from loaded textures and scale them appropriately to a 'detail level' parameter on each surface. It would make it a lot easier to tweak scene sizes to better fit within video memory.....
I did restart DS and load up a file to render but GPU was done with it. That was when I just rebooted the computer. Thank you hphoenix for the suggestion. I am pretty sure the texture on these plants are very large. I will at that option as I am deciding what I want to do with it.
I've had this happen a couple of times. I am pretty sure though that the first time it happened was well before I started using the beta so I don't think it is necessarily related to that. I think I had to reboot to clear it but I won't swear to that. I've had several programs that needed a reboot to start if I had left the computer running too long (read days not hours) so I thought it might have something to do with that. My mother board went belly up this week and I have no idea if it is related or no.
It does for 3Delight...and is supposed to do some sort of compression in Iray, but there are problems with some 'detail' maps (norma/bump/displacement) being compressed.
Iray textures on board the VRAM are compressed (using nVidia's internal compression) but even compressed, the textures still are the largest memory consumer in the VRAM. To wit:
A 1k x 1k 24-bit image (uncompressed) will take up about 4MB of memory (RGBA*1M). A 4k x 4k image takes up 64MB of VRAM. Consider a figure that uses four 4k x 4k textures (color, specular, bump, transparency), even letting the last two be greyscale images (so they are only 16MB each) that's 64+64+16+16 = 160MB.
That means you can't have more than about 10 of those figures (with included geometry, frame buffers, shaders, and including compression) and have it fit in a 2GB VRAM space.
Add in a large HDRI IBL texture, some props or clothes, and you quickly drop what the card can hold before running out of memory.
Now, at 1k x 1k, you could have 160 of those same figures. And as long as the camera is never doing a close up shot, you won't be able to tell. So adding in the rest of the stuff, you could still easily fit quite a complicated scene into VRAM.
I think the various vendors (and DAZ itself) need to start packaging up Iray materials with presets for low, medium, and high-resolution textures. So that when we apply the presets, it uses the correct resolution images. It would allow us to better control our VRAM usage....and only use really detailed textures where we NEED them.
Actually it's a bit worse than that...because Iray uses about the same amount of memory per image whether it's color or greyscale. And it seems that for many items, there are 5 maps...normal map, too.
On the down side of having high, mid and low is that you are now going to bump up the download size immensely.
So 3 versions of every texture included in a set and 3 different mat files or shader presets? The first issue with that is file bloat and the second issue is the price increases. Which everyone would have to deal with even if they were never going to do huge scenes. I've never had a scene yet exceed my card and I regularly use some pretty large sets. If I have ever had trouble with anything it is with older products that had textures that were just to small to look good in Iray.
I would be willing to buy a DAZ Script that resizes textures. I know I'm capable of doing it myself in an external program, but having an interactive script within DS would be a nice workflow aid.
Actually, it wouldn't increase the download size as much as you'd think. As the majority of most download packages are the image files, and they are usually the largest sizes already. So 1/4 and 1/16 additional per image (so a 4k image now also includes a 2k and a 1k) adds only 31.25% if uncompressed. So a 100MB download would become AT MOST, 132MB. Not a huge bump.
Additional cost would be strange, as resizing images and making a copy of a material preset with the new sized images wouldn't be very much additional effort. It could probably even be automated with a script/plugin as long as the naming conventions were followed.
As for texture sizes in Shaders, that can be a whole different matter. Depending on a LOT of factors, those may require large sizes to have any resemblence of quality to them. But textures for characters, props, and such often do not require such high resolution.
It would be nice if DS would auto-resize them on the fly, depending on the ratio of render resolution to area occupied for a given node. But that's a somewhat complicated factor, and would require overrides and such.
But as a lot of people aren't really gurus with Iray and Daz, they may not realize that what the objects they are loading use by default are so large (memory wise) or know how to re-size/re-name/re-texture and then wonder why the render is so slow (or craps out completely.)
Resizing the images and making the presets might not be much effort, but testing them all might be.
Not very much addional effort is not the same as no effort and time spent is time spent. Not to mention if it were done for Iray then files would also need to be done for 3dl if the product includes support for it. Plus all the testing time which would be trippled as far as testing the surface stuff. Now if its a product that is kept small it might not be a thing. But most PA's shoot for more bang for your buck as far as content.
Doing it for shaders would be madness. My last shader set had had over 200 presets and 37 maps. And that was on a set that used a low volume of maps. I'm not alone in large sets either.
I guess I just don't see the point since Iray already has texture compression.
No, it wouldn't need to be done for 3DL, because mipmapped textures are already made at render time. so it isn't a problem. That's what tdlmake is doing when it is spending all that time 'optimizing textures'.
And Iray's compression is more or less an all or nothing one...it does it but not based on closeness to the camera or anything (at least that's what it looks like to me). You set the compression level globally...and that's when you start running into problems with things like normal maps.
The best solution would be a scripted one that mimics the behavior of 3Delight's tdlmake (although I don't know if Iray can use mipmapped images...so another script to make the 'detail' decision would probably need to be included).
I wish Iray could handle ptex. We would not need all those texture files to get a great render. I ptex file vs. 1 texture plus bump, plus normal map, plus specular and on and on.
Right...double posted.
Umm...3Delight, in Studio has had p-tex for a while now, but there doesn't seem to be anything available that actually uses it, so what difference would it actually make if Iray could use it?