6gb Vram Games

[Bradley Zweig]

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.

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.

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.

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 sup...@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 -

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.

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.

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.

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.

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.

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?

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.

I've been tweaking my P3d v5 settings to see what makes the sim tick. Unlike in v4, v5 makes very heavy use of VRAM, which is good! However, I and a few others have noticed that it's rather easy to crash the sim by going over the memory limit.

With all the ORBX products installed, sitting at FlyTampa EKCH V2, I easily hit the VRAM limit with my RTX 2080 when sat in a default A/C. Bear in mind that most of my sliders are one notch away from the maximum position.

I just wanted to let you know so that you're prepared for this possible issue ahead of the FSLabs v5 installers coming out. So far I have found that the two biggest VRAM hogs are Advanced Atmospherics (TrueSky Beta) and Texture Resolution.

Just look at the attached screenshots taken at Copenhagen and see how quickly the VRAM usage increases as you choose a higher texture resolution. You can easily save about 600MB just by choosing High instead of Ultra, and both look absolutely fantastic when viewed up close, let alone from the cockpit or high up above the ground.

Bear in mind also that I'm intentionally pushing the sim and your mileage will definitely vary. I just assumed that most of us who are invested in the FSLabs busses will be using some high quality add-ons alongside it.

I've been tweaking my P3d v5 settings to see whan makes the sim tick. Unlike in v4, v5 makes very heavy use of VRAM, which is good! However, I and a few others have noticed that it's rather easy to crash the sim by going over the memory limit.

I know, right? DX12 is pretty bad with VRAM management. That's why Asobo went with DX11 instead for MSFS2020. It's not optimized enough for huge open world environments. Or should we say, it's sort of ahead of its time and current gen GPUs are not ready for it, which is subject to change once the 3xxx series is out, bringing GPUs with more than 16 GBs of VRAM to the table.

They offer performance gains because they allow developers to load graphics textures directly into GPU memory rather than having to load them into slower system memory (RAM) and developers can also take advantage of other functions in the new api's that reduce cpu overheads when processing "draw calls". All these things reduce the amount of CPU processing required compared with the previous versions of the API's. The freed up CPU cycles and the faster processing of textures by the video card is what is resulting in the increased performance we see in V5.

However, because developers are now working much closer to the graphics hardware (e.g. loading textures directly into GPU memory), they now must be much more aware of how much VRAM each texture requires and they must manage the VRAM directly themselves. Previous API's did the memory management for them as the textures were in system memory and the graphics API took care of swapping textures to VRAM as and when required. The developers didn't have to worry about the amount of free VRAM and the API managed all that for them. However, the older API's had lower performance since they took up valuable CPU processing time and waited for textures to be moved back and forward between system RAM and VRAM.

It seems that with P3Dv5 it is going to be the end user's responsibility not to load too many textures to exceed their available VRAM. LM doesn't appear to have taken any measures in their code to prevent this from happening. I've had one crash to desktop on my machine so far. Not 100% it was a lack of VRAM as I didn't investigate it too much, but I run at 4K with 4x Super Sampling AA (I use a 65" screen so AA is important) and all graphics and world settings maxed out except dynamic reflections. GPU is the 2080Ti.

c80f0f1006