madshi bug tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000493madVRbugpublic2017-07-27 22:052017-07-30 18:32
ReporterAuroraWright 
Assigned To 
PriorityurgentSeveritymajorReproducibilityalways
StatusnewResolutionopen 
PlatformWindowsOSWindows 10OS VersionLTSB 2016
Summary0000493: Random spikes in render times cause caches to empty and framedrops
DescriptionNot sure if this is AMD or madVR's fault, but as I don't have posting permissions on the forum I'm reporting it here anyway.
With my 2016 Macbook Pro (Radeon Pro 460) and Windows 10, latest MPC-HC, LAV Filters and madVR, using an untouched BD rip of Kimi No Na Wa (haven't been able to reproduce this with anything else), there are random spikes in max rendering times (I lowered the rendering average to as less as 19 ms, no change) which empty the render cache and present cache, and when this happens both max rendering and max present times rise to 140 or so ms. The spots in which this may happen are random; and when it doesn't happen there's just a slight spike in rendering (41-45 or so ms).
My settings are:
- in MPC-HC I have the resolution change to the native 2880x1800 when going fullscreen (as normally Windows uses a 3840x2400 resolution with 200% zooming)
- in LAV, hardware decoding and deinterlacing are turned off.
- in madVR I have smooth motion on (as this monitor only supports 60 Hz), NGU Sharp Low as Luma doubling (the rest of the image upscaling window is left as efault), Bicubic60 + AR as Chroma upscaling, Bicubic150 + AR as downscaling, antibanding to Medium/High, CPU/GPU queues to 24/16, and everything else as default.
I tried both the latest AMD drivers (via inf editing to make them work on this card) and the older AMD/Apple-certified driver, and there's no difference. I also tried downgrading madVR but no change either. No other app is running other than MPC-HC.
Steps To Reproduce- Let the movie play for 10/15 minutes.
- Eventually a random rendering spike occurs and it brings both the render and present caches to 0.
TagsNo tags attached.
madVR Version0.91.11
Media Player (with version info)1.17.13
Splitter (with version info)0.70.2
Decoder (with version info)0.70.2
DecodingSoftware
Deinterlacingauto mode
DXVA2 Scaling Activeno
Aero / Desktop CompositionOn
Problem occurs with modewindowed mode
GPU ManufacturerAMD
GPU ModelAMD Radeon Pro 460
GPU Driver Version17.7.1
Attached Files

- Relationships

-  Notes
(0001748)
madshi (administrator)
2017-07-27 22:14

Seems weird that it only occurs with one specific movie. In the OSD (Ctrl+J) in this situation which is the first queue from top to bottom which is "in trouble"? I suppose the decoder and upload queues stay nicely filled?

Any external software running which might access the GPU, like GPU-Z or f.lux or a browser or anything?

Are subtitles active? If so try without. Also try DXVA copyback decoding instead of software, but I don't think it will make a difference.
(0001749)
AuroraWright (reporter)
2017-07-27 23:33

Looking at the OSD, the max rendering time has a spike to 140/150ms and the render queue is emptied, the present time/queue follow. Afterwards the render queue returns to normal after some framedrop, then the spikes alternate with present and render max times (one brings down the other queue and a bit of frame drops follow, and it keeps going this way). Tried disabling XySubFilter altogether and no difference, DXVA decoding makes no difference either. Yeah, decoding (and subtitle if enabled) queues stay 100% filled.
No program at all running in the background or foreground while I test
(0001750)
madshi (administrator)
2017-07-27 23:52

Try locking the GPU clock rates at max (or some other reasonable value) with some teaker tool. Sometimes the GPU clocks down temporarily which can cause these kind of issues.
(0001751)
huhn (reporter)
2017-07-28 00:23

are you using a 3D LUT?
(0001752)
AuroraWright (reporter)
2017-07-28 00:55

I locked it using Wattman (the built-in tool in Radeon Settings) via changing all the clock steps to the max clock and no difference either...
(0001753)
AuroraWright (reporter)
2017-07-30 18:31
edited on: 2017-07-30 18:32

I think I was wrong, because I did some more testing and it seems that presenting is actually the cause, with higher average rendering times (not sure why) the rendering queue stays filled and in these occasions only the present queue oscillates between 0 and 8; in exclusive fullscreen mode it shows a presentation glitch every time the present queue empties and there's a frame drop.


- Issue History
Date Modified Username Field Change
2017-07-27 22:05 AuroraWright New Issue
2017-07-27 22:14 madshi Note Added: 0001748
2017-07-27 23:33 AuroraWright Note Added: 0001749
2017-07-27 23:52 madshi Note Added: 0001750
2017-07-28 00:23 huhn Note Added: 0001751
2017-07-28 00:55 AuroraWright Note Added: 0001752
2017-07-30 18:31 AuroraWright Note Added: 0001753
2017-07-30 18:32 AuroraWright Note Edited: 0001753 View Revisions


Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker