madshi bug tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000568madVRbugpublic2018-07-29 10:082018-09-30 17:31
ReporterZaoshi 
Assigned Tomadshi 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformPCOSMicrosoft Windows 10 ProOS Version1803
Summary0000568: Render queue is not being filled
DescriptionWhen I'm using windowed and fullscreen windowed modes render queue (and to a similar extent present queue) are not being filled.
This seems to happen only when video is playing - if I pause queues get filled.
I tried using fullscreen exclusive mode and it does not have this issue (queues are completely full), but it comes with a bunch of other problems so I do not want to use it.
Steps To ReproduceSet GPU queue size to maximum and play video in fullscreen windowed mode.
Additional InformationI have tried switching from NGU to Bilinear scaling. This seems to increase queue to 8/24, but it still fails to get filled.
Then I tried to reset settings and set queue sizes to maximum. Queues were filled up completely.

I've attached .zip with OSD images from various modes and my settings.bin file in case it can be of any help.
TagsNo tags attached.
madVR Version0.92.14
Media Player (with version info)MPC-HC (64-bit) 1.7.13 (e37826845)
Splitter (with version info)LAV Splitter: 0.72.0.0
Decoder (with version info)LAV Video: 0.72.0.0
DecodingDXVA2 Native
Deinterlacingauto mode
DXVA2 Scaling Activeno
Aero / Desktop CompositionOn
Problem occurs with modeall modes
GPU ManufacturerNVidia
GPU ModelGeForce GTX 1070
GPU Driver Version398.36
Attached Fileszip file icon osd_images.zip [^] (3,299,653 bytes) 2018-07-29 10:08

- Relationships

-  Notes
(0002314)
madshi (administrator)
2018-07-29 10:48

If the problem does not occur with default settings, then I'd suggest that you compare your default settings to your non-default settings. E.g. start with the default settings, then step by step change one setting at a time, to gradually change the default settings to your non-default settings. This way you should be able to figure out which exact setting is responsible for the problem.
(0002316)
Zaoshi (reporter)
2018-07-29 11:18

Changes to settings and render queue results in order:
1. Default settings: queue at 23-24/24
2. Set chroma upscaling to NGU anti-alias high: 23-24/24
3. Set image upscaling to NGU anti-alias high: 23-24/24
4. Enabled reduce banding artifacts (high/high): 23-24/24
5. Enabled reduce ringing artifacts: 23-24/24
6. Enabled reduce compression artifacts, strength 8, quality high, +process chroma channels: 17-19/24
7. Enabled reduce random noise, strength 2, +process chroma channels: 7-9/24
8. Set image upscaling to Bilinear: 17-18/24
9. Enabled upscale refinement > sharpen edges 1.0: 14-16/24
10. Enabled upscale refinement > thin edges 1.0: 12-13/24
11. Enabled upscale refinement > activate anti-bloating filter 50%: 11-13/24
12. Enabled upscale refinement > activate anti-ringing filter: 10-12/24

It seems increasing number of processing steps reduces render queue even if GPU can keep up.
(0002317)
madshi (administrator)
2018-07-29 11:37

That's somewhat weird, I'm not sure why that would happen. What kind of average render times do you get? Does it change anything if you add a flush after intermediate render steps?

In any case, if the problem does not occur in fullscreen exclusive mode, then I'm not sure if there's anything I can do, because my code is nearly the same in FSE vs windowed mode. So it must be either Direct3D or the GPU driver which makes the difference here.

FWIW, most users don't like "reduce random noise" much. Might make sense to disable that and increase the "reduce compression artifacts" strength instead. That should save a lot of performance.
(0002318)
Zaoshi (reporter)
2018-07-29 12:10

I think render times are reported incorrectly so I'm not sure if it will be of any help. When I increase upscaling quality OSD shows 16ms but I get 3 frame drops / second.

Without flush OSD reports 13.25ms. With flush - 15.50ms and I get 2 frame drops / second.
In FSE mode without flush I get 19.50ms. With flush - 21.30ms. In both cases there are no frame drops.

I noticed that if I reduce GPU queue size to 8 my render queue stays at 4-5/8 and frame drops disappear (in case when flush is enabled).

I did notice that "reduce random noise" causes a lot blurriness. That is why I keep it at low value to get rid only of fine noise.
"reduce compression artifacts" has similar issue - at high value it blurs image and eliminates fine details. I had a few cases where it replaced texture with almost solid color, so I do not want to increase it.
For now I'm still experimenting with these options, but thanks for the information.
(0002319)
madshi (administrator)
2018-07-29 12:16

Well, as I said, I don't really know anything I could do to improve this situation. I'm doing the same thing in FSE mode and in windowed mode. So if it works well in FSE mode, then it's unlikely to be my fault if it doesn't work as well in windowed mode.

Both "reduce random noise" and "remove compression artifacts" remove fine noise to some extent. Enabling both is probably superfluous. I've already considered removing "reduce random noise" completely.
(0002320)
Zaoshi (reporter)
2018-07-29 12:38

Alright, thanks. I tried to reinstall driver but that did not help. It seems I'll have to reduce my queue to 8. At least this way it's partially filled.

Thanks for heads up. Will experiment to get by without it.
(0002321)
Nakasyma (reporter)
2018-07-29 13:31

I can confirm this is an issue and I have some additional information:

- The problem only occurs after Windows 10 Version 1803 (April 2018 Update) upgrade

- The problem only occurs with NGU upscalers, all of the other upscalers are working well (including super-xbr)

- For me it seems the problem is only with the queue information. I don't have any issues with the playing quality despite of the nearly empty queues (and also don't have any dropped frames)
(0002322)
madshi (administrator)
2018-07-29 13:35

There have been some functionality additions to win10. IIRC, some users on doom9 suggested to turn some of those new win10 features off to make madVR perform optimally. I don't remember the details, you'll have to dig through the doom9 madVR thread, or ask there.
(0002329)
Msarc (reporter)
2018-08-08 08:34

Same issue, some more info:

- I can confirm that this started happening immediately after Windows 1803 update (I only updated yesterday).

- It's not an NGU issue, other upscalers suffer from this as well, including Super-XBR. Less demanding upscalers simply lower the impact and allow better hardware to compensate with raw power.

- Lowering GPU queue size has the same effect - lowers the impact, but not enough to help when more demanding processing is being done.

- Enabling/disabling flush made no difference in regards to the issue, but disabling flush raised rendering times by about 3.5 ms in both windowed and FSE mode.

- DX9 or DX11 - no difference. Tried setting both in MadVR and LAV decoder.

- The only new feature in v1803 of which I could find mentions on the forum is "Focus Assist", but having it disabled made no difference on my system.

MadVR v0.92.14
MPC-HC v1.7.17
AMD drivers v18.4.1 and v18.8.1 (no difference)
CPU: Intel Q9550
GPU: AMD R9 290
(0002330)
madshi (administrator)
2018-08-09 11:19

Yes, I think it was "Focus Assist" which I've heard mentioned. Other than trying different drivers, I'm not sure what else to suggest. Obviously, if it was an OS update which introduced the issue, it's more likely to be a problem with the OS update or the GPU drivers than with madVR.

I've been telling users for months (years?) now that Windows 8.1 is the best OS for video playback. But nobody seems to listen to me. madVR users get screwed over time and time again with every new Windwos 10 update.
(0002331)
Zaoshi (reporter)
2018-08-09 19:39

Disabling Focus Assist helps with issues that occur when switching to FSE, but it doesn't seem to do anything for windowed fullscreen.
(0002332)
Msarc (reporter)
2018-08-10 11:23

Given that both Nvidia and AMD users are having this problem, it's less likely to be a driver issue. But it could be that Microsoft broke something that both camps need to fix. Just not sure any of them, including MS, will bother.

But back to the issue: I had noticed that both render times and CPU/GPU utilization are lower than normal in windowed mode after 1803.
For example, same video file, same madVR settings:
- Before 1803, 10-11 ms render times and no drops/repeats
- After 1803, 6-7 ms render times and massive drops/repeats

Like 1803 is preventing madVR from using the system at full power in windowed mode, for whatever reason.

And some more things I tried with no success:
- Checked Windows power settings - everything is still set to "max performance" as before.
- Set Windows system timer to 0,5 ms during playback, using "Windows System Timer Tool" (easily googled).
- Opened "Game Bar" during playback in MPC-HC and set it as a game.
- Disabled everything in "Settings > Gaming".
- Disabled the new "Settings > Personalization > Colors > Transparency effects".
- Set MPC-HC to "High performance" in "Settings > System > Display > Graphics Settings".
(0002430)
madshi (administrator)
2018-09-30 17:30

This problem should be fixed in v0.92.17, so I'll close this bug report. If you guys still have the problem with v0.92.17, then please re-open.

- Issue History
Date Modified Username Field Change
2018-07-29 10:08 Zaoshi New Issue
2018-07-29 10:08 Zaoshi File Added: osd_images.zip
2018-07-29 10:48 madshi Note Added: 0002314
2018-07-29 10:48 madshi Assigned To => madshi
2018-07-29 10:48 madshi Status new => feedback
2018-07-29 11:18 Zaoshi Note Added: 0002316
2018-07-29 11:18 Zaoshi Status feedback => assigned
2018-07-29 11:37 madshi Note Added: 0002317
2018-07-29 12:10 Zaoshi Note Added: 0002318
2018-07-29 12:16 madshi Note Added: 0002319
2018-07-29 12:38 Zaoshi Note Added: 0002320
2018-07-29 13:31 Nakasyma Note Added: 0002321
2018-07-29 13:35 madshi Note Added: 0002322
2018-08-08 08:34 Msarc Note Added: 0002329
2018-08-09 11:19 madshi Note Added: 0002330
2018-08-09 19:39 Zaoshi Note Added: 0002331
2018-08-10 11:23 Msarc Note Added: 0002332
2018-09-30 17:30 madshi Note Added: 0002430
2018-09-30 17:31 madshi Status assigned => closed
2018-09-30 17:31 madshi Resolution open => fixed


Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker