View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000568 | madVR | bug | public | 2018-07-29 10:08 | 2022-09-23 08:41 |
| Reporter | Zaoshi | Assigned To | madshi | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | feedback | Resolution | reopened | ||
| Platform | PC | OS | Microsoft Windows 10 Pro | OS Version | 1803 |
| Summary | 0000568: Render queue is not being filled | ||||
| Description | When 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 Reproduce | Set GPU queue size to maximum and play video in fullscreen windowed mode. | ||||
| Additional Information | I 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. | ||||
| Tags | No tags attached. | ||||
| madVR Version | 0.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 | ||||
| Decoding | DXVA2 Copyback | ||||
| Deinterlacing | auto mode | ||||
| DXVA2 Scaling Active | no | ||||
| Aero / Desktop Composition | On | ||||
| Problem occurs with mode | windowed mode | ||||
| GPU Manufacturer | NVidia | ||||
| GPU Model | GeForce RTX 3090 | ||||
| GPU Driver Version | 516.94 | ||||
|
|
|
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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) |
|
|
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. |
|
|
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 |
|
|
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. |
|
|
Disabling Focus Assist helps with issues that occur when switching to FSE, but it doesn't seem to do anything for windowed fullscreen. |
|
|
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". |
|
|
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. |
|
|
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. |
|
|
If it doesn't happen in FSE mode, why don't you simply use that? It's there for reasons like this... :-) |
| 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 |
