DaVinci Resolve 19 - Your GPU memory is full

Hello,

I am doing intensive Color Management processing on my underwater 10bit videos: RGB Mixer, Color Wheels, Color Warper, Relight, Noise reduction, Power window, Tracking, ...

Today, I get ALWAYS the error message "Your GPU memory is full" when rendering in 4K AND in HD, if Davinci Resolve does not crash without warning. Before, I was able to go through by emptying the DVR cache and lowering the rendering speed. NOT ANYMORE.

My configuration :
DVR 19 Studio
CPU: Intel(R) Core(TM) i7-9700K CPU @ 3.60GHz 3.60 GHz
RAM: 32 GB (DDR4)
GPU: RTX 3090 GAMING UC 24G (RAM: 24 GB) + Driver NVIDIA 560.81 Studio (August 2024 version)
SSD: 256 GB (Windows 11 Home 21H2)
3 x HDD: 14 TB (Data & DVR work space)

I have followed most of the troubleshooting checklists from A to Z with the same result.

Any idea on how to solve the problem?

Davinci 19 really messed up VRAM usage, and FPS count, and I can not imagine this is any of OUR faults. there are hundreds of people saying 19 is a problem, and the regulars to the forum will tell you "It's your hard ware" you have 24 gigs VRAM, for anyone to tell YOU "It's your hardware" Is insulting lmao

your computer is beast, should easily handle this, but, something about 19 is using 2x as much VRAM as before, and definitely more ram. But good luck getting ahold of any of the devs to tell them, we've been trying to for weeks but we haven't gotten a response. I've called support numerous times as I have studio, and reported this.

Thank you for your battle Kat you are a true warrior. Do you do edit for people or for your streaming ? Lol see you on another bug topic !

You could try Caching some of those nodes, Jean-Marie, and using that Cache during delivery.

You could try Caching some of those nodes and using that Cache during delivery.

We already tried cached the audio, the video, everything cachable indeed and playing back files having them isolated, but that does not resolve the playback issue. And for users with a weak or borderline GPU, they say they can see the "Offline" red message blinking. It is likely the software somehow was unable to read the file correctly, whether it is cached, on the hard drive or SSD. This is why I asked everyone their OS and CPU type, maybe it is specific when you have the Windows 11 + Intel + NVIDIA graphic card combination ?

Hello guys,


Before going further, I do think DaVinci Resolve is really fantastic, especially its Color Management and its all-in-one package (Edition, Color, Fusion, Fairlight, Deliver).
Constructive critics, now.

Sorry to learn I am not the only one having this kind of problem.
Without even talking about budget, what worries me is that it is difficult to find a GPU with more than 24 GB of RAM on the market.
Should we need 2 GPUs? 4 GPUs? Is it really going to solve the problem? Computing power, energy & resources consumption does not seem to be a green planet solution, does it?

After many unsuccessful tests and one ultimate successful attemp/rendering, with my eyes on the Windows 11 Task Manager/Performance, I may have a temporary solution.

Let's review the situation:
The Color Management of my 2 falty clips (Clip1 and Clip2) is using for both :
Serial nodes:
=> RGB Mixer +
=> Primaries/Color Wheels +
=> HDR/Color Wheels (potentially, but not in my current problem)
=> Primaries/Log Wheels +
=> Relight (used only since DVR19, for me; it is great but also quite demanding on the RAM, I believe)
=> Sharpen
Parallel nodes:
=> Qualifier/HSL + Color Warper/Hue/Saturation
=> Power Windows + Tracking (potentially, but not in my current problem)
=> Magic Mask + Tracking (potentially, but not in my current problem)

What I believe is the problem:
The addition of Relight to all my other regular Color Management nodes is bringing my 24 GB of GPU RAM on the brinks of collapsing.
The Cross Dissolve video transition between Clip1 and Clip2 is the last straw causing the GPU RAM collapse to happen.

What I believe is a temporary/tedious solution to ease up a bit the strain on my GPU RAM:
1) Select all clips on the 4K Timeline (duplicated from the HD Timeline with its setting changed into 4K instead of HD)
2) Right-Click/Enable Clip => Untick (disable all clips)
3) Right-Click/Render Cache Color Output => Untick
4) Playback/Render Cache => User
5) For each Clip of the Timeline:
=> Right-Click/Enable Clip => Tick
=> Right-Click/Render Cache Color Output => Tick
=> Wait for DaVinci Resolve to create 100% of the Color Ouput Cache (Blue line on top of the Clip in Edit)
6) Once the Color Output Cache has been created for all the Clips of the Timeline, do the rendering with Deliver:
VIDEO:
=> Resolution = 3840 x 2160 Ultra HD (4K)
=> Encoding Profile = Main10 (I am using 10bit videos)
=> Advanced Settings:
====> Use render cached images => Tick
FILE:
=> Render speed = 50% or lower

Once again, it is a temporary and tedious solution, not really satisfying.

BLACKMAGIC, please, would not it be time to do a proper MEMORY MANAGEMENT OPTIMIZATION on DaVinci Resolve?
Computing power, energy and resources consumption is not the preferred solution anymore.
I understand DaVinci Resolve is very demanding on the computer configuration because of what it is able to do.
However, this could be a threat to DaVinci Resolve adoption in the future if a full Datacenter is required to make it work properly.

You could try Caching some of those nodes, Jean-Marie, and using that Cache during delivery.

Hello Jim,

Thanks for the good piece of advice which is more surgical than my temporary/tedious/sledgehammer solution (783 GB of cache just for 1 Timeline which is only one day of clips).
I will try that as well as you made me discover it was possible.

Nevertheless, I do think Blackmagic should optimize its memory management.
If it is already done or if the GPU driver prevents it (as I read it somewhere about NVIDIA), then Blackmagic should consider a user-friendly parameter providing:
=> some kind of automated caching solution when the GPU RAM is too close to its limit +
=> the appropriate means to manage the cached images in a fine way (GB of additional storage to delete); the present global cache of each project to keep or delete is not enough, in that case.

Many thanks to all of you who tried to help me.

Jm

One of the longest chapters in reference manual is about caching. Its worth putting time into learning it well.

I do think Blackmagic should optimize its memory management.

Well, I won't argue with that!

I am kind of surprised to see this is still an issue. For a while now the NVIDIA driver allows a fallback to system memory when VRAM is full. Setting the option in the NVIDIA control panel in the Manage 3D settings window > CUDA - Sysmem Fallback Policy to "Prefer Sysmem Fallback" instead of "Driver Default" may stop the crashes.. Worked for me. I went from 8 to "40" GB VRAM. And if the system slows down, you'll know why. Give it some time, make a sandwich, and see how it goes. At least it won't crash

But, Resolve still seems to have a serious memory leak issue with VRAM. Once it's full, it stays full, and slows things down, the program will not release VRAM until I quit. Some day that problem too, shall disappear. I can wait.

I don't use any cache, I hope. Mabye when I get a stack of expendable SSDs I might.

the program will not release VRAM until I quit.

I've seen that as well.

But, Resolve still seems to have a serious memory leak issue with VRAM. Once it's full, it stays full, and slows things down, the program will not release VRAM until I quit.

Instead of quitting, close project, start a new project, add media press play. Does your VRAM go down, if it does then you're not seeing a memory leak in the traditional sense of the term.

I am kind of surprised to see this is still an issue. For a while now the NVIDIA driver allows a fallback to system memory when VRAM is full. Setting the option in the NVIDIA control panel in the Manage 3D settings window > CUDA - Sysmem Fallback Policy to "Prefer Sysmem Fallback" instead of "Driver Default" may stop the crashes.. Worked for me. I went from 8 to "40" GB VRAM. And if the system slows down, you'll know why. Give it some time, make a sandwich, and see how it goes. At least it won't crash

But, Resolve still seems to have a serious memory leak issue with VRAM. Once it's full, it stays full, and slows things down, the program will not release VRAM until I quit. Some day that problem too, shall disappear. I can wait.

I don't use any cache, I hope. Mabye when I get a stack of expendable SSDs I might.

Thanks Dave,

I tried what you suggest. See my attached file.
Conclusions in my following posts.

Jm

You could try Caching some of those nodes, Jean-Marie, and using that Cache during delivery.

Thanks Jim,

I tried what you suggest. See my attached file.
Conclusions in my following posts.

Jm

the program will not release VRAM until I quit.

I've seen that as well.

Hello Jim and Dave,

I wanted to test your two propositions. So I simplified my Timeline to keep only 3 clips:
=> Clip number 01 (Just to warm up DVR19 a little),
=> Clip number 02 (My said "faulty Clip1" with Relight nodes added to my regular nodes),
=> Clip number 03 (My said "faulty Clip2" with Relight nodes added to my regular nodes),

with Cross Dissolve effects beween them.

1) I tried Dave's proposed solution of using the "Prefer System Fallback" parameter on the NVIDIA control panel, as shown in my previous post attached file 202409_1_NVIDIA Prefer System Fallback_FAILED.jpg (sorry, it's in french).

Well, the name of this file says it all. It failed. DVR19 crashed without warning and freezed my computer, forcing me to do an emergency restart.

2) I tried Jim's proposed solution of caching at least the extra Relight nodes I was suspecting to put extra strain on my GPU RAM.

There was no point in caching all the other nodes of the 4 Color layers (yes, I am using this new DVR19 functionnality as well) because it would have been more or less equivalent to my sledgehammer solution (caching the Color output of my Clips, one by one).

As shown in my previous post attached file 202409_2_Cache of Relight Nodes only_FAILED.jpg, I forced the caching of Relight nodes in Clip number 02 and I was in the process of doing it in the Clip number 03 when DVR19 gratified my with a beautiful "Critical Exception: bad allocation".

Once again, many thanks for your help and those interesting solutions which made sense.
However, they failed and I am sticking to my sledgehammer solution while hoping Blackmagic will do its best to address this Memory Management topic.

I must add, like Jim, that DVR19 does not seem to release properly the GPU dedicated RAM.
Sure, it is difficult to be 100% sure as I suspect a few things must remain in the GPU RAM in order to enable the Cross Dissolve between the clips, for example.
But when looking at the GPU performance screen of Windows Task Manager, the fact is the use of the GPU RAM is a staircase going up and never down, except when you quit DVR19 or when it crashes and you kill the process in Task Manager.

Cheers

Jm

Would it be useful if you uploaded your small test project with media (as a project archive) to a file sharing site and post a link to it here? Some of us could download it and try it out on our systems to see if we get the same sort of fault? I'd like to try it on my MacBook, for example, to see how badly it behaves but others with nVidia cards could give it a try as well. Your 24GB of VRAM should be more than enough unless something else is going on with your system (and with Resolve). It would also give BMD a solid test case to replicate the defect you have reported.

Would it be useful if you uploaded your small test project with media (as a project archive) to a file sharing site and post a link to it here? Some of us could download it and try it out on our systems to see if we get the same sort of fault? I'd like to try it on my MacBook, for example, to see how badly it behaves but others with nVidia cards could give it a try as well. Your 24GB of VRAM should be more than enough unless something else is going on with your system (and with Resolve). It would also give BMD a solid test case to replicate the defect you have reported.

Hello Steve,

It is most certainly a way for BMD to identify more easily what the problem is and where.
This is also giving up a little bit of my secret Underwater Color Management recipes
Are you sure others and BMD are going to dig into it?

I cannot do it today, nor this Week-End.
I might do this next monday 16th if you think it's worth it.

Jm

It may be worth it. If you have time and can create a simple example that illustrates the issue without revealing too much special sauce...

Instead of quitting, close project, start a new project, add media press play. Does your VRAM go down

No. That's how we know it's a memory leak. Resolve doesn't (always) release VRAM when switching projects, as it should.

Instead of quitting, close project, start a new project, add media press play. Does your VRAM go down

No. That's how we know it's a memory leak. Resolve doesn't (always) release VRAM when switching projects, as it should.

I can't see where they've indicated they closed their current project with maxed out VRAM opened a new project added a video and noted if their vram went down. If the VRAM doesn't go down that's a memory leak, a coding bug that could be fixed which is likely wasting processing cycles as well but if it does go down that would more indicate temporary files like caching filled up the VRAM because Resolve did not clean them up. Quite different things.

I've had a notable memory leak once, 6GB of VRAM got stuck, it remained between projects and after quiting Resolve, I was interested to see if it Windows would auto flush the VRAM but after 2 days the 6GB remained in VRAM, a restart fixed the problem.

I can't see where they've indicated...

I've done this.

It may be worth it. If you have time and can create a simple example that illustrates the issue without revealing too much special sauce...

OK, then.

Hello all,

As suggested by Steve, you will find links below to the archive of a 3 clips test project archive making DVR19 crash each time between Clip 02 and Clip 03 when rendering the Timeline in 4K with Main10 Encoding Profile (10 bit video depth) on my PC.

"Your GPU memory is full", "Bad allocation", "Critical exception" or Vanishing of the DVR19 GUI while DVR19 is still running wild as a background task,
I had them all and probably some other shades I can't remember.

Reminder of my PC configuration:
=> DVR 19 Studio
=> CPU: Intel(R) Core(TM) i7-9700K CPU @ 3.60GHz 3.60 GHz
=> RAM: 32 GB (DDR4)
=> GPU: RTX 3090 GAMING UC 24G (RAM: 24 GB) + Driver NVIDIA 560.81 Studio (August 2024 version)
=> SSD: 256 GB (Windows 11 Home 21H2)
=> 3 x HDD: 14 TB (Data & DVR work space)

The Color grading parameters are dummy to protect my ultra-secret recipes
However, the node tree is the one causing the crash.
Tested and crashing again before making this post.

To avoid PC/MAC compatibility and Google Drive access problems as much as possible, here are the different directories/files and their public link to my Google Drive :

DVR19-Troubleshooting {general purpose directory}
DVR19-Your GPU memory is full.dra {directory & DVR19 archive name of the Test project}
project.drp {DVR19 project archive file}
MediaFiles {media directory}
GX011291_Extract.MP4 {media file}
GX011293.MP4 {media file}
GX011295.MP4 {media file}

=> DVR19-Troubleshooting {directory}
https://drive.google.com/drive/folders/ ... drive_link

==> DVR19-Your GPU memory is full.dra {directory}
https://drive.google.com/drive/folders/ ... drive_link

===> project.drp {file}
https://drive.google.com/file/d/1E1b0i1 ... drive_link

===> MediaFiles {directory}
https://drive.google.com/drive/folders/ ... drive_link

====> GX011291_Extract.MP4 {file}
https://drive.google.com/file/d/1QdOhVJ ... drive_link

====> GX011293.MP4 {file}
https://drive.google.com/file/d/1bEKkWy ... drive_link

====> GX011295.MP4 {file}
https://drive.google.com/file/d/10dY58V ... drive_link

I do hope this will help.

Cheers

Jean-Marie

i have a bit of time, so i tried the .dra on my front line machine, a z8 with 2x 8160's / 2x 3090 blower / 256g / 96Tb on SAS, generaly nothing much slows down this machine

your project certainly did

i was seeing 18 fps playback without caches up to a dissolve, then it dropped to around 1fps during the dissolve

i copied the grades, made a new project imported the media, hit play and it was the same

i cached the second relight node and. it went back to playing back cleanly

no instances of "out of gpu mem" errors, but i might have stopped the playback early without caches, if my machine is running at 1fps, it's time to sort out why, not keep plowing on..

i'd find a way to get to the end game without two relight nodes... there's nothing i can see in them that could not not be done with simpler tools ( i can see boundry / edges breaking a bit)

Without caching it's very slow, but didn't get an out of memory error

The project worked for me. During the render it went right up against the 8gb VRAM on the card and then spilled over into system RAM up to 10gb more, getting real slow in the process. The second transition took a little over 10 minutes, the entire render taking 18 minutes 34 seconds. Once past the second transition, it released all but 2gb of system RAM, but render continued very slowly to the end.

I didn't do any caching, so the VRAM was full and the interface was very slow while messing with settings and trying to play the timeline. I thought it crashed, but it didn't. Yay!

And I stand corrected on the memory leak, kinda... All but 4.5gb of VRAM was released when I opened a different project.

I'm going to mess around a bit more. I have to find out why the audio didn't import

Ok render 4K 10bit HEVC, same render one after another

0:51m
1:16m
1:05m
1:28m

So it is a bit unusual, my VRAM is getting over full and the slow down occurring, but not a crash or out of memory error. I then load a new project, VRAM goes down to 3GB indicating it's a not a memory leak, but a clutter of leftovers left in VRAM in the project that isn't being released FOR THAT PROJECT, but is released with a new project.

i have a bit of time, so i tried the .dra on my front line machine, a z8 with 2x 8160's / 2x 3090 blower / 256g / 96Tb on SAS, generaly nothing much slows down this machine

your project certainly did

i was seeing 18 fps playback without caches up to a dissolve, then it dropped to around 1fps during the dissolve

i copied the grades, made a new project imported the media, hit play and it was the same

i cached the second relight node and. it went back to playing back cleanly

no instances of "out of gpu mem" errors, but i might have stopped the playback early without caches, if my machine is running at 1fps, it's time to sort out why, not keep plowing on..

i'd find a way to get to the end game without two relight nodes... there's nothing i can see in them that could not not be done with simpler tools ( i can see boundry / edges breaking a bit)

Thanks for your help.
My conclusions in a further post.
Jm

The project worked for me. During the render it went right up against the 8gb VRAM on the card and then spilled over into system RAM up to 10gb more, getting real slow in the process. The second transition took a little over 10 minutes, the entire render taking 18 minutes 34 seconds. Once past the second transition, it released all but 2gb of system RAM, but render continued very slowly to the end.

I didn't do any caching, so the VRAM was full and the interface was very slow while messing with settings and trying to play the timeline. I thought it crashed, but it didn't. Yay!

And I stand corrected on the memory leak, kinda... All but 4.5gb of VRAM was released when I opened a different project.

I'm going to mess around a bit more. I have to find out why the audio didn't import

Thanks for your help.
My conclusions in a further post.
Jm

Ok render 4K 10bit HEVC, same render one after another

0:51m
1:16m
1:05m
1:28m

So it is a bit unusual, my VRAM is getting over full and the slow down occurring, but not a crash or out of memory error. I then load a new project, VRAM goes down to 3GB indicating it's a not a memory leak, but a clutter of leftovers left in VRAM in the project that isn't being released FOR THAT PROJECT, but is released with a new project.

Thanks for your help.
My conclusions in a further post.
Jm

The project worked for me. During the render it went right up against the 8gb VRAM on the card and then spilled over into system RAM up to 10gb more, getting real slow in the process. The second transition took a little over 10 minutes, the entire render taking 18 minutes 34 seconds. Once past the second transition, it released all but 2gb of system RAM, but render continued very slowly to the end.

I didn't do any caching, so the VRAM was full and the interface was very slow while messing with settings and trying to play the timeline. I thought it crashed, but it didn't. Yay!

And I stand corrected on the memory leak, kinda... All but 4.5gb of VRAM was released when I opened a different project.

I'm going to mess around a bit more. I have to find out why the audio didn't import

Hello Dave, DermotShane & CougerJoe,

3 tries, 3 hits without other nuisance than a system slowing down to a crawl, which is already surprising, considering some beasts you are running this small test on.
What should I think?

If the strength of a chain is depending on its weakest link, should I conclude there is a bottleneck in my configuration which is too narrow to stand the strain of the color grading, despite the 24GB of my RTX 3090 GPU?

My main HDD used for DVR data is getting old?

My 230 GB Samsung SSD for the OS where only 35 GB are left?

And why on earth my render is not "spilling over into system RAM" like yours, Dave?
Did I miss an important point? Some clever Windows/PC system or NVIDIA driver or DVR19 parameter that spare my GPU RAM when it is full up?

I really don't mind my system to be slow as long as the render goes throuh properly which is not the case, unless cashing all my clip color output one at a time (sledgehammer solution).

True enough, I am going to make a new High-end PC full of SSD, with NVMe cache, a RTX 4090 and other fancy things to enjoy DVR19 post-production because the main components of my current PC (Motherboard, i7, ventirad HDD) are aging (2015) even if they are running smoothly. I have even tested all my 32 GB RAM recently, just to make sure.

However, this hardware change should not be considered as a satisfying solution.
No witchcraft in IT. There must have some kind a rational explanation. There must have some kind of astute software crafts to deal with sparseness and bottlenecks, within certain limits, of course.

There was a time, not so long ago, when IT resources where sparse and expensive. Coding had to stay close to the CPU instructions in order to be efficient and to remain thin, then.
Today, Energy and resources are becoming sparser and more expensive again.
Today is time to go back to LOW CODE.
BMD should keep it in mind.

Once again, many thanks to all of you, guys, for helping me digging into this problem. I am impressed by your dedication and your willingness to test it yourself.

I am sticking to my sledgehammer solution and to relight, for the time being. Yes, I had other ways to relight my subjects before but DVR is my Christmas Tree. BMD made this present for us and I don't understand why I should not use it anymore. It would be a bit like going back to candlelight.
Let's see what happens next.

Cheers

Jm

I had this GPU Memory is Full problem also... I forget what I did to fix it, do you have EasyDCP checked? If so, uncheck it. Also, I've had problems using the "Better" option for Relight. Have you tried disabling nodes to see if the problem goes away?

My system:

• Dual XEON 6230 Gold Processors with a combined 40 cores and 80 threads
• All M.2 SSD storage (PCIe 3)
• 256gb of DDR4 ram
• RTX 3090 24GB

resolve.PNG (24.05 KiB) Viewed 32279 times

I had this GPU Memory is Full problem also... I forget what I did to fix it, do you have EasyDCP checked? If so, uncheck it. Also, I've had problems using the "Better" option for Relight. Have you tried disabling nodes to see if the problem goes away?

My system:

• Dual XEON 6230 Gold Processors with a combined 40 cores and 80 threads
• All M.2 SSD storage (PCIe 3)
• 256gb of DDR4 ram
• RTX 3090 24GB

The attachment resolve.PNG is no longer available

Hello Que Thompson,

Thanks for trying.
The EasyDCP is unchecked (see picture below, coming from my DVR19 Studio configuration).
Because it is advised to leave at least 30% of free space on any SSD, I also managed to bring back the available space of my OS SSD drive to 32%, just in case this is a bottleneck for DVR19. The render is still crashing.

I can work on my color grading, for the time being.
A sledgehammer solution exists for the rendering (my color output caching of all the clips, one by one, then using the cached images in the rendering process).
The last 3 successful render tests of Dave, DermotShane & CougerJoe may suggest a new high-end PC is a possible solution, however unsatisfactory it may be without a good technical explanation of the root cause.

Let's hope BMD will be listening.
I heard BMD CEO developped his own corporate software because he could not find any corresponding to his needs on the market. Optimization is certainly something speaking to him.
Again, DaVinci Resolve is resource demanding because of what it is able to do. This is understandable. Nevertheless, it would be nice if it was not up to the point of requiring a mini-datacenter at home.

Jm

Just out of curiosity, if you take the “relight” tool out, do you see any issue? That tool is power hungry….

Just out of curiosity, if you take the “relight” tool out, do you see any issue? That tool is power hungry….

Hello Walter,

Test 1 : Relight1 & Relight2 nodes inactivated in Clip 01, 02 & 03
=> Render (Main10, 4K) OK

Test 2 : Relight1 & Relight2 nodes re-activated in Clip 02
=> Render (Main10, 4K) OK

Test 3 : Relight1 & Relight2 nodes re-activated in Clip 02 & 03
=> Render (Main10, 4K) NOK

Relight is very memory greedy indeed. But 24 GB for 2 clips in 4K, really?

Jm

Jm,

I have some other options turned off that may or may not make a difference for you.

In your Decode options:
If you're not using Blackmagic RAW or the cloud or RED, turn off "Use GPU for Blackmagic RAW decode" "Stream files during download from Blackmagic Cloud", and disable "Use GPU for R3D"

Under Memory and GPU:
GPU processing mode - Uncheck Auto and select CUDA
GPU selection - Uncheck Auto and select your video card in the window below.

I hear differing opinions on using "Performance mode" under the playback stettings in preferences. I disabled mine
 
In my nvidia control panel under the Manage 3D settings: OpenGL rendering GPU - I also have my video card instead of auto selected

I selected my card in all those settings so that the system "doesn't get tied up in knots" looking for the wrong thing. It may be overkill, but Resolve hasn't crashed since

I also have Live save and project/timelines backup disabled, because they have caused me grief in the past, and now I manually save and export very frequently. Some people consider that dangerous, but when they were on, they would frequently interupt whatever else I was doing, I suspect a crash or two may have been caused by them also

I would like to know if 4 frames a second is the best an RTX 2070 can do. during the transitions it would "lock up" for a long time. Even if I were to cache these things it would take an enormous amount of time to render them for the cache, and then, make the smallest change and it has to remake the cached file

I'm curious, can you let us know how much shared GPU memory shows up in your Windows Task Manager under the Performance tab? The 24gb you have on the card should be enough, I only used 19gb (GPU+sys) to render your test project.

If all else fails, it could turn out you have a hardware defect in the VRAM

you could try another video driver to see if its that.
tried it on my machine and rendered fine but on amd gpu.
I note clips shot in 50 on a 29/30 timeline what frame rate you exporting at.

I'm curious, can you let us know how much shared GPU memory shows up in your Windows Task Manager under the Performance tab? The 24gb you have on the card should be enough, I only used 19gb (GPU+sys) to render your test project.

For me it used 22.6 GB Vram + 2.8GB system memory on first render that took 51 seconds, but this was loading project and render, which you wouldn't normally be doing unless you are having a problem with Resolve. Using timeline and editing then immediately rendering would have resulted in more memory use and slower render.

You can try to split the effects in a different timeline and "render in place" as workaround

Hi
I have a similar problem with GPU memory. It´s really strange. Even when Resolve is idle for hours the VRAM stay filled up at least on one of my 2 x RX6900XT. The GPUs can never max out because of too little VRAM. Often the GPUs run only on 20%.

I just enabled Resize Bar in OpenCore and my BIOS and it helps a lot cause the GPU can use additional memory from the RAM when it gets full.

You can try to split the effects in a different timeline and "render in place" as workaround

Hello Waltervolpatto,
Dear fellow Resolvians,


Sorry for my silence. Back on the air. Once more, thank you for trying to help or to share the pain.
I still believe DVR19.1 is a fantastic software and my perpetual Christmas tree

In the meantime, I created a new PC and some more underwater video post-productions/testings.

1) Here are the main components of my homemade brand new PC as of today :
- CPU = AMD Ryzen Threadripper 7970X 32-Cores,
- Motherboard = Gigabyte TRX50 Aero D,
- RAM = 192 GB = 4 x Micron 48GB DDR5-5600 RDIMM 2Rx8 CL46,
- GPU1 = ASUS GeForce RTX 4090 24GB (new one),
- GPU2 = Gigabyte GeForce RTX 3090 24GB (my old one),
- Win11 Pro Drive = SSD Samsung 990PRO 1TB NVMe PCIe 4.0 (up to 7450 MB/s),
- DVR Work Drive = SSD Samsung 990PRO 2TB NVMe PCIe 4.0 (up to 7450 MB/s),
- HDD = 2 x 16 GB.
It is working fine and with lightening speed, which is a great relief!
In other words, let's get rid of the hardware and power problem, even if I may consider a possible weakness of my "old" 3090 GPU2 which might not stand the saturation of its memory as well as the new 4090 GPU1.

2) Let's face it:
My DVR19.1 renderings keep on:
- saturating my GPU memories,
- crashing without warning and without freezing my PC, this time (thanks to Win11 pro, to the 48GB GPU memory, to the 192GB RAM or to the brand new PC in gener
al?).
It simply vanishes from the screen and from the running tasks after some hard processing.
So, either I do not use DVR19.1 properly or DVR19.1 is (too) memory greedy.
However, I developped a strategy which seem to prevent it most of the time (see below).

3) Some empirical observations, first, based on what I see on the Windows Task Manager-Performance tool and on how is structured my timeline :
- DVR uses my 2 GPUs in priority, more than the CPU;
- In my configuration and after some tests, DVR seems to consider that the Main GPU is the one managing the 2 monitors (here: GPU1);
- All the 3D GPU processing shows on GPU1 only;
- The memory of GPU1 and GPU2 are used simultaneously;
- The temperature of GPU1 and GPU2 rises simultaneously during the processing;
- Most of the time the CPU is used at, let's say, 10% but can go up to 50% and seldomly up to 70% (hypothesis: 1.when my Fusion macro used to level horizontally, to resize/move and to blackframe the clips is involved or 2.when some serious compression/decompression is taking place like during the Color Render caching with DNxHR HQX codec);
- The use of the two GPU memories is always scaling up and never goes down during the render;
- The release of the two GPU memories takes place only when I end DVR;
- The crashing seems to occur when my GPU2 (3090) memory is saturated;
- My timeline is set to 4K only for Render ; it is made of clips with a lot of color management, some fusion macros when necessary (see Use of CPU above), linked together by standard cross-dissolve effects.

4) Here is an empirical and only intuitonal strategy I use to prevent the Render to crash as of today (written for you as well as a procedure for me) :
Step 1: Set Project settings > Render cache format = DNxHR HQX => Maximum compression of the cache with very few concession on quality in order to use the power of my CPU and to decrease the volume of cache on my DVR Work Drive
Step 2: Set Playback > Render Cache = None => No cache production when working on the timeline Color Management
Step 3: Set Timelines > Timeline Settings > Timeline Resolution = HD (1080p)
Step 4: Do the Color Management of the whole HD timeline
Step 5: Do not use any video transition effect => avoid the likely requirement for DVR to have two clips in GPU memory at the same time during the main color Render caching of step 8
Step 6: Set Timelines > Timeline Settings > Timeline Resolution = Ultra HD (4K) => I duplicate my HD Timeline to play safe as a backup and set the new one to Ultra HD
Step 7: Set Playback > Render Cache = Smart
Step 8: Let the timeline main color Render caching run automaticaly (the red line on top of the timeline in Color must become blue) => serious data crunching, power consumption (not ecological, unfortunately) and heating is taking place, hopefuly without crashing
Step 9: Put the video transition effect in the timeline and set its duration, one at a time => DVR is automatically going to update the cache of the overlapping clips to take the new effect into account, with minimum resource (memory, compute) consumption hopefully
Step 10: Do the Render of the Ultra HD (4K) Timeline

ONLY WHEN statisfied with the rendered 4K timeline:

Step 11: Set Playback > Render Cache = None => To stop the automatical color Render caching
Step 12: Set Playback > Delete Render Cache = All => To release space on the DVR Work Drive

NB1: As an amateur, I really wonder how the Hollywood and other Professional post-producers are playing it with their zillionK rushes. One clip at a time? A full datacenter? Other means?
NB2: BlackMagic Design, can you improve the DaVinci Resolve GPU memory management, please?

Cheers

Jm

i grade indie features mainly, use four machines regularly, and another few machines at random times

i have only twice needed to use re-light, if a shot has been so completly screwed up on set as to need that, it has already gone to VFX to sort one hopes

the post sup's do not budget time to sort that stuff in a grading suite, and producer's do not have the coin to pay for VFX in a grading suite, the DP and directors do not have the time / patience to sit through what is basicly a side trip from the task at hand, gradeing their film

that we CAN do things like that is cool, but with 10 days to grade a feature, it's not cost effective to tie up the realestate, monitors, scopes, coffee machine, bar fridge, couches, light controled enviroment etc to do something that is best sent off weeks in advance and arrives at my doorstep as an EXR sequence

most client driven sessions are on a machine with 24g Vram and 2x xeon proc's, workstation class machines with solid PSU and cooling to run 24/7 @ 100% - up to the task at hand, but not an optimal fit for doing VFX on the fly in RT

i grade indie features mainly, use four machines regularly, and another few machines at random times

i have only twice needed to use re-light, if a shot has been so completly screwed up on set as to need that, it has already gone to VFX to sort one hopes

the post sup's do not budget time to sort that stuff in a grading suite, and producer's do not have the coin to pay for VFX in a grading suite, the DP and directors do not have the time / patience to sit through what is basicly a side trip from the task at hand, gradeing their film

that we CAN do things like that is cool, but with 10 days to grade a feature, it's not cost effective to tie up the realestate, monitors, scopes, coffee machine, bar fridge, couches, light controled enviroment etc to do something that is best sent off weeks in advance and arrives at my doorstep as an EXR sequence

most client driven sessions are on a machine with 24g Vram and 2x xeon proc's, workstation class machines with solid PSU and cooling to run 24/7 @ 100% - up to the task at hand, but not an optimal fit for doing VFX on the fly in RT

Hi Dermot Shane,

Brutal! No room enough for fancy tools like Relight if it's slowing you down. Solid computing power required to produce efficiently within a short timeframe and within budget.
I understand. Thanks for sharing your pro real life experience.

On my side, I do this for fun, not for a living, as a simple user and customer.
If it does not shake anything at BMD's, I hope at least it can help a user or two, pro or amateur.

Cheers

Jm

Take the 3090 out and with with a single gpu