Flipping between GPU and CPU rendering each frame of a series?

I am experiencing an issue trying to render a series of images.  This is the first time I've done this, so I am not certain what I have done.

The problem: Daz is switching between using my GPU and my CPU between fames during the render.

It always renders the first frame on the GPU, blazes through its iterations, then it prepares the second frame and switches to CPU.  Chugs badly through the iterations, then prepares the third frame and switches back to GPU.  Sometimes this happens every frame, sometimes it manages 2 in a row.  I also noticed that the denoiser runs only on the frames rendered using the GPU.  Eventually (after the first 4-5 frames) it settles down and uses the GPU for the remaining frames.

What is going on?  The scene renders fine on the GPU as a still image.

Details: It's a single figure, wardrobe, no environment, although that doesn't seem to matter because it does the same thing if I turn off the wardrobe and figure and just render the HDRI.  I'm running a 1080 with 8 gigs of RAM, and the output is only 742x1200.  I have GPU checked for Photoreal and Interactive (CPU unchecked), and optix checked as well.

Have I done something stupid?

Comments

  • JD_MortalJD_Mortal Posts: 758
    edited April 2020

    Sounds like its just not "ready", before it starts the next scene. So the memory may seem "full", so the second frame will not fit, but obviously, since it didn't render that frame in memory, now memory is free again.

    I would suggest that you visit the help section and report this as a possible "bug". I am sure that they might just have to add a delay, or wait a moment more, to resolve this issue.

    Are you possibly rendering a real tiny scene that has a lot of content, but simply renders fast? If so, you might want to try a slightly longer render-time or possibly lower some detail a bit. Until this gets resolved for you, in your situation. I have personally not run into this issue, but my stuff either fits easily, or not at all. I don't have many renderings that are "on the border of memory", in an animation setup.

    Post edited by JD_Mortal on
  • westechiewestechie Posts: 17
    edited April 2020

    The problem is probably with your RAM memory size, because those Textures have to go some where.  They still get processed by your graphics hardware, but your RAM memory must still hold them on to them the entire time.  Texture data is copied to your graphics hardware.  It's not moved over.  If your RAM memory is not large enough, then it forces your OS to process the stuff it self from the Cache.  Any time the system uses its Cache, it will totally deny OpenGL access to graphics acceleration.  This would be why it switches from one to the other.

    You can have the best graphics hardware with incredible memory, but small RAM memory in your system will cause you an issue every time with out fail.  I'm guessing you have less than 16 GB of RAM memory.  It requires non-buffered ECC to push it to 32 GB if your CPU and mother board can even handle it.

    Post edited by westechie on
  • Try using the Public Build, https://www.daz3d.com/daz-studio-beta , as some chnages were made in the way resources are handled to try to address this issue.

  • westechie said:

    The problem is probably with your RAM memory size, because those Textures have to go some where.  They still get processed by your graphics hardware, but your RAM memory must still hold them on to them the entire time.  Texture data is copied to your graphics hardware.  It's not moved over.  If your RAM memory is not large enough, then it forces your OS to process the stuff it self from the Cache.  Any time the system uses its Cache, it will totally deny OpenGL access to graphics acceleration.  This would be why it switches from one to the other.

    You can have the best graphics hardware with incredible memory, but small RAM memory in your system will cause you an issue every time with out fail.  I'm guessing you have less than 16 GB of RAM memory.  It requires non-buffered ECC to push it to 32 GB if your CPU and mother board can even handle it.

    I'm not sure that's it, as I have 32 Gigs of system RAM, and Task Manager says it's barely a quarter full during the render.

  • JD_Mortal said:

    Sounds like its just not "ready", before it starts the next scene. So the memory may seem "full", so the second frame will not fit, but obviously, since it didn't render that frame in memory, now memory is free again.

    I would suggest that you visit the help section and report this as a possible "bug". I am sure that they might just have to add a delay, or wait a moment more, to resolve this issue.

    Are you possibly rendering a real tiny scene that has a lot of content, but simply renders fast? If so, you might want to try a slightly longer render-time or possibly lower some detail a bit. Until this gets resolved for you, in your situation. I have personally not run into this issue, but my stuff either fits easily, or not at all. I don't have many renderings that are "on the border of memory", in an animation setup.

    It does feel like that!  I noticed several frames start in CPU, then switch to GPU on iteration 60 or 70.  I'm rendering 400 iterations, so it's about 90 seconds per frame on the GPU.  As for the scene size, what you describe is what I typically encounter, too.  All or nothing.  I've done much larger scenes that fit (this one reports only 1.7 gigs of texture memory at render time, and less than 70 megs of geo),

  • Try using the Public Build, https://www.daz3d.com/daz-studio-beta , as some chnages were made in the way resources are handled to try to address this issue.

    I'm using 4.12.0.86... which I think is the same version as that link?  That's what it says here: http://docs.daz3d.com/doku.php/public/software/dazstudio/4/start

     

  • kenshaw011267kenshaw011267 Posts: 3,805
    westechie said:

    The problem is probably with your RAM memory size, because those Textures have to go some where.  They still get processed by your graphics hardware, but your RAM memory must still hold them on to them the entire time.  Texture data is copied to your graphics hardware.  It's not moved over.  If your RAM memory is not large enough, then it forces your OS to process the stuff it self from the Cache.  Any time the system uses its Cache, it will totally deny OpenGL access to graphics acceleration.  This would be why it switches from one to the other.

    You can have the best graphics hardware with incredible memory, but small RAM memory in your system will cause you an issue every time with out fail.  I'm guessing you have less than 16 GB of RAM memory.  It requires non-buffered ECC to push it to 32 GB if your CPU and mother board can even handle it.

    HUH? System RAM doesn't keep geometry or textures stored while a render is running uinless you're rendering on CPU.

    OpenGL isn't even used in an iRay render. Also cache hits are completely transparent to software and are faster than RAM hits anyway.

    You do not need ECC RAM to get more than 32Gb in a consumer system. It depends on the MoBo but 64Gb and 128Gb support is not uncommon. Workstation systems support up to 256Gb, if you really want to spend $1400 on RAM in a desktop system. This matters because ECC is substantially more expensive than standard RAM and at this point the protection it offers is minimal, basically the very rare flipping of a bit due to a cosmic ray hitting the RAM modules.

  • Try using the Public Build, https://www.daz3d.com/daz-studio-beta , as some chnages were made in the way resources are handled to try to address this issue.

    I'm using 4.12.0.86... which I think is the same version as that link?  That's what it says here: http://docs.daz3d.com/doku.php/public/software/dazstudio/4/start

     

    The beta is 4.12.1.115, so quite a bit (at least 115 builds) newer.

  • The beta is 4.12.1.115, so quite a bit (at least 115 builds) newer.

    Thanks!  I'll give it a try tonight.

  • hobhobukhobhobuk Posts: 27

    BETA fixes this, always had this issue.
    Diable CPU fallback altogether on BETA, on interactive and render.

Sign In or Register to comment.