madshi bug tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000395madVRbugpublic2016-04-03 16:452016-04-08 18:52
Reporterhuhn 
Assigned To 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
Platformwindows OSwindows 10OS Version10547
Summary0000395: memory leak with a 3D LUT
DescriptionmadVR is leaking or not freeing memory when a 3D LUT is used.
Steps To Reproducerestart the PC
open GPU-Z. check the GPU memory usages.
use a refresh rate of 60 hz.
reset madVR to default settings.
select a 3D LUT.
enable smoothmotion.
set GPU queue to 4.
open a file and scale it to UHD.
close the media player.
the GPU ram usages should be a lot higher now. for me it's about 250 MB
Additional Informationi used a file with styled subtitles and i used xv subfilter.
TagsNo tags attached.
madVR Version90.16
Media Player (with version info)MPC HC 1.7.10
Splitter (with version info)lav filter 68
Decoder (with version info)lav filter 68
DecodingSoftware
Deinterlacingauto mode
DXVA2 Scaling Activeno
Aero / Desktop CompositionOn
Problem occurs with modeall modes
GPU ManufacturerNVidia
GPU Model960
GPU Driver Version364.72
Attached Files

- Relationships

-  Notes
(0001300)
huhn (reporter)
2016-04-03 16:48

i used madVR 90.17 not 90.16
(0001301)
madshi (administrator)
2016-04-03 16:48

If GPU RAM usage is still higher after closing the media player then madVR cannot be reponsible for that. The OS automatically cleans up all resources when a process closes down.

Or is the media player still hanging around in the task manager?
(0001302)
huhn (reporter)
2016-04-03 17:50

it is closed.
(0001303)
madshi (administrator)
2016-04-03 18:09

Then I don't see how it could be my fault.

Anyway, if you start (and stop) the media player multiple times to repeat this test, does the "leak" increase, until the GPU runs out of RAM?
(0001304)
huhn (reporter)
2016-04-04 02:50

no only up to 700 MB Vram usages.
(0001305)
madshi (administrator)
2016-04-04 08:43

Ok, thanks. Overall I don't think this is a bug in madVR. As mentioned before, even if madVR forgets to close the 3dlut (which I don't think is the case) the OS should cleanup when the media player closes. The GPU driver may delay cleanup for some unknown reason, maybe to save performance or something, but that's out of my control.
(0001306)
huhn (reporter)
2016-04-04 17:55

even an hour later it isn't cleaning the Vram.

if this is an OS or driver problem than there is nothing that can be done.

the only think i know was that after using madVR the GPU Vram usages gets higher.
(0001307)
madshi (administrator)
2016-04-04 18:35

Well, I don't know what I could do. My code looks ok to me, the 3dlut seems to be properly freed.

If you want to double check for a non-freed 3dlut: Every time you load a new video file into MPC-HC, madVR is destroyed and recreated. If madVR doesn't properly free the 3dlut, the GPU RAM consumption should steadily climb when loading multiple different video files in the media player *without* closing the media player. If that happens, madVR has a leak. If it doesn't happen, madVR doesn't seem to have a leak.
(0001308)
huhn (reporter)
2016-04-04 19:19

no that is clearly not happening.

it has something with scaling to do. a 3d LUT is just 100 mb how can it use up to 400 mb?

the biggest problem is for every new test i need to restart the PC i don't know another way to free the Vram.
(0001309)
madshi (administrator)
2016-04-04 19:47

Well, the 3dlut is RGB, but GPU textures require RGBA, so that's some percent more RAM. However, that doesn't explain the jump from 100MB to 400MB.

In any case, considering all the information I have right now, I'm pretty sure that all this behaviour is between the OS and the GPU driver, and madVR got nothing to do with it.
(0001310)
huhn (reporter)
2016-04-04 20:05

ok

- Issue History
Date Modified Username Field Change
2016-04-03 16:45 huhn New Issue
2016-04-03 16:48 huhn Note Added: 0001300
2016-04-03 16:48 madshi Note Added: 0001301
2016-04-03 17:50 huhn Note Added: 0001302
2016-04-03 18:09 madshi Note Added: 0001303
2016-04-04 02:50 huhn Note Added: 0001304
2016-04-04 08:43 madshi Note Added: 0001305
2016-04-04 17:55 huhn Note Added: 0001306
2016-04-04 18:35 madshi Note Added: 0001307
2016-04-04 19:19 huhn Note Added: 0001308
2016-04-04 19:47 madshi Note Added: 0001309
2016-04-04 20:05 huhn Note Added: 0001310
2016-04-08 18:52 huhn Status new => closed
2016-04-08 18:52 huhn Resolution open => fixed


Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker