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

[huhn]

i can't find that option so i guess i still have the old version will try the newest version from github later. but this version is clearly slower strange...

[aufkrawall]

The option can be found in MPDN itself under video renderer -> general.
It should be there with normal final build.

Edit: Alternate weight access method for non-OpenCL is now also in final extensions.

[Zachs]

@huhn
Thanks for carrying out the NNEDI3 tests.

So the SM5.0 version is also worlds faster on AMD then. From memory, I thought the prefer vector method actually works best on AMD? Anyway this then really leaves Maxwell as the odd one out. My suspicion is NVIDIA simply haven't fully optimised the drivers for their new architecture yet.


The old test version and the latest version are exactly the same if you don't enable the new interop as far as OpenCL is concerned. I'm really at a loss to explain why the test build is so much faster.

[aufkrawall]

Maxwell is especially faster than Kepler in games that require excessive shader power.
It'd be strange if NNEDI3 SM couldn't be optimized for it in some way.

[Zachs]

Yeah my gut feeling tells me they just haven't optimised it enough yet. There's no reason for OpenCL to be faster than shader as far as my understanding goes. One is kind of a 'hard coded' version in how the hardware is used while the other gets dynamically mapped to the hardware resource by the driver. In fact it still puzzles me that NVIDIA prefers OpenCL for 128 and 256 neurons when both Intel and AMD hates it all across the board. The speedup from OpenCL to shader is almost exactly the same for both of them too.

[Zachs]

@huhn

Does Lav filter support DTS HD for both x86 and x64?
I should update the OP then...

[nevcairiel]

Does Lav filter support DTS HD for both x86 and x64?
I should update the OP then...

It does, without any external DLL.

[huhn]

@huhn
Thanks for carrying out the NNEDI3 tests.

So the SM5.0 version is also worlds faster on AMD then. From memory, I thought the prefer vector method actually works best on AMD? Anyway this then really leaves Maxwell as the odd one out. My suspicion is NVIDIA simply haven't fully optimised the drivers for their new architecture yet.

vector is way slower than pre scaler on my r9 270 is is nearly as slow as openCL in the old test build.

The old test version and the latest version are exactly the same if you don't enable the new interop as far as OpenCL is concerned. I'm really at a loss to explain why the test build is so much faster.

i have both version "installed" (the old test version is just in a folder and not installed properly) currently the main difference is that the old faster test build is anyCPU and the new test is done with the installer for x64 and the installer for extensions.

i just retested it the test build is clearly faster all other settings should be at default.

here are the results with the new interop api:

the new api uses 40 ms with the same test file. so it is faster and that quite a bit but of cause still no match to pre scaler.

and don't forget i test SD to FHD here the impact from the copyback problem with openCL should be way worse with higher resolutions so openCL doesn't stand a chance against SM 5.0

[ryrynz]

@huhn

Does Lav filter support DTS HD for both x86 and x64?
I should update the OP then...
Yup told you about that 😊

[Zachs]

Ah I thought it was WMA tracks.

[x7007]

If I have 970 GTX , should I select Always use new OpenCL Intertop API ? and OpenCL NNEDI3 extension ? ( I chose 64 neurons )

I'm using the old drivers in windows 10 the 353.49 . What will happen when I upgrade to 353.63 for example or newer . Should I still select those settings ? I have crazy good performance with this now, only 4.0-6.0 ms when checking CTRL + J.

[Zachs]

Does the OSD screen say "fallback has occurred in renderscript"? If it does, it means NNEDI3 isn't running.

The "Always use new OpenCL interop API" won't have any effects on drivers without the legacy interop support - i.e. it defaults to the new interop.

[Zachs]

vector is way slower than pre scaler on my r9 270 is is nearly as slow as openCL in the old test build.



i have both version "installed" (the old test version is just in a folder and not installed properly) currently the main difference is that the old faster test build is anyCPU and the new test is done with the installer for x64 and the installer for extensions.

i just retested it the test build is clearly faster all other settings should be at default.

here are the results with the new interop api:

the new api uses 40 ms with the same test file. so it is faster and that quite a bit but of cause still no match to pre scaler.

and don't forget i test SD to FHD here the impact from the copyback problem with openCL should be way worse with higher resolutions so openCL doesn't stand a chance against SM 5.0

Can you test with the same AnyCPU version to rule out any difference in settings?

If the new interop API is faster, it would suggest that it doesn't need copyback (i.e. latency is gone)! Not that it really matters any more, since AMD also prefers the shader version.

[huhn]

i took the Application.64.config made a copy and renamed it to Application.anyCPU.config and overwriten the old Application.anyCPU.config with it. they are now equally in speed.

in term of speed
SM5.0 pre scaler 32 ms
prefer vector 38 ms
SM 5.0 avoid branches 46 ms and dropping frames
openCL new API 40 ms
openCL normal 48+ ms frames drop like crazy

interesting is this. small code has no meaningful difference for me but prefer scaler & small code and alternate weights access method together are really slow 46ms+. while prefer vector & small code with and without alternate weights access method has about the same speed ~36 ms.

about the interop not sure SM 5.0 can be really slow as slow as slow as normal openCL so hard to judge. i may set my PCIe to 1.0 and test again. SM 5.0 shouldn't really care but openCL should lose a ton of speed if a copyback is used.

edit: +-2 ms for the same test is pretty normal the rendertimes are not really stable.

and a small news about the audio drop issue.
i have my r9 270 in my gaming PC now and just got the audio issue. i can't remember any issue on this PC before. so it can be assumed it is the card it self or the AMD driver.
i may do some better test or may not. moving PC hardware from one PC to the next is quite time consuming.

[Zachs]

I think it is safe to say the new interop gets rid of AMD copyback!

The 8ms difference is massive and nothing else would explain that difference. With NVIDIA where no copyback is involved either for new or old interop, the difference is around 0.1ms (in favour of the new interop).

Since the new interop is faster all around and doesn't harm Intel (Intel doesn't even like OpenCL NNEDI3), I'll make it use that by default in MPDN 2.42.0.

p.s. Thank you so much for testing. Your efforts are very much appreciated.

[x7007]

Is that good ?

Which version to use x86 , x64 or anycpu ? what does it mean any cpu ?

So if I update to nvidia newest drivers without legacy Interop I won't have the OpenCL and NNEDI3 support ?
http://s8.postimg.org/446k2pfz9/3333.jpg

[Zachs]

Is that good ?

So if I update to nvidia newest drivers without legacy Interop I won't have the OpenCL and NNEDI3 support ?

If you update to the latest drivers, you *will* still have OpenCL NNEDI3 support - that's the point of the new interop!

What I was trying to say was even if you don't check the new interop option, it will *still* use the new interop when the old interop isn't available. The option "forces" the use of the new interop path, but it doesn't mean the new path won't be used automatically when it has no other choice.

The warning you see below the new interop option is mainly only for old drivers that may not have the new interop path - all recent drivers have it.

The other thing you might want to do from your screen shot is revert "Max Quality" back to "Image Quality". The difference between max quality is so minute your eyes won't (at least shouldn't) be able to see it.

EDIT: And the reason you're getting such low render time is because you're not upscaling at all - you're actually downscaling.

[Zachs]

Shiandow has just committed a new feature that allows you to copy and paste your script chain. In going forward, you could now share your script chain with other users on the forum.

*Note: The latest commits require the unreleased MPDN v2.42.0 so don't try it yet.

e.g. SuperChromaRes --> Deband --> NNEDI3 256/256 --> Sinc-Blackman 2D

<ListOfPreset xmlns:yaxlib="http://www.sinairv.com/yaxlib/">
<Preset Name="SuperChromaRes" Guid="48fc4ac2-225d-4249-a3b3-c5a80362e268">
<Script yaxlib:realtype="Mpdn.Extensions.RenderScripts.Shiandow.SuperRes.SuperChromaResUi">
<Settings>
<Passes>2</Passes>
<Strength>0.5</Strength>
<Softness>0</Softness>
<Prescaler>True</Prescaler>
</Settings>
</Script>
</Preset>
<Preset Name="Deband" Guid="8791dff6-9588-429e-aff1-7ed8ea136879">
<Script yaxlib:realtype="Mpdn.Extensions.RenderScripts.Shiandow.Deband.DebandUi">
<Settings>
<maxbitdepth>8</maxbitdepth>
<power>0.5</power>
<grain>True</grain>
</Settings>
</Script>
</Preset>
<Preset Name="NNEDI3" Guid="ff8ade8c-6487-4f3c-8c55-491b691e63a1">
<Script yaxlib:realtype="Mpdn.Extensions.RenderScripts.Shiandow.NNedi3.NNedi3Scaler">
<Settings>
<Neurons1>Neurons256</Neurons1>
<Neurons2>Neurons256</Neurons2>
<CodePath>ScalarMad</CodePath>
<Structured>False</Structured>
</Settings>
</Script>
</Preset>
<Preset Name="EWA Scaler" Guid="753b685e-de61-49c1-94fa-d2d462c39356">
<Script yaxlib:realtype="Mpdn.Extensions.RenderScripts.Mpdn.EwaScaler.EwaScalerScaler">
<Settings>
<TapCount>Eight</TapCount>
<AntiRingingEnabled>True</AntiRingingEnabled>
<AntiRingingStrength>1</AntiRingingStrength>
<Scaler yaxlib:realtype="Mpdn.Extensions.CustomLinearScalers.SincBlackman" />
</Settings>
</Script>
</Preset>
</ListOfPreset>


Copy-and-pasting the code above into a blank script chain will allow you to duplicate my example script chain exactly.

[huhn]

I think it is safe to say the new interop gets rid of AMD copyback!

The 8ms difference is massive and nothing else would explain that difference. With NVIDIA where no copyback is involved either for new or old interop, the difference is around 0.1ms (in favour of the new interop).

Since the new interop is faster all around and doesn't harm Intel (Intel doesn't even like OpenCL NNEDI3), I'll make it use that by default in MPDN 2.42.0.

p.s. Thank you so much for testing. Your efforts are very much appreciated.

the test with PCIe 1.0 will show it for sure.

i use 256 neuron so the 8 ms just for better interop is very very huge the calculation shouldn't change what so ever and 256 is very slow. so yes it is likely not using an copy back operation.

what extension is used this time? i don't remember a extension all GPU share.

[Zachs]

No no. There isn't a common one - it's the same as the old interop where they have their own extensions. When I compared NVIDIA to AMD's difference in new and old interop speed, I didn't mean they both share the same API.

Anyway it'll still be good to find out if the copyback is truly eliminated - even if no AMD user will use the OpenCL version...

[huhn]

PCIe 1.0:
SM 5.0 prefer scaler 36 ms
openCL 53 ms
openCL new API 40 ms

numbers are very very unstable. but openCL new api is as fast as always so it can be assumed it isn't using a copyback.
pretty interesting that SM 5.0 got slower.

what so ever on my card prefer scaler is boss.

[Zachs]

Fantastic!

It's fully confirmed then - the new OpenCL interop doesn't have the copyback problem!

Thanks again huhn.

[x7007]

If you update to the latest drivers, you *will* still have OpenCL NNEDI3 support - that's the point of the new interop!

What I was trying to say was even if you don't check the new interop option, it will *still* use the new interop when the old interop isn't available. The option "forces" the use of the new interop path, but it doesn't mean the new path won't be used automatically when it has no other choice.

The warning you see below the new interop option is mainly only for old drivers that may not have the new interop path - all recent drivers have it.

The other thing you might want to do from your screen shot is revert "Max Quality" back to "Image Quality". The difference between max quality is so minute your eyes won't (at least shouldn't) be able to see it.

EDIT: And the reason you're getting such low render time is because you're not upscaling at all - you're actually downscaling.

So I don't understand, how can I upscale ? I should see Upscaling NNEDI3 right on the CTRL + J . why it's not active ?


My settings now are

Renderer Script - OpenCL NNEDI3 64-64
Luma Upscaler - Jinc 4 Taps , unselected Anti-Ringing
Chroma Upscaler - Same ^
Luma Downscaler - Same ^
Chroma Downscaler - SoftCubic Softness 75


Should I select Rely on DWM to handle the Vsync in windowed mode ?

[huhn]

this renderer doesn't show the used scaler in the OSD.

most default setting are default because they are the best so yes leave them as they are.

to use nnedi3 you need an file that needs upscaling a 1080p file on a 1080p screen isn't upscaled. chroma is a different story.

[ryrynz]

this renderer doesn't show the used scaler in the OSD.


Yeah, I've hit Zach up about this once before and I've wished it there many times since, been meaning to mention it again.. It's a pretty useful bit of info seen in madVR's OSD.

[Zachs]

Well the problem is MPDN doesn't know what scaler is actually being used in the render script.

[huhn]

and to be honest is that something really needed in a OSD?

[Zachs]

BTW, this could be done via player extensions. So please go ahead and add a new request on GitHub.

[aufkrawall]

Fantastic!

It's fully confirmed then - the new OpenCL interop doesn't have the copyback problem!

Thanks again huhn.
Kudos for your coder skills. :devil:

[burfadel]

What is the order of the way the filters are applied? Do the Luma and Chroma upscalers/downscalers work first, then the render script, or does the render script work first, then the upscalers/downscalers?

I would be thinking SuperRes etc would be better applied before upscaling or downscaling, but then I have a custom luma greyscale random noise shader that adds a bit of warmth to the picture (as in making it look perceptively better). This shader would be best applied last.

[Zachs]

It depends on what renderscript you're using - you could entirely or partially replace MPDN's scalers, or use MPDN's scalers for first phase chroma only as well as the final scaling to target size etc.

In your case, if you want to use SuperRes with a noise shader at the end, you'd have something like "SuperRes (NNEDI3) --> Resizer (100% target size) --> noise shader".

[x7007]

So how do I know if I use NNEDI3 and it works and I get the same quality from Madvr with potplayer ? If I have low Ms , that means it doesn't work or it has better performance than the normal OpenCL api ? I'm confused. I want to use this player but I can't be sure about some of the settings compare to the normal Madvr.


Which version to use x86 , x64 or anycpu ? what does it mean any cpu ?
Should I select Rely on DWM to handle the Vsync in windowed mode ?

[aufkrawall]

So how do I know if I use NNEDI3 and it works and I get the same quality from Madvr with potplayer ? If I have low Ms , that means it doesn't work or it has better performance than the normal OpenCL api ?

When an upscaling render script is selected without conditionals, it will always be used if upscaling is needed.
Even if target rectangle is just one pixel more than native resolution, it is used. Then you should also see render time increasing, in case of NNEDI3 by a lot.
If you want to use render scripts in a smarter way, you have to use conditional render scripts (see Wiki for MPDN extensions at Github).


I'm confused. I want to use this player but I can't be sure about some of the settings compare to the normal Madvr.

For chroma scaling, I suggest Sinc-Blackman AR with 6 or 8 taps.
Spline 4 taps is very similar to madVR Catmull-Rom (or is even equal), according to Zachs. So you might want to use it for downscaling.


what does it mean any cpu ?

I don't know.


Should I select Rely on DWM to handle the Vsync in windowed mode ?
Option is unchecked by default and this way, playback is totally reliable here. I suppose it shouldn't be enabled, unless there are problems.

[x7007]

When an upscaling render script is selected without conditionals, it will always be used if upscaling is needed.
Even if target rectangle is just one pixel more than native resolution, it is used. Then you should also see render time increasing, in case of NNEDI3 by a lot.
If you want to use render scripts in a smarter way, you have to use conditional render scripts (see Wiki for MPDN extensions at Github).


For chroma scaling, I suggest Sinc-Blackman AR with 6 or 8 taps.
Spline 4 taps is very similar to madVR Catmull-Rom (or is even equal), according to Zachs. So you might want to use it for downscaling.


I don't know.


Option is unchecked by default and this way, playback is totally reliable here. I suppose it shouldn't be enabled, unless there are problems.


Which movie will be upscaled ? 720p only on 1080p monitor resolution ? or 1080p on 2560x1440 monitor resolution ? a 1080p movie won't upscale on 1920x1080p monitor ?

When using Potplayer + Madvr + NNEDI3 it always upscaled my 1080p and 720p. Something I am missing here, I just don't why OpenCL NNEDI3 doesn't work because of the low ms.

[huhn]

nnedi3 is an image doubling scaler so no it is not used on a 1080p source on a 1080p screen.

are you sure you know what you want to achieve?

madVR can use nnedi3 for chroma but this is so placebo for movies...

and never forget if you don't see a difference you are just wasting power nothing else.

[ryrynz]

So I don't understand, how can I upscale ? I should see Upscaling NNEDI3 right on the CTRL + J . why it's not active ?

Your source is 1920 x 1080 and your display resolution is smaller because you're not running in fullscreen.
Waste of power using NNEDI3 on full HD content on a full HD screen or lower.


Should I select Rely on DWM to handle the Vsync in windowed mode ?

Nah, leave that one alone.

[Zachs]

I don't know if there are any official places left to download the Winamp SDK now that Winmap is dead, but there was an SDK to build DSP plugins, so you can equally just use that to use DSP plugins.
Laws cannot really prevent that.

Ah alas Winamp plugins are 32-bit only.

[x7007]

Your source is 1920 x 1080 and your display resolution is smaller because you're not running in fullscreen.
Waste of power using NNEDI3 on full HD content on a full HD screen or lower.



Nah, leave that one alone.

I watch Exclusive full screen, I just took the screenshot to show the settings.

So all you guys are saying NNEDI3 is not useful for 1080p even on Exclusive Full Screen mode , but only 720p ?

and if I have 2560x1440 resolution then upscaling will work because it will upscale a 1080p movie to the higher resolution .

Is that correct ?

What I want to understand hopefully is the MPDN versions.

What is the difference between x86 or x64 vs AnyCpu version ?

What should I use for the Chroma and Luma Upscaling and Downscaling settings ? I couldn't find such suggestions in the thread. do you guys have any suggestions ?

[Zachs]

Yes that is correct.

As for the question in regards to the different editions,
AnyCPU version will run on x86 and x64 OSes in its native mode (i.e. 32-bit process on 32-bit OS, 64-bit process on 64-bit OS).
x86 will run on both x86 and x64 Oses too but will run in WOW64 mode under x64 (as 32-bit process).
x64 can only run on x64 OSes.

[x7007]

Yes that is correct.

As for the question in regards to the different editions,
AnyCPU version will run on x86 and x64 OSes in its native mode (i.e. 32-bit process on 32-bit OS, 64-bit process on 64-bit OS).
x86 will run on both x86 and x64 Oses too but will run in WOW64 mode under x64 (as 32-bit process).
x64 can only run on x64 OSes.

So if I can't use NNEDI3 even in Exclusive full screen 1080p bluray movies MKV with 1080p resolution monitor.

Which Chroma and Luma Upscaling should I use ?

[ryrynz]

So if I can't use NNEDI3 even in Exclusive full screen 1080p bluray movies MKV with 1080p resolution monitor.


You can, it'll just upscale then downscale to your display resolution and you won't gain anything significant picture quality wise from it by doing so.


Which Chroma and Luma Upscaling should I use ?
Entirely up to you, depends on your source, display settings and personal preference of course. My recommendation would be to try out the EWA scalers for both chroma and luma.

[Zachs]

So if I can't use NNEDI3 even in Exclusive full screen 1080p bluray movies MKV with 1080p resolution monitor.

An honest question - do you know what NNEDI3 does?

[Dlget]

:p
Upscaling is not even used if you watch 1080p video in 1080p display.
so why bother about setting??? those settings are useful only for lower resolution video.

[ryrynz]

:p
Upscaling is not even used if you watch 1080p video in 1080p display.

Don't know why I thought it'd upscale regardless.. but NEDI has the option.
Hey Zach, what is the required upscale for MPDN to use NNEDI3? Doesn't appear to be 2x as I'm having it activate on a 1280 x 694 file > 1920 x 1200.

[Zachs]

It's always upscaled 2x. Then downscaled implicitly to target size using MPDN luma scaler.

[ryrynz]

I'll put that another way, how much of an upscale is required for NNEDI3 to activate?
Being a 2x upscale and without any options to specify otherwise you'd either assume it always activates or only activate when 2x upscaling is required to reach target size.

madVR has the options 'only if scaling factor is 2.0x/1.5x/1.2x or larger' or 'always if upscaling is needed'.

[aufkrawall]

As I already said, it doubles resolution if target rectangle is just one pixel more than source resolution (so always doubled if any upscaling is needed).
If you want to simulate madVR options, you have to use conditional render scripts.

e.g. choose script group, add script chain and in it add conditionals like:
If SourceSize.Width <= 1280 and SourceSize.Height <= 720 and NeedsUpscaling Use NNEDI3
You can also simulate madVR's sharpen after each doubling option with sharpen shaders (can be added into image processor render script). Instead of just NNEDI3 in the example above, you choose render script and in it you first run NNEDI3 doubling and afterwards image processor.
http://abload.de/img/1leaab.png (http://abload.de/image.php?img=1leaab.png)

http://abload.de/img/2swskg.png (http://abload.de/image.php?img=2swskg.png)

[ryrynz]

As I already said, it doubles resolution if target rectangle is just one pixel more than source resolution (so always doubled if any upscaling is needed).
If you want to simulate madVR options, you have to use conditional render scripts.


Missed that. Yeah figured, haven't looked into them much. Cheers.

[huhn]

it is at always but that's why this exist https://github.com/zachsaw/MPDN_Extensions/wiki/The-Conditional-Render-Script
but not sure if this can stop the quadrupling...

a lot of settings can't be used effectively without render script and/or conditional and it is relative complicated to use all this stuff.

for example getting nnedi3 only scaling when 2x or more scaling is needed is quite some work and needs so extra knowledge.

the Conditional system is extrem powerful but not that easy to use.

[aufkrawall]

I agree that some conditional options should be ported into the UI, probably not much work for the devs.
But afterall, conditionals are basically simple Excel when -> then functions. Not rocket science. :)