Media Player .NET (MPDN) - D3D HQ GPU Video Renderer [v2.49.0/v1.31.0 27 Dec 2018]

[ryrynz]

Originally Posted by trandoanhung1991

Anyone else having a problem with the reclock script? It's causing, for me, a lot of dropped and delayed frames. I'm using SVP with it, might that be the problem?

Yeah possibly.. why not disable it and see, it's a quick test. SVP can be pretty intensive.

[Zachs]

I don't think you should use Reclock with SVP. MPDN doesn't know what the actually frame rate is in that case since SVP can change it at any time.

[Zachs]

Originally Posted by ryrynz

Ah, we've been down this road before. Love me some benches..

Got a good name for this too Zach..

The Determinator

That's definitely doable with player extensions and render scripts. I wouldn't do it yet though since the algos are still changing and being optimised.

[trandoanhung1991]

Originally Posted by ryrynz

Yeah possibly.. why not disable it and see, it's a quick test. SVP can be pretty intensive.

Yep, disabling the script keeps the frame rate stable.

Originally Posted by Zachs

I don't think you should use Reclock with SVP. MPDN doesn't know what the actually frame rate is in that case since SVP can change it at any time.

Something happened when both of them are on which causes frame rate to drop below 59, down to as low as below 40 for brief moments, which causes drops and delays.

I have another question. Is it possible to get MPDN to play BDMVs folders?

[aufkrawall]

Shouldn't MPDN be able to open jpegs via LAV the same way as it can open pngs?
It can't open this one:
http://abload.de/img/testqwud0.jpg

[Zachs]

I just tried your JPG with GraphStudioNext (LAV Splitter Source --> LAV Video Decoder --> Video Renderer) and it couldn't display anything too.

[Zachs]

Originally Posted by trandoanhung1991

I have another question. Is it possible to get MPDN to play BDMVs folders?

I don't think that's supported by LAV Splitter Source?

[nevcairiel]

Originally Posted by Zachs

I don't think that's supported by LAV Splitter Source?

It is, tell it to open the index.bdmv (for automatic playlist selection) or one of the playlists in the PLAYLIST folder, and it'll work.

[Zachs]

Test Build for MPDN v2.41.0 (Build 3320) is out (use it with the latest GitHub extensions) - http://mpdn.zachsaw.com/Test%20Builds/3320/

NNEDI3 (SM5.0) now has an alternate code path under optimizations. As I only have access to an old Fermi and an Intel P4600 currently, I can't say how much better or worse it'll perform beyond these two GPUs. My old first gen Fermi (NVS4200M) doesn't like this code path at all. However, on the P4600, it has sped up NNEDI3 by up to 100% in some situations. On the Intel GPU, the SM version was already much faster than the OpenCL version without this alternate code path but it is now more than twice as fast. The Intel GPU seems to always prefer the "Scalar and Small Code" optimization with alternate path whereas the first gen Fermi absolutely hates it (twice as slow).

I'd like your help now to find out what the best option for your GPU is - and I suspect different generations of GPU even from the same vendor will prefer different optimizations.

Nvidia and Intel GPUs have starkly contrasting fortunes with the alternate code path, so I'm very curious to see what it would do with an AMD GPU as well as other generations of Nvidia GPUs.

[aufkrawall]

I can confirm your Fermi findings with Maxwell.
Using alternate code path doubles GPU load to 100% and I have lots of dropped frames. No matter if vector or scalar.

[Anima123]

720p -> 1080p, GTX 880M + HD 4600 Optimus, Alternate weight access method used

neurons 64 + 64,
Prefer Scaler: 61ms
Prefer Vector: 61ms
Prefer Scaler & Small Code: 106ms (picture errors)
Prefer Vector & Small Code: 113ms (picture errors)

The error picture looks like:
https://www.dropbox.com/s/sb621se03b..._Code.png?dl=0

Normal picture without Small Code:
https://www.dropbox.com/s/al8rhyc3ca...Image.png?dl=0

neurons 32 + 32,
Prefer Scaler: 37ms
Prefer Vector: 37ms
Prefer Scaler & Small Code: 60ms (picture error)
Prefer Vector & Small Code: 59.4ms (picture error)

neurons 32 + 16,
Prefer Scaler: 33.2 ms
Prefer Vector: 33 ms
Prefer Scaler & Small Code: 33.5ms (picture error)
Prefer Vector & Small Code: 34.2ms (picture error)

Edit: Using traditional method, avoid branch is the most efficient for my GPU,
neurons 64 + 64: 33.2 ms
neurons 32 + 32: 23.2 ms
neurons 32 + 16: 19.1 ms

[Zachs]

Looks like it's not just Fermi hating this new path. The whole NVIDIA product line hates it. Try it with your HD4600, you'll find the results to be the complete opposite!

[huhn]

my r9 270 doesn't really care maybe 0.5 ms difference. prefer scalar was the fastest mode with and without alternative weight access method.

[aufkrawall]

Would it make any difference to use DirectCompute instead of SM 5.0?

[Zachs]

It really comes down to how well the driver maps the code to the underlying resource. Theoretically they should all perform equally but as we've seen it's very erratic - the same code using different version of Microsoft shader compiler would make a lot of difference.

[aufkrawall]

Originally Posted by huhn

my r9 270 doesn't really care maybe 0.5 ms difference. prefer scalar was the fastest mode with and without alternative weight access method.

Is there a huge difference for you in GPU load, clocks and render times with prefer scalar over OpenCL?

[ryrynz]

As you know my 750 Ti loves avoiding branches so this alternative method is of no use to me.

I will mention however that each option was slower with the alternative weights and the small code options
gave me some lovely artifacting I could probably printscreen and sell as art.

But anyway, OpenCL is still faster for me by 6ms or so so I'll just stick with that for now until I get a 960 or something.
FWIW it's quite nice getting 256/16 neurons at only 66% GPU load & 27 ms render on a low end graphics card like the 750 Ti
on 704x480 content. Some mighty bang for my buck right there, madVR has to sit on 64 neurons for the same level of performance.

[madshi]

Originally Posted by ryrynz

FWIW it's quite nice getting 256/16 neurons at only 66% GPU load & 27 ms render on a low end graphics card like the 750 Ti
on 704x480 content. Some mighty bang for my buck right there, madVR has to sit on 64 neurons for the same level of performance.

We're talking X/Y here, right? Does 256/16 look better than 64/64? In my experience 16 neurons doesn't handle certain edge angles well. So I'm not sure if it's a good idea to use 256/16 over 64/64. Have you compared this with test images etc?

[ryrynz]

Originally Posted by madshi

We're talking X/Y here, right? Does 256/16 look better than 64/64? In my experience 16 neurons doesn't handle certain edge angles well. So I'm not sure if it's a good idea to use 256/16 over 64/64. Have you compared this with test images etc?

I've done a quick comparison but not on test images, but my results echo exactly what Nevcairiel said, the second neuron count has significantly less impact than the first.
In fact I would not be able to spot the difference in a moving image it's that small.

I tested this on an anime image where lines are obviously all over the place and any drop in neuron count could be seen to negatively affect lines for fingers etc.
I know exactly what to look for having done comparisons with 64 vs 256 neurons many times and I did not see any drawbacks setting to only 16 neurons for the second value.
As is often often said, test images don't reflect real world results and although I'm sure you could find some small drawbacks, the benefits would surely outweigh them.

I think your own testing here would also conclude that allowing this second value to be set independently would be a good idea.

[Zachs]

Hi everyone,

Could you let me know if this MPDN test build 3338 makes OpenCL work again with the new Nvidia drivers?

Cheers.