What do these IRAY log errors mean?
grinch2901
Posts: 1,246
I've noticed a slowdown in my render speeds and so I checked the log file to see if anything is amiss like I'm sonehow not getting GPU engaged or something. I saw two errors coming up consistently but hadn't seen them before. They are:
WARNING: dzneuraymgr.cpp(261): Iray ERROR - module:category(IRAY:RENDER): 1.0 IRAY rend error: Degraining filter cannot be combined with "black pixel filter".
and
Iray INFO - module:category(IRAY:RENDER): 1.10 IRAY rend info : CUDA device 0 (GeForce GT 750M): Prevent device timeout
Iray INFO - module:category(IRAY:RENDER): 1.15 IRAY rend info : CUDA device 0 (GeForce GT 750M): Prevented device timeout
What do these mean and is there something I need to fix?
Daz 3D is part of 
Connect
DAZ Productions, Inc.
224 S 200 W, Suite #250
Salt Lake City, UT 84101
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
For what it's worth I reset my render settings to default and the render times came back to normal for my somewhat modest machine. All those odd errors disappeared. So I beleive some combination of render settings filters was confusing the renderer somehow. I'd still like to know what. Typically I use the firefly and pixel filters at default but recently I've been playing with Bloom and Crush Blacks. Could be some combination makes Iray say "foul".
From my experience:
The timeout INFO messages are normal. It just says that the GPU prevented the typical 2 (or 5) second watchdog timeout. If it didn't do this, your OS might think the graphics card stalled. You'd get an error, and would likely cause a forced shutdown of D|S.
WARNINGs are non-fatal messages that indicate some render issue, like what you found with combining certain filters. Usually the render continues with the feature set is can. Perhaps D|S shouldn't allow incompatible features to be combined, but this is, after all, the first public version of the program with Iray. These are the types of things I'm sure they'll add as time goes by.
ERRORs are fatal messages that cause Iray to stop in one or more devices. They can happen in the GPU, in which case Iray will attempt to render the scene in the CPU. If that doesn't work, the render stops completely.
By "fatal," it doesn't really mean a crash in the program or system, just that Iray can't go on -- for example, if your card had the wrong drivers and didn't support Iray. You'd get an ERROR message saying the version of CUDA or the compute level was too low, that sort of thing.
Well the first one is a WARNING that an ERROR happened but the render continued, albeit slowly. So Iray continues to surprise!
Seems like a potential "generic" error for DAZ or the "Shader developer" to be noticed... (To let them know that they are attempting to do two incompatible things that are impossible, or that the limits they used, are beyond the scope and stopping those two things from working together.)
So, in the end, only one of those two settings is working, or none of them, due to the failure. (At-least it is clear that they are not "Both" working, for the final render.)
As for the slow-downs, they are all subject to the level of rendering "things" you stack into the mix. They do not all happen at the same time. Rendering goes through levels of steps, depending on the settings, working by stacking outputs or by blending outputs or by over-writing outputs on the screen. (Eg, drawing the initial 100% lit-up images is fast. However, drawing the shadows back onto the lit-up surfaces takes longer... Drawing the atmospheric "blur" and "scattering of light-beams", takes even longer. Since those are more complex "corrections" to the original pre-rendered UV-map 100% lit-up surfaces. They deal with all the stuff in-between and have to do things like rendering the same model 8x from various angles, then "blur" the results, to get things like focal-depth and atmosphere specularity, which sees around the primary "camera-angle". Even if it is just fake focal blur, by blurring only... The process which comes in corrective passes, takes longer than just reading values from the images, as it has to read rendered values too, and add those into the progressive formula.)
When I setup rendering, on any new "render-engine", I play with the settings to get the fastest render possible, no matter how ugly. Then I adjust each individual setting and see how much time it adds. Also taking note to the highest value that produces what I want, and what looks best, without just wasting time for that 2% better look.
Eventually, I end-up with nice defaults that cover my test-renders, and production-renders, and super-production renders. My test renders only take a few minutes. I know what the final production-render will look like, by the way the test-render lays things down. When I have time, I do a super-production render, if needed. Though, I have not gotten any IRay warnings in my logs, yet...
The degrain filter is invoked when you turn on Noise Filter Enable. Not sure what the "black pixel filter" does, but it's probably related to the pixel filter setting. One or likely all of these may be incompatible with the degrain filter. The problem is being internally flagged by Iray as a render error, but the D|S "neuray manager" program (the thing that runs Iray) is handling it as a warning level. There should probably be something in the D|S user interface to make certain features grayed out when you select the Noise Filter, but since it doesn't cause a crash, it's probably low on their to-do list.
Filtering is one of those things that you just have to experiment with to see what works for your situation. If you pass your renders through a post process, you may find noise and speckle filters in Photoshop or GIMP are better and/or faster. For example, since convergence noise is mostly in shadow areas, in Photoshop create a mask of just the shadow areas, then run a despeckle or noise filter on this to reduce the "grain" of impartially finished renders. What I sometimes do is create a clipping mask of just the dark areas, and run the blur tool manually over it. Works well for a quick fix, and looks pretty good.
Tobor...remember, that kind of stuff is 'post processing'...and in general, this crowd (DAZ/Poser community) has had a severe allergy to post processing. It's going to take a while for these features to a) be accepted, b) be thought of as 'valid' and c) start being widely used.