Increase in workable rendering memory (Nvidia)?



  • Greetings Poser users, while experimenting with Poser today, I forgot to switch to CPU rendering for Superfly after loading up a rather huge scene - and to my great surprise the GPU started rendering as if nothing was the matter. I stopped the render, and the Message Log revealed that Poser had loaded no less than 7794 MB in rendering memory.

    I am quite certain that Poser would refuse to render things above 4000 MB in the past on my Nvidia 980 card, which has 4GB of memory. I tried to find any mention of changes in Poser and Nvidia changelogs, but was unsuccessful in doing so. Is this just a fluke, or has something changed behind the scenes to make this possible?



  • @adosity In Superfly you can switch the Renderdevice.
    The only problem with a 4 GB Graphics card is the field size.

    I guess it worked because you left the pre-selected "64x64"?

    If you choose an adequate field-size you can generally render with your card.

    See here:
    https://forum.smithmicro.com/topic/2142/rendertime-considerations-using-superfly-cycles

    For example my 1050 Ti with less Memory can render with field sizes up to 280, while the 1080 with more Memory can go somewhere up to 1024 - depending on the Szene difficulty. But 256 seems to generally work for newer Cards. I guess 32 or 64 should work with your older Card anyway and with any Scene.

    To automatically internally compute the right "Field-Size" for each System and Scene, is something the developers should really think about.

    0_1500043218766_2017-07-14 16_39_07-Render Options.jpg



  • @theogott yes, typically I use a tile size of 256, on larger renders I'd go to 384 (256+128) or 512. I'm using a GTX970 and GTX980. The only time I've gotten a render to fail is when textures exceed video ram. At that point it's easy to go through a scene and find a couple of textures that could be down-sized to get the render to go.



  • @theogott Right, I used to switch from GPU rendering to CPU rendering whenever the scene reached a certain complexity and size because Poser would simply fail to start the render if it reached that 4GB-ish threshold. I haven't done any comprehensive testing, but I seem to recall that the bucket size didn't really matter when it came to the GPU.

    Just a few weeks ago I was loading some locations (specifically, Petipet's Sci-fi Hangar) and I couldn't even render the location alone when using the GPU to render. Now I've been experimenting a bit, filled it with all manner of objects and figures, many with their own sets of PBR-textures, and I've gotten the rendering memory up to 8869 MB and it still works fine. That's both with a bucket size of 64 and up to 1024 (which is the highest I've checked).

    The only thing that I can think of having changed is that I disabled rendering in a seperate process, but that was only to get the rendering memory back in the Message Log, and I'm pretty sure it still failed to GPU-render large scenes after that. Poser hasn't had any updates, and I'm using Nvidia driver 382.05 for my 980.



  • From Blender i can tell you that sometimes restarting the program is helpful - especially after Rendering Errors. Also sometimes a complete Machine restart helped in the past. See ...



  • @adosity said in Increase in workable rendering memory (Nvidia)?:

    Greetings Poser users, while experimenting with Poser today, I forgot to switch to CPU rendering for Superfly after loading up a rather huge scene - and to my great surprise the GPU started rendering as if nothing was the matter. I stopped the render, and the Message Log revealed that Poser had loaded no less than 7794 MB in rendering memory.

    I am quite certain that Poser would refuse to render things above 4000 MB in the past on my Nvidia 980 card, which has 4GB of memory. I tried to find any mention of changes in Poser and Nvidia changelogs, but was unsuccessful in doing so. Is this just a fluke, or has something changed behind the scenes to make this possible?

    What you saw was correct. Poser's SuperFly can put textures into system memory when VRAM is not enough. There are still certain things that need to be in VRAM and cannot be moved, such as per-ray private data, which is why you can still see out of memory errors with larger tile sizes.

    For the technical details, see: https://developer.blender.org/D2056



  • @stefan Thanks, that's really interesting. The date on that post seems to suggest that this wasn't a feature when Superfly was first released in late 2015, and that I might have been working with outdated assumptions for the better part of the last year. Either way, it's good to see this is now possible.

    That note about 'pinning' half of the system's memory, does that mean it 'reserves' the memory regardless of whether or not it uses it for the render? I noticed that when I GPU-render a scene which Poser says uses 5100 MB of rendering memory I see Poser is using about 11 GB of the available 16 GB system memory; while it is at about 2 GB when not rendering. When rendering the scene with the CPU Poser is using 'only' 7 GB of system memory. Would it be correct to conclude that a GPU render 'reserves' (excuse my perhaps incorrect use of these technical terms) 8GB of system memory for the GPU render regardless of the scene's size?

    If so, I can see two caps on the scene when using GPU renders: the part that must fit on the GPU memory must be, in my case, smaller than 4GB and the total size must be, again in my case, smaller than 4GB + 0,5*16 GB = 12 GB. Is that about correct?

    I assume that the video posted (thanks for that, too) will educate me on the influence the Bucket Size can have on this memory use. A quick test with the aforementioned scene shows some less than conclusive numbers, in that a 32 bucket size results in 3310 MB memory load on the GPU, a 128 bucket size in a 3313 MB GPU memory load, and a 512 bucket size a 3301 MB GPU memory load. I'm not yet sure how to interpret that, but I'll have a look at the video soon.

    Thanks!



  • To add after a bit more testing: when under Preferences "Render Process > Seperate Process" is enabled, the mentioned scene (about 5100 MB) does run out of memory on a GPU render, this after first loading up the whole of the GPU memory (so hitting 4GB+ before stopping, rather than the 3300 MB it uses when the option is disabled). The error given is 'Out of device or mapped host memory'.

    Disabling the 'Seperate Process' option again allows the GPU render to proceed smoothly. This must have been what was holding me back in the last few months. I had enabled this option based on my understanding of the Poser manual - but perhaps the benefits of this seperate process are more apparent when using CPU renders and/or the Firefly engine.


  • Poser Ambassadors

    @adosity said in Increase in workable rendering memory (Nvidia)?:

    To add after a bit more testing: when under Preferences "Render Process > Seperate Process" is enabled, the mentioned scene (about 5100 MB) does run out of memory on a GPU render, this after first loading up the whole of the GPU memory (so hitting 4GB+ before stopping, rather than the 3300 MB it uses when the option is disabled). The error given is 'Out of device or mapped host memory'.

    Disabling the 'Seperate Process' option again allows the GPU render to proceed smoothly. This must have been what was holding me back in the last few months. I had enabled this option based on my understanding of the Poser manual - but perhaps the benefits of this seperate process are more apparent when using CPU renders and/or the Firefly engine.

    Render in separate process was very useful in the 32bit version of poser where the render engine would run in its own address space (which was limited to 4GB). With the 64bit version that limitation is no longer there.

    I think when you have it enabled, the render engine can no longer offload the GPU memory to system memory because it is in another address space.



  • @adosity said in Increase in workable rendering memory (Nvidia)?:

    @stefan Thanks, that's really interesting. The date on that post seems to suggest that this wasn't a feature when Superfly was first released in late 2015, and that I might have been working with outdated assumptions for the better part of the last year. Either way, it's good to see this is now possible.

    It was part of the initial SuperFly release and got improvements with the service releases, before it was submitted to the Blender developer site.

    Be aware though that there is always the CUDA runtime at play that does its own allocations that SuperFly has no control over, but renders will fail when the CUDA runtime runs out of VRAM.



  • @wimvdb said in Increase in workable rendering memory (Nvidia)?:

    I think when you have it enabled, the render engine can no longer offload the GPU memory to system memory because it is in another address space.

    That sounds like it makes sense (to me at least!), thanks. I'll leave it off from now on.

    @stefan said in Increase in workable rendering memory (Nvidia)?:

    It was part of the initial SuperFly release and got improvements with the service releases, before it was submitted to the Blender developer site.

    Be aware though that there is always the CUDA runtime at play that does its own allocations that SuperFly has no control over, but renders will fail when the CUDA runtime runs out of VRAM.

    Thanks for the clarification.

    Since you mention SuperFly has no control over certain allocations, I suppose there is also no way of knowing within Poser when (and on account of which models, textures, etc.) a scene reaches a point where it can no longer be rendered, and that it's a case of trial and error when you run into problems.