View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000578 | madVR | bug | public | 2018-09-25 22:41 | 2018-09-29 14:29 |
| Reporter | VPupkin | Assigned To | madshi | ||
| Priority | high | Severity | major | Reproducibility | always |
| Status | closed | Resolution | no change required | ||
| Platform | PC | OS | Windows | OS Version | 7 |
| Summary | 0000578: Render queue often dropping | ||||
| Description | A problem appeared today - the render queue often gets empty during playback, while the decoder and upload queues are stable, so frames drop actively. The CPU/GPU buffers are set to 64/20 and I usually run in exclusive fullscreen mode, but the same thing happens in windowed mode. I've already tried everything I could. I updated GPU driver twice, now it's the newest. I switched the renderer settings (desktop composition, separate device, flushing after intermediate already set) - nothing. I've monitored performance during playback - CPU and GPU are not fully loaded, there's a plenty of system and video memory available and all the GPU indicators that NVidia inspector shows (including GPU temp) look fine. I've even checked the DPC latencies, but they also look awesome. There was a similar topic here with Windows 10 involved, but I have Windows 7. Apparently it's the renderer's fault, so what is going on? | ||||
| Additional Information | I'm using SVP for smooth motion on a CRT monitor at 75 Hz. The monitor is attached to the laptop and is the only active one. Sometimes I see frame drops even with the queue filled, but the drop counter isn't always showing them. | ||||
| Tags | No tags attached. | ||||
| madVR Version | 0.92.14 | ||||
| Media Player (with version info) | MPC-BE 1.5.2 (build 3788) beta | ||||
| Splitter (with version info) | MPC Matroska Source (?) | ||||
| Decoder (with version info) | MPC Video Decoder (FFMpeg libavcodec 58.20.103) | ||||
| Decoding | Software | ||||
| Deinterlacing | none (progressive) | ||||
| DXVA2 Scaling Active | no | ||||
| Aero / Desktop Composition | On | ||||
| Problem occurs with mode | all modes | ||||
| GPU Manufacturer | NVidia + Intel | ||||
| GPU Model | GT 630M + HD Graphics 3000 | ||||
| GPU Driver Version | 391.35 (NVidia) | ||||
|
|
The problem appeared today - so it's a new problem? What has changed since yesterday? Does the problem also occur without SVP? |
|
|
It's not the first time I encounter a problem with frame drops, but in this exact form it is the first time since I changed something in playback. Yesterday I was watching a movie (by the way it was 16:9 i.e. bigger frame size than this) and with the buffer sizes mentioned it managed almost fine. If a buffer amount decreased, it started with decode buffer as it is meant to be. I haven't changed anything since yesterday, and I didn't test it without SVP. Actually watching it without SVP doesn't make any sense to me - I'm already used to good picture. Another thing worth mentioning - a couple of days ago (before driver updates) I experienced a different problem - the present time in renderer statistics was almost zero (unlike usual 4 ms or something), but after a couple of minutes CPU load jumped resulting in horrible drops. The next morning everything got back to normal (hadn't even rebooted the system). And one more - even now, after driver updates, switching from madVR to EVR is immediately sending the system to BSOD. Don't remember for sure, when it started. |
|
|
I don't think you really answered my question: If this problem appeared today, what exactly has changed since yesterday? E.g. did you install different drivers? Did you install an OS update (or did the OS update itself)? Did you change madVR or media player or LAV or SVP settings? Something else you changed? *Something* must have changed if it worked well yesterday, but not today, right? So the proper way to debug this issue is to figure out what changed and then maybe revert that change, or at least analyze which exact change caused the issue. BSODs are usually driver bugs. |
|
|
I know what you mean but I've told that I haven't changed anything since yesterday. The drivers are the same, OS updates are disabled, madVR and player options unchanged, player's not using LAV and the only possible change in SVP is the general quality slider, but it's unlikely to cause such a trouble. Tell me what this upload queue is. Decoder queue is the decoder frame output, renderer queue is the renderer's output, and what is upload queue between them? This is relevant because when frames drop, the renderer queue falls, while the upload stays stable. |
|
|
The upload queue is copying the decoded frames from System RAM to GPU RAM. Basically the decoded frames are "uploaded" to the GPU. Well, it's a mystery, then. If it worked well yesterday and doesn't today, something MUST have changed, no? If nothing else, maybe the constellation of the planets? |
|
|
I don't know what it could be. It's the same mystery as the zero present time and BSOD with EVR. So let's find the reason directly. There's a drop at the renderer queue, so why would frames stall in the renderer? Is it renderer algorithm slowing everything down? And what benchmark can I use to discover what is happening at this particular link? |
|
|
It's not that easy. Rendering is a very complex thing. It involves multiple passes, eventually with some flushes in between, maybe interop between different APIs (e.g. D3D9 vs DirectCompute) etc etc. Add to that SVP, which might also use OpenCL in addition to all the above, which also puts stress on the GPU. All of that makes it difficult to figure out the exact reason why the render queue doesn't fill. Often it's simply a D3D9 API call which appears to be stuck, for no apparent reason. |
|
|
Most probably you have inserted some reporting tools in the renderer itself that can uncover these function call delays, like logs or advanced statistics. They are a must for troubleshooting in cases like this, so I assume you have. What are they? |
|
|
Sure, you can create debug logs, but they are MASSIVE. And as I said, in cases like your's it usually ends up in a Direct3D API call being stuck for no apparent reason. There's no way for me (or madVR) to find out why Direct3D sometimes gets stuck. The API calls succeed, they just take a long time, sometimes. |
|
|
Maybe, but I want to be sure. Tell me how to create a log and explain what to search for in it. And by the way, I have D3D11. 9 is an old version, isn't it? |
|
|
Still no answer. What's the matter? |
|
|
Is the problem fixed in this build? http://madshi.net/madVRxySubFilter.rar |
|
|
Wait a while. I asked you about the log, so answer that first. I don't want to shoot in the dark by switching to some other build, I want to find the exact reason first, so tell me about the logs. Are you making some kind of secret out of it or what? |
|
|
How about a little politeness? This is freeware, but you're not only impatient, but also demanding, and not polite at the same time. I'm tempted to close this bug report and ignore you. |
|
|
And here you are stooping to insinuations. Bad news for you, man. I've got immune resistance to this crap. I've come across so many whorish insinuators concealing their dirty motives behind them, that they don't affect me at all. So there's no impoliteness here, just inconvenient questions for you. Now it's crystal clear to me that you are hiding this logging information for some reason. This is stupid beyond the pale, because the main purpose of logs is troubleshooting on user side. So what is your game? Most probably you are afraid of me somehow using this information to write my own competitive renderer. Or you are just lazy about explaining the details. In the latter case it's totally your fault because such things must be described in the docs that you didn't bother to write (or hid so deeply that I couldn't find them). And if it's the first, then you are sacrificing your users' welfare to elimination of a highly unlikely threat, then whore is your name and you must be ashamed of that. |
|
|
Wow. Obviously my impression of your attitude was spot on. For your interest, it has been explained a million times on doom9 how to create debug logs. There's even a nice simple batch file in the madVR folder to do that. But anyway, I've no interest helping you any further. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2018-09-25 22:41 | VPupkin | New Issue | |
| 2018-09-26 00:10 | madshi | Note Added: 0002395 | |
| 2018-09-26 15:01 | VPupkin | Note Added: 0002396 | |
| 2018-09-26 15:16 | madshi | Note Added: 0002397 | |
| 2018-09-26 16:04 | VPupkin | Note Added: 0002398 | |
| 2018-09-26 16:19 | madshi | Note Added: 0002399 | |
| 2018-09-26 17:59 | VPupkin | Note Added: 0002400 | |
| 2018-09-26 18:12 | madshi | Note Added: 0002401 | |
| 2018-09-26 18:30 | VPupkin | Note Added: 0002402 | |
| 2018-09-26 19:14 | madshi | Note Added: 0002403 | |
| 2018-09-26 19:52 | VPupkin | Note Added: 0002404 | |
| 2018-09-28 17:56 | VPupkin | Note Added: 0002412 | |
| 2018-09-28 18:53 | madshi | Note Added: 0002415 | |
| 2018-09-29 10:55 | VPupkin | Note Added: 0002422 | |
| 2018-09-29 11:05 | madshi | Note Added: 0002423 | |
| 2018-09-29 14:21 | VPupkin | Note Added: 0002424 | |
| 2018-09-29 14:29 | madshi | Note Added: 0002425 | |
| 2018-09-29 14:29 | madshi | Status | new => closed |
| 2018-09-29 14:29 | madshi | Assigned To | => madshi |
| 2018-09-29 14:29 | madshi | Resolution | open => no change required |
