View Issue Details

IDProjectCategoryView StatusLast Update
0000211madVRbugpublic2015-03-23 09:04
Reportercyberbeing Assigned Tomadshi  
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionno change required 
Platformx64OSWindows 7 SP1OS Version7601
Summary0000211: FLIPEX fails to activate when FSE Present in Advance disabled
DescriptionFLIPEX fails to activate for both Windowed mode (old path) as well as Overlay mode when FSE Present in Advance disabled. This issue seems to exist in all madVR releases (tested builds between 0.60 and 0.87.10).

Side note:
SWAPEFFECT=1 (DISCARD?) results in significantly lower GPU load than FLIPEX, allowing me to use higher NNEDI3 and Dithering settings in madVR (i.e. FLIPEX >90% load, dropped frames, 46ms render | DISCARD 75% load, no dropped frames, 38ms render). Maybe this should be made into a formal 'Trade quality for performance' setting when this bug is fixed. Though I'm a bit surprised the difference is as large as 20%, so maybe something else is broken as well?
Steps To Reproduce*Enable madVR debug mode
*Disable FSE Present in Advance
*Set Windowed mode backbuffers to 4
*Open video in Windowed mode
Result: Backbuffers limited to 3, debug log reports SWAPEFFECT=1 (Discard)

*Enable madVR debug mode
*Disable FSE Present in Advance
*Enable Overlay
*Open video in Windowed Overlay mode
Result: Error message, unable to create Overlay

__________


*Enable madVR debug mode
*Enabled FSE Present in Advance
*Set Windowed mode backbuffers to 4
*Open video in Windowed mode
Result: Backbuffers uses set value of 4, debug log reports SWAPEFFECT=5 (FlipEX)

*Enable madVR debug mode
*Enable FSE Present in Advance
*Enable Overlay
*Open video in Windowed Overlay mode
Result: Overlay created successfully
Additional Informationhttp://msdn.microsoft.com/en-us/library/windows/desktop/bb172612
TagsNo tags attached.
madVR Version0.87.10
Media Player (with version info)MPC-HC (1.7.5.65)
Splitter (with version info)LAV Splitter (0.61.1)
Decoder (with version info)LAV Video (0.61.1)
DecodingSoftware
Deinterlacingnone (progressive)
DXVA2 Scaling Activeno
Aero / Desktop CompositionOn
Problem occurs with modewindowed mode
GPU ManufacturerNVidia
GPU ModelGTX 770
GPU Driver Version337.61

Activities

cyberbeing

2014-05-16 13:54

reporter   ~0000637

Issue does not occur when Automatic FSE is disabled.

cyberbeing

2014-08-26 08:19

reporter   ~0000657

Triggering this issue also breaks DXVA (Native).

cyberbeing

2014-08-26 09:27

reporter   ~0000658

Workaround FSE (old mode):
*Disable Automatic FSE
*Disable FSE Present in Advance
*Open Video
*Re-enable Automatic FSE via Keyboard Hotkey (if desired)

Result:
*Bug is avoided for the entire madVR session

madshi

2015-03-22 15:08

administrator   ~0000809

Uhm, this is complicated.

First of all, FLIPEX and OVERLAY compete with each other. You can only use one or the other. Then, when disabling FSE Present in Advance, madVR has to use IDirect3D9 instead of IDirect3D9Ex, and IDirect3D9 doesn't support FLIPEX. See more details here:

https://msdn.microsoft.com/en-us/library/windows/desktop/bb172612(v=vs.85).aspx#D3DSWAPEFFECT_FLIPEX

Basically that means that when enabling Overlay or when disabling FSE Present in Advance, madVR can't use FLIPEX.

The reason why your GPU is faster with disabled "Present in Advance" is that in that presentation mode madVR only presents every video frame once. When using "Present in Advance", madVR has to present one video frame for every VSync interrupt, which of course costs some extra performance. This problem will probably go away when I (re)introduce a Direct3D11 presentation mode.

So, is there anything I need to do here? Or did my explanations clarify/solve everything in this bug report?

cyberbeing

2015-03-22 16:52

reporter   ~0000813

Last edited: 2015-03-22 17:15

You seem to be talking about two unrelated things.

The issue here is that disabling the 'FSE Present in Advance' option, disables FLIPEX globally no matter what mode is actually being used. Essentially you seem to be using IDirect3D9 globally, whenever there is a possibility that FSE (old mode) could be used. I don't see a reason for this, especially since FSE (old mode) seems to function just fine with FLIPEX using IDirect3D9ex, albeit slower.

FLIPEX is slower with with Windowed (old) & FSE (old), than using DISCARD. Neither of the 'old path' modes present frames in advance, so that cannot be related. The old paths should still be presenting each video frame only a single time even with FLIPEX, right?


DISCARD = SwapEffect 1 (madVR debug log)
OVERLAY = SwapEffect 4 (madVR debug log)
FLIPEX = SwapEffect 5 (madVR debug log)

Automatic FSE Enabled + FSE Present in Advance Enabled + Windowed mode (old mode) = FLIPEX used for Windowed/FSE
Automatic FSE Enabled + FSE Present in Advance Enabled + Windowed mode (new mode) = FLIPEX used for Windowed/FSE
Automatic FSE Enabled + FSE Present in Advance Enabled + Overlay = FLIPEX (FSE) and OVERLAY used

Automatic FSE Enabled + FSE Present in Advance Disabled + Windowed mode (old mode) = DISCARD used for Windowed/FSE
Automatic FSE Enabled + FSE Present in Advance Disabled + Windowed mode (new mode) = DISCARD used for Windowed/FSE
Automatic FSE Enabled + FSE Present in Advance Disabled + Overlay = DISCARD used for Windowed/FSE (Overlay error message)

Automatic FSE Disabled + FSE Present in Advance Disabled + Windowed mode (old mode) = FLIPEX used
Automatic FSE Disabled + FSE Present in Advance Disabled + Windowed mode (new mode) = FLIPEX used
Automatic FSE Disabled + FSE Present in Advance Disabled + Overlay = OVERLAY used


Automatic FSE Disabled + FSE Present in Advance Disabled = FLIPEX used (Windowed)

Automatic FSE Disabled + FSE Present in Advance Disabled + Automatic FSE Re-enabled via Hotkey
= FLIPEX used for FSE (old mode) & Windowed

madshi

2015-03-22 17:19

administrator   ~0000814

I don't really see why FLIPEX would be slower than DISCARD. According to the MS documentation it seems that it should be the other way around. That's why I thought that it might have to do with the new mode vs old mode. If you're sure that using the old mode works faster with DISCARD, I can change that, not a big problem.

I do use IDirect3D9 globally if the old FSE mode is used because the old FSE mode doesn't work with IDirect3D9Ex. At least that was the case when I first implemented it. Maybe newer OSs are more flexible there.

Overall, I'm not quite sure what I should do now. Your bug report contains a lot of information, but no direct "this should be done that way". Or "it's wrong to do this". Originally it seems you reported as a bug that FLIPEX isn't always used. But later you seem to prefer using DISCARD. So I'm not sure now if you want FLIPEX now to be always used, or DISCARD to be always used.

So: What exactly do you want me to change?

cyberbeing

2015-03-22 18:19

reporter   ~0000816

Last edited: 2015-03-22 18:24

Exactly what you should change is up to your discretion.

What bothers me, is that the current is behavior and interaction between options is inconsistent and unexpected:


*FSE options should not change Windowed Mode SwapEffect behavior or break Overlay.

*Pick a SwapEffect for each FSE & Windowed mode to always be used no matter what options are selected.

*Select use of IDirect3D9ex or IDirect3D9 based on OS support, rather than madVR options.

*madVR OSD reports Windowed (new path) when IDirect3D9 DISCARD is active, even though I assume that makes it impossible to present frames in advance.

*It may be worthwhile to test some of the other SwapEffect modes like FLIP and COPY, so see how they behave in comparison to DISCARD. Also if IDirect3D9ex behaves any better than IDirect3D9 when not using FLIPEX on modern OS.

It's also noteworthy that Windowed (old path) has a cosmetic anomaly when resizing the MPC-HC window with IDirect3D9 DISCARD mode. That alone make me hesitant to say you should make that the default. The question is if the same occurs with IDirect3D9ex DISCARD, or even FLIP or COPY.


If you want a simple solution, I'd say to just use IDirect3D9ex FLIPEX for all FSE and Windowed modes (new & old paths) on Windows 7 and newer. Optionally, you could add a option under Trade Quality for Performance to disable FLIPEX for Windowed & FSE 'old path' while still using a IDirect3D9ex device. If this is the optimal or correct solution, I have no idea.

madshi

2015-03-22 19:13

administrator   ~0000818

You make it sound so easy.

> FSE options should not change Windowed Mode
> SwapEffect behavior or break Overlay.

It is technically impossible to use FLIPEX or OVERLAY when using IDirect3D9. So *if* I have to use IDirect3D9, what you're suggesting is technically impossible.

> Pick a SwapEffect for each FSE & Windowed mode to
> always be used no matter what options are selected.

See above.

> Select use of IDirect3D9ex or IDirect3D9 based on
> OS support, rather than madVR options.

This really is the key question: Can I use IDirect3D9Ex for the old FSE mode? I've just done a quick test, and although it appears that playback works fine, the backbuffer queue never fills. I'm not sure if that was the issue I had with IDirect3D9Ex when using the old FSE mode, or if it was something else. But it does not seem as if I could just enable IDirect3D9Ex for all modes. An empty backbuffer queue is a serious problem.

And as long as I have to use IDirect3D9 for the old FSE mode, all other requests you made are technically impossible.

> madVR OSD reports Windowed (new path) when IDirect3D9
> DISCARD is active, even though I assume that makes it
> impossible to present frames in advance.

I don't think that FLIPEX is needed for the new Windowed mode, although it's probably more efficient, according to the MS documentation.

> It may be worthwhile to test some of the other SwapEffect
> modes like FLIP and COPY, so see how they behave in
> comparison to DISCARD. Also if IDirect3D9ex behaves any
> better than IDirect3D9 when not using FLIPEX on modern OS.

If I could use IDirect3D9Ex for all modes, I would do that in a heartbeat. IDirect3D9Ex has many advantages I'd love to have. But on a quick check, IDirect3D9Ex doesn't work well with the old modes. One queue or another isn't filling. I think it's some sort of threading block in IDirect3D9Ex. The old modes rely on using multiple different threads to render & present etc. The new modes do everything in one thread. It seems that IDirect3D9 works well with the multi-threaded approach, but IDirect3D9Ex does not, at least not in FSE mode. That's what I seem to remember.

I would like to use IDirect3D9Ex, but I can't (the queues don't fill). I would like to use FLIPEX always, but I can't (IDirect3D9 doesn't support it). I would like to support OVERLAY always, but I can't (IDirect3D9 doesn't support it).

So at this point I don't really know if I can do anything about this at all.

Or do your queues perfectly fill, if you try to make IDirect3D9Ex work with the old FSE mode?

cyberbeing

2015-03-22 20:53

reporter   ~0000823

Last edited: 2015-03-22 21:33

> I don't think that FLIPEX is needed for the new Windowed mode

The render queue doesn't fill properly, always sitting at 'rendered: ++' around 90% of the time, even if you have the GPU queue size set much higher. This has a side effect of causing the backbuffer and present queues to not fill properly.

No such issue with the render queue on Windowed (old path) or FSE (old path) with DISCARD.

Have you tried using IDirect3D9 FLIP instead of IDirect3D9 DISCARD in this instance?


> Or do your queues perfectly fill, if you try to make IDirect3D9Ex work with the old FSE mode?

According to the madVR debug log, it appears to stay at a solid 'buffered: ++' the entire time and never fills beyond that. So you seem to be correct, that the queues do not fill properly with FSE (old path) and FLIPEX.

Have you tried using DISCARD with IDirect3D9Ex instead of IDirect3D9? As far as I can tell, IDirect3D9Ex is not limited to only using FLIPEX.

madshi

2015-03-22 22:45

administrator   ~0000833

IDirect3D9 FLIP doesn't help. And using DISCARD with IDirect3D9Ex doesn't fill the queues when using the new windowed mode.

One bug is that when using IDirect3D9 (to make the old FSE mode work with full queues) I can't use the new Windowed mode. Currently it's tried, but doesn't work correctly. I will fix that. Anything else I can do? I think not, sadly...

cyberbeing

2015-03-22 23:13

reporter   ~0000834

It does seem like this problem is more complex than it originally appeared.

Is it possible to switch between IDirect3D9 and IDirect3D9ex while madVR is running? Allow only FSE (old path) to use IDirect3D9 DISCARD, but automatically create a IDirect3D9ex device with FLIPEX or OVERLAY when needed? Prevent FLIPEX from ever being used with FSE (old mode), including my workaround?

madshi

2015-03-22 23:22

administrator   ~0000835

The problem is not FLIPEX, the problem is the old FSE mode with IDirect3D9Ex. That just doesn't seem to work.

It would be theoretically possible to use two different devices for presentation, one for windowed mode and one for FSE mode. However, IDirect3D9 isn't able to share resources, so I'd have to clear all queues, every time I switch between the devices. Furthermore, switching between windowed and FSE mode would be much slower than it is now. So overall not a very promising solution. And to be honest, even trying to make that work would cost me a *LOT* of development resources, and I'd much rather spend my time on something that benefits most users, instead of trying to improve some old mode which most users aren't using, anymore. You're one of very few people who're still using the old mode. Working on a D3D11 presentation mode with all its potential benefits (like 10bit output mode) etc sounds much more promising. The D3D11 mode should offer comparable GPU performance to the old mode, I think.

cyberbeing

2015-03-23 00:12

reporter   ~0000836

Last edited: 2015-03-23 00:12

> You're one of very few people who're still using the old mode.

I actually use FSE (new mode) with Windowed (old mode), so I'm not really affected by this.

I only discovered this issue, since this was around the time you were asking on the forums if anyone still used the 'old path' modes. I figured it was a good time to re-test performance difference between FSE (new mode) & (old mode), only to discover this unexpected behavior which seemed to be skewing my results in Windowed mode.

Since it seems that no further action is required, I'm just adding what's below for documentation purposes.

__

The following combination of settings results in madVR using IDirect3D9 instead of IDirect3D9ex on Win7+:

*FSE Present in Advance Disabled + Automatic FSE enabled

___


Side-effect of madVR using IDirect3D9 instead of IDirect3D9ex:

*Overlay mode is unable to be used

*Windowed mode will use IDirect3D9 SwapEffect DISCARD

___

madshi

2015-03-23 09:04

administrator   ~0000837

I did do one change/fix, though: If IDirect3D9 is used, I will also automatically switch to the old Windowed mode.

Issue History

Date Modified Username Field Change
2014-05-16 13:36 cyberbeing New Issue
2014-05-16 13:54 cyberbeing Note Added: 0000637
2014-08-26 08:19 cyberbeing Note Added: 0000657
2014-08-26 09:27 cyberbeing Note Added: 0000658
2015-03-22 15:08 madshi Note Added: 0000809
2015-03-22 15:09 madshi Assigned To => madshi
2015-03-22 15:09 madshi Status new => feedback
2015-03-22 16:52 cyberbeing Note Added: 0000813
2015-03-22 16:52 cyberbeing Status feedback => assigned
2015-03-22 16:53 cyberbeing Note Edited: 0000813
2015-03-22 16:53 cyberbeing Note Edited: 0000813
2015-03-22 16:56 cyberbeing Note Edited: 0000813
2015-03-22 16:56 cyberbeing Note Edited: 0000813
2015-03-22 16:58 cyberbeing Note Edited: 0000813
2015-03-22 16:59 cyberbeing Note Edited: 0000813
2015-03-22 16:59 cyberbeing Note Edited: 0000813
2015-03-22 17:01 cyberbeing Note Edited: 0000813
2015-03-22 17:01 cyberbeing Note Edited: 0000813
2015-03-22 17:15 cyberbeing Note Edited: 0000813
2015-03-22 17:19 madshi Note Added: 0000814
2015-03-22 17:19 madshi Status assigned => feedback
2015-03-22 18:19 cyberbeing Note Added: 0000816
2015-03-22 18:19 cyberbeing Status feedback => assigned
2015-03-22 18:24 cyberbeing Note Edited: 0000816
2015-03-22 19:13 madshi Note Added: 0000818
2015-03-22 19:14 madshi Status assigned => feedback
2015-03-22 20:53 cyberbeing Note Added: 0000823
2015-03-22 20:53 cyberbeing Status feedback => assigned
2015-03-22 20:53 cyberbeing Note Edited: 0000823
2015-03-22 21:33 cyberbeing Note Edited: 0000823
2015-03-22 22:45 madshi Note Added: 0000833
2015-03-22 22:45 madshi Status assigned => feedback
2015-03-22 23:13 cyberbeing Note Added: 0000834
2015-03-22 23:13 cyberbeing Status feedback => assigned
2015-03-22 23:22 madshi Note Added: 0000835
2015-03-22 23:23 madshi Status assigned => feedback
2015-03-23 00:12 cyberbeing Note Added: 0000836
2015-03-23 00:12 cyberbeing Status feedback => assigned
2015-03-23 00:12 cyberbeing Note Edited: 0000836
2015-03-23 00:13 cyberbeing Status assigned => resolved
2015-03-23 00:13 cyberbeing Resolution open => no change required
2015-03-23 09:04 madshi Note Added: 0000837
2015-03-23 09:04 madshi Status resolved => closed