H.265 4:2:2 10bit Intel iGPU hardware decoding memory leak?

Can someone look into possible H.265 4:2:2 10bit Intel iGPU quicksync hardware decoding memory leak that might lead to the excessive memory usage with thumbnail generation?

Can also vouch for this, Have the same issue. Either intel driver issue or DR bug.

Can also vouch for this, Have the same issue. Either intel driver issue or DR bug.

The desktop 12900 and 13900 Intel iGPU can use up to 64GB of system RAM which those users may have a much lower chance of getting memory overload due to larger iGPU ram pool.

I think most professionals wont try to edit h.265 just yet due to performance issues in general.
But really hope this can be resolved soon!

Intel has blamed the control software. They've suggested removing the driver with DDU and installing an older one.

Supposedly there is an update out now that fixes the memory issue but can't find it yet.

Intel has blamed the control software. They've suggested removing the driver with DDU and installing an older one.

Supposedly there is an update out now that fixes the memory issue but can't find it yet.

Found the forum post you were talking about but it doesn't seem to solve the issue. Either removing ark control software or DDU'ing to install older drivers results in the same crashes / memory leaks.

Updating BIOS to latest with latest drivers also no solution.

I just did a clean install of

31.0.101.4826

My memory use went from almost 50GB to at most 300MB. Often much less.

We'll see how long it'll work but right now on my system it seems to be fixed.

I just did a clean install of

31.0.101.4826

My memory use went from almost 50GB to at most 300MB. Often much less.

We'll see how long it'll work but right now on my system it seems to be fixed.

I am running the same driver right now, without Arc control software. It seemed to be running a bit better for me initially but ended up with the same crashes after a while and lots of memory usage because timeline thumbnails en bin thumbnails.

Any other stuff you did?

No just that.

I just did a clean install of

31.0.101.4826

My memory use went from almost 50GB to at most 300MB. Often much less.

We'll see how long it'll work but right now on my system it seems to be fixed.

I did a clean install three days ago and today just now again.
The same memory overload problem persist on my system with H.265 10bit 4:2:2 files.
H.265 10 bit 4:2:0 is ok because RTX3080ti and most modern videos cards can decode it.
But not the H.265 10bit 4:2:2 ...

When you open task manager which application is taking all the memory?

Only thing I can think of is the control software didn't get full removed and replaced.

I just did a clean install of

31.0.101.4826

My memory use went from almost 50GB to at most 300MB. Often much less.

We'll see how long it'll work but right now on my system it seems to be fixed.

I did a clean install three days ago and today just now again.
The same memory overload problem persist on my system with H.265 10bit 4:2:2 files.
H.265 10 bit 4:2:0 is ok because RTX3080ti and most modern videos cards can decode it.
But not the H.265 10bit 4:2:2 ...

Also did a DDU reinstall and the memory overload persists. Thumbnail loading in bin viewer and timeline takes up so much memory. I really don't get why it does, or should do that. Is there a way to have these thumbnails less dynamic in DR, so that it is just one thumbnail and not hover scrolling in bin de viewer?

When you open task manager which application is taking all the memory?

Only thing I can think of is the control software didn't get full removed and replaced.

DaVinci Resolve
no other application is taking up memory fast during h.265 10bit 422 thumbnail generation@_@.

See that's different. I never saw Resolve grabbing memory. It was the arc software.

When you open task manager which application is taking all the memory?

Only thing I can think of is the control software didn't get full removed and replaced.

DaVinci Resolve
no other application is taking up memory fast during h.265 10bit 422 thumbnail generation@_@.

For me it's also just resolve taking up memory.

Intel gfx_win_101.4887 and DR 18.6.2 is working ok I think.
For some unknown reason Intel iGPU revert back to older driver two time today at some point which lead to memory overloads and crashes. Wired...

How much ram do you have? The limit IIRC should be 50% of system ram.

How much ram do you have? The limit IIRC should be 50% of system ram.

64gb total system memory
laptop 12900H iGPU can only use upto 32gb of RAM.
desktop 12900k can use upto 64gb.

Latest intel iGPU drivers 4887. Latest resolve 18.6.2. Still same memory overload happens.

How are we the only ones experiencing this and how is no one at Blackmagic aware of this?
It just makes no sense that even with thumbnail loading the pc is under that much load. Why is there no option for all the thumbnails to not be Dynamic as in being able to scrub through them in the viewer? Just let them be static one thumbnail images instead of DR trying to create multiple thumbnails per clip for all clips in the source viewer. Am aware of the uncheck live preview setting in the source viewer. Does nothing.

Changing the timelines thumbnail generation helps somewhat in extending the moment it does eventually crash, but still not ideal.

Only way to go through this is with proxies / transcoding, however still buggy to say the least on the intel iGPU. Nvidia GPU for decode is fine but slower then the intel is supposed to be.
Again in premiere no issues at all with live raw playback of 10 bit 422 and 420 clips.

It's infuriating to say the least.

Latest intel iGPU drivers 4887. Latest resolve 18.6.2. Still same memory overload happens.

How are we the only ones experiencing this and how is no one at Blackmagic aware of this?
It just makes no sense that even with thumbnail loading the pc is under that much load. Why is there no option for all the thumbnails to not be Dynamic as in being able to scrub through them in the viewer? Just let them be static one thumbnail images instead of DR trying to create multiple thumbnails per clip for all clips in the source viewer. Am aware of the uncheck live preview setting in the source viewer. Does nothing.

Changing the timelines thumbnail generation helps somewhat in extending the moment it does eventually crash, but still not ideal.

Only way to go through this is with proxies / transcoding, however still buggy to say the least on the intel iGPU. Nvidia GPU for decode is fine but slower then the intel is supposed to be.
Again in premiere no issues at all with live raw playback of 10 bit 422 and 420 clips.

It's infuriating to say the least.

Try a "Clean" install of the newest driver 4887 "only select the igpu driver"? and check device manager to see if the Intel igpu driver is indeed the new one before starting Davinci.
For some resason that igpu driver was reverted back to old driver yesterday twice...

Might be windows. In the past it had a habit of reverting to the last driver installed by Windows.

sadly, still crashing @_@...