Marmoset 4043 low VRAM usage
So the question is straight forward. Older marmoset (4036) was using up to 300% of VRAM before it really started lagging. Now, the new Marmoset (4043) is using not more than 85-95% of VRAM. And it never goes higher. It causes severe lags and delays in viewport. Basicly, I can't do anything. I need that new motion blur effect and a new shadow catcher for my renders. Anyone knows how to allow/make marmo to use up to 300% of VRAM again ? I also noticed that this problem occured when they introduced a TDR delay feature.
How it was -
And how its now -
My gpu is Geforce GTX 1070 ti 8gb 256b.
But nevertheless, within the same hardware the same scene works in a different way in 4036 and 4043 versions. Frustrating. Need your help.
I need to render a big scene, can't optimize it any further. Like this.
Replies
I can't speak to the performance issues, but.... 300% VRAM usage doesn't make sense to me anyway. 100% is the max it could ever be. The percentage must have been a display error of some kind?
It doesn't feel like display error. I think marmo pulls additional memory from common RAM. And the difference in performance is drastical. The scene with 210% of VRAM works way better than the one with 86%. The response to each action in the last scene is literally 10 seconds for any kind of an action. So its 100% VRAM plus some amount from RAM.
With the 4.04 update, Toolbag's backend switched from DX11 to DX12, and this had some performance and memory management implications. We also switched from Nvidia Optix to the DXR ray-tracing backend that is built in DX12. Generally, you should see improved ray tracing performance (render speed) but the memory use for the ray-traced acceleration structure can be higher than it was with Optix. In cases of very high memory use, you may see decreased performance or instability.
There is no way to configure Toolbag 4.04 to use the rendering backend or memory management systems from earlier versions.
The VRAM counter can be a little confusing. What it represents is the % of VRAM that Toolbag is able to allocate when it launches, not necessarily the % of the total VRAM available. Unfortunately, video card drivers make it difficult to report accurate VRAM information in absolute terms. What this means is that if you launch Toolbag when 6/8GB of VRAM is in use, the counter showing 100% would = 2GB of VRAM used by Toolbag. If Toolbag needs more than that, it will ask the operating system for additional resources, which may be granted. This is how values over 100% can sometimes be displayed. Values over 100% typically indicate very high memory use and potential instability.
Here are some general tips for reducing video memory usage:
If none of the above suggestions help, we may need to get a copy of your scene file to further debug the problem. In that case please email support@marmoset.co with a link to this thread and a brief description of the problem along. You can go to File -> Export -> Scene Bundle, and then zip up the .tbscene and /assets/ folder to package the scene.
Thank you very much for the tips on optimisation. As I said to your support the scene in 4036 works just fine, without any lags in the viewport. Rendering time is around 2-5 minutes for each shot you can see here -
https://www.artstation.com/artwork/RnW04v
I would actually trade the rendering speed to viewport stability. Even if the render goes faster than those 2-5 minutes for each shot, its not a big deal to me. I couldn't have managed to spot a difference in the quality of renders done in 4043 and 4036.
My GeForce GTX 1070 ti might be already outdated for the new codes and standards, but this is a pure downgrade of Tb4 for me.
I have several more scenes as large as that one to render. Now it turns out I can't use new features of shadow catcher and camera's motion blur.
Now I need to setup scene for each shot individually: linking hd textures to the objects that are close to camera and linking lower res to a distant objects. It turns out, that now Tb4 is suitable to render small scenes only.
I appreciate your detailed response on a new memory management logic.
Unfortunately, with the change from DX11 to DX12, there isn't anything we can do about how the memory is managed. We were surprised to learn that this scene performed acceptably in TB 403 as the texture memory use exceeds the amount of VRAM on your GPU. As Toolbag is a GPU renderer, it's important for the resources in the scene to fit into the GPU's available memory to ensure stability and a good level of performance.
We've discussed some options to handle these cases better such as a global texture resolution setting that would allow users to downsample all textures in the scene. We'll investigate this further for possible inclusion in a future build.
Thanks for the feedback.
Just add the new features from 4043 into 4036. Such as Motion Blur for camera and a new shadow catcher. Thats basicly it. I also want to suggest to keep the versions of Marmoset for dx11 and dx12 as two parallel products. Or maybe you could add an option somewhere in the settings that would allow to switch dx11 or dx12. Im really drooling over for the motion blur.
You are the best fellows. Marmoset is awesome. Love you.
Since it is on topic, i am using 3060ti/12900k/ddr5 (it was a gift someone else purchased) i get crashes, perhaps it is the ddr5, i am surprised to see that 210% usage on the vram, i am afraid to go above 90%, i stop using marmo, it could be an over use-age of materials on my part, even i think i have too many.
I did do this: "RTX to the Generic ray-tracing back end", idk if it helped with the crashes(posted piece), also idk if it is a bug but rtx and regular view-port seems to display the same "rtx" visual, minus solidifying, let's say gemstone colors from clear to a solid, i did do a test and found m4 to display refractive light through the same stones but only in 1 direction, which made me sad.
Guess i would be the only one to care for the all around lighting in 360 to get that "realistic look,"
About the encoding for videos ^ still speaking on rtx, if i put samples to 8 i sort of get a decent time-frame for encoding, but if i put the samples to anything higher say 32 = 4/8 hours, 64 = 8-12 hours, seems like something isn't doing something it should. Which in my in video/audio editing dabbling seems to be the "encoder" built into marmoset?
I really think this will help: \/
Take a look into a free app called megui it will give you standard setting you can change (there was a pre-settings before they updated i think they made it separated, i have them and can share them to add to the section where its needed to you can see all the editing they made to the encoder to make it from fastest to slowest) (might be at the installer for addons or something off github or similar hosting site) and you can adjust them to your encoder so these times can be better for you and the application. If it is another situation then by all means ignore this part. I am trying to help where i can with how i am using the app, to "give back", in some way, by "beta testing", i suppose. (hey at least i do it others i do not see bringing this up nor "giving back", when they obtain "copies".) The times also do not help any of us.
All the best, hope this reads well, sry to "derail very slightly.
(I will try to report more if i find situations worthy of reporting.)