View Issue Details

IDProjectCategoryView StatusLast Update
0000568madVRbugpublic2022-09-23 08:41
ReporterZaoshi Assigned Tomadshi  
PrioritynormalSeverityminorReproducibilityalways
Status feedbackResolutionreopened 
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.17
Media Player (with version info)MPC-HC (64-bit) 1.9.23
Splitter (with version info)LAV Splitter: 0.76.1
Decoder (with version info)LAV Video: 0.76.1
DecodingDXVA2 Copyback
Deinterlacingauto mode
DXVA2 Scaling Activeno
Aero / Desktop CompositionOn
Problem occurs with modewindowed mode
GPU ManufacturerNVidia
GPU ModelGeForce RTX 3090
GPU Driver Version516.94

Activities

Zaoshi

2018-07-29 10:08

reporter  

osd_images.zip (3,299,653 bytes)

madshi

2018-07-29 10:48

administrator   ~0002314

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.

Zaoshi

2018-07-29 11:18

reporter   ~0002316

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.

madshi

2018-07-29 11:37

administrator   ~0002317

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.

Zaoshi

2018-07-29 12:10

reporter   ~0002318

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.

madshi

2018-07-29 12:16

administrator   ~0002319

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.

Zaoshi

2018-07-29 12:38

reporter   ~0002320

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.

Nakasyma

2018-07-29 13:31

reporter   ~0002321

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)

madshi

2018-07-29 13:35

administrator   ~0002322

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.

Msarc

2018-08-08 08:34

reporter   ~0002329

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

madshi

2018-08-09 11:19

administrator   ~0002330

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.

Zaoshi

2018-08-09 19:39

reporter   ~0002331

Disabling Focus Assist helps with issues that occur when switching to FSE, but it doesn't seem to do anything for windowed fullscreen.

Msarc

2018-08-10 11:23

reporter   ~0002332

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".

madshi

2018-09-30 17:30

administrator   ~0002430

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.

ProphetWild

2022-09-23 06:17

reporter   ~0002936

I've been having this issue for a few years now. The render queue will fall to 3-4/8 and I will drop frames. This happens randomly but I can also trigger it in windowed mode by mousing over/pulling up the seek bar.
I have changed CPU and GPU as well as done clean installs of Windows 10 and 11 over the years and the issue persists. It does not happen in FSE.
I've tried different CPU/GPU queue values, vsync options, all of the flush options, and it still happens over all different content.
I've been using the HDR betas and it happens in those as well.
Really have no idea what it could be, I remember seeing something about the windowed mode having a weird interaction if you're running in 10bit/12bit but seems like a strange bug.

madshi

2022-09-23 08:41

administrator   ~0002937

If it doesn't happen in FSE mode, why don't you simply use that? It's there for reasons like this... :-)

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
2022-09-23 04:56 ProphetWild Status closed => feedback
2022-09-23 04:56 ProphetWild Resolution fixed => reopened
2022-09-23 04:56 ProphetWild madVR Version 0.92.14 => 0.92.17
2022-09-23 04:56 ProphetWild Media Player (with version info) MPC-HC (64-bit) 1.7.13 (e37826845) => MPC-HC (64-bit) 1.9.23
2022-09-23 04:56 ProphetWild Splitter (with version info) LAV Splitter: 0.72.0.0 => LAV Splitter: 0.76.1
2022-09-23 04:56 ProphetWild Decoder (with version info) LAV Video: 0.72.0.0 => LAV Video: 0.76.1
2022-09-23 04:56 ProphetWild Decoding DXVA2 Native => DXVA2 Copyback
2022-09-23 04:56 ProphetWild Problem occurs with mode all modes => windowed mode
2022-09-23 04:56 ProphetWild GPU Model GeForce GTX 1070 => GeForce RTX 3090
2022-09-23 04:56 ProphetWild GPU Driver Version 398.36 => 516.94
2022-09-23 06:17 ProphetWild Note Added: 0002936
2022-09-23 08:41 madshi Note Added: 0002937