madVR - high quality video renderer (GPU assisted)

[P.J]

Any real-world difference between madVR and EVR? found no good topic about it =T

[CarlosCaco]

Originally Posted by P.J

Any real-world difference between madVR and EVR? found no good topic about it =T

Just give a try and see with your eyes...

[Asmodian]

Originally Posted by chros

What is Power in % anyway?
Can you use graphs of nvidiainspector with that card?

100% should be ~250W for this card.

It shows the same pattern with nvidiaInspector as well:

[DragonQ]

Originally Posted by P.J

Any real-world difference between madVR and EVR? found no good topic about it =T

Big differences for me are smooth motion and much nicer SD -> HD upscaling. Even if you can't tell the difference between chroma upscaling methods these make obvious improvements.

[leeperry]

Originally Posted by P.J

Any real-world difference between madVR and EVR?

All placebo, really.

[ryrynz]

Originally Posted by leeperry

All placebo, really.

This is literally the last thing I'd ever expect you to say.

@P.J Seriously though, read the OP.

[chros]

Originally Posted by ryrynz

This is literally the last thing I'd ever expect you to say.

Originally Posted by Asmodian

100% should be ~250W for this card.

It shows the same pattern with nvidiaInspector as well:

Hmm... Does the "Voltage" graph working for that card?

[ashlar42]

Originally Posted by leeperry

All placebo, really.

Quick, somebody call an exorcist. An entity has taken hold of leeperry's body!

[Asmodian]

Originally Posted by chros

Hmm... Does the "Voltage" graph working for that card?

nvidiaInspector's doesn't but Afterburner's does:

Edit: I found the cause, it was a polling issue, simply the sampling interval drifting in and out of phase with a very spiky instantaneous power usage.

Increasing the sample rate 10x, to once every 100ms, makes what is going on obvious:
Titan X (Pascal) with: madVR 1000msec, madVR 100ms.


Sorry for all the images.

I think the Titan X (Pascal) actually powers down after every frame is rendered, in my case it only takes 19ms to render each frame so it is using a lot less power for 22.7ms out of every 41.7.

[aufkrawall]

Can confirm this:

[Asmodian]

Originally Posted by aufkrawall

Can confirm this:

Very nice! Thanks.

C1E For GPUs.

[Betroz]

Originally Posted by Asmodian

C1E For GPUs.

Maybe nVidia have made some adjustments to their Turbo Boost 3.0 technology or something. So this could be by design.

[Asmodian]

Originally Posted by Betroz

Maybe nVidia have made some adjustments to their Turbo Boost 3.0 technology or something. So this could be by design.

Yes, I am sure it is by design. It isn't turbo boost though, that changes the clock speeds based on power use and temperature. This is more like the enhanced halt states in CPUs; parts of the core turn off and on over very small timescales, but the overall clock speed doesn't change.

[e-t172]

Public service announcement: if you're experiencing A/V sync issues (specifically, video lags behind audio) in windowed mode (full screen or otherwise), you might want to take a look at http://bugs.madshi.net/view.php?id=434. I believe I have seen related problems being reported in this thread at some point, with people suspecting Windows 10 to have something to do with it.

[Asmodian]

Originally Posted by e-t172

Public service announcement: if you're experiencing A/V sync issues (specifically, video lags behind audio) in windowed mode (full screen or otherwise), you might want to take a look at http://bugs.madshi.net/view.php?id=434. I believe I have seen related problems being reported in this thread at some point, with people suspecting Windows 10 to have something to do with it.

Hmm, quite interesting, have you checked windowed overlay? Another data point to try to isolate it would be good.

(it seems likely that it is OK as well as it is similar to DX9 Old Path)

edit: Another question, how big is your present queue?

[e-t172]

Good idea. I just did the test for D3D fullscreen overlay (everything else reset to defaults), and as you suspected there is no delay in this mode.

[Sunset1982]

I did some further investigations regarding the wrong composition rate.

I found out, that since the Win10 Anniversary Update the composition rate of 23,976 movies is shown as 24hz instead of the correct 23,976hz.

I don't know what the composition rate exactly means and if this bug leads to any kind of playback problems or framedrops, but with the 1511 build the composition rate is always shown as the correct 23,976 hz. With Windows 10 build 1607, in D3D11 / 10 bit / FSE mode and in 3D mode (D3D11 /8 bit / FSE) the composition rate is shown as 24hz instead of 23,976 hz. I reinstalled Win10 with 1511 build and it worked as it should. Updated to 1607 and it's broken again. So this is clearly an issue with Win10 anniversary update and madvr's FSE D3D11 mode. This happens with my RX480 and my GTX1060 too.

Used latest crimson 16.9.1 drivers, latest mpc-hc, lav, madvr and xysubfilter builds.


@madshi: Is this a known bug? Do I have to expect any kind of playback problems?

[e-t172]

Originally Posted by Asmodian

edit: Another question, how big is your present queue?

I can see why you would ask that As mentioned in the bug report, all tests were done with the default settings, i.e. 8 frames to present in advance. I know for a fact that the same issue (with the same amount of delay - it's not correlated) occurs with a queue size of 4 because that's the setting I normally use.

I tried to test 16 frames to present in advance but, amazingly, the GPU driver crashes instantly as soon as I try to go full screen with that setting in place. Interesting bug. I suspect that has something to do with the fact that full screen in my setup means 2160p (4K), maybe 16 times 2160p is asking for too large a buffer, i.e. it triggers an overflow bug somewhere in the GPU driver or something.

[Asmodian]

Originally Posted by e-t172

I can see why you would ask that As mentioned in the bug report, all tests were done with the default settings, i.e. 8 frames to present in advance. I know for a fact that the same issue (with the same amount of delay - it's not correlated) occurs with a queue size of 4 because that's the setting I normally use.

I tried to test 16 frames to present in advance but, amazingly, the GPU driver crashes instantly as soon as I try to go full screen with that setting in place. Interesting bug. I suspect that has something to do with the fact that full screen in my setup means 2160p (4K), maybe 16 times 2160p is asking for too large a buffer, i.e. it triggers an overflow bug somewhere in the GPU driver or something.

Thanks for the extra info, a truly annoying issue. This makes me glad I am using Overlay again.

I can confirm the crash when presenting 16 frame in advance, the Nvidia driver doesn't like it at all. I am only on 2560x1440 too and 14 frames works properly. I remember this setting used to only go up to 15?

Edit: DX11 will only use 15 when set to 16, but DX9 Full Screen Exclusive is happy even with 16 frames in advance.

[aufkrawall]

What exactly do you do to reproduce the crash? I don't seem to be able to reproduce it.