madVR - high quality video renderer (GPU assisted)

[ryrynz]

Originally Posted by XMonarchY

Damn, these are the responses that you get from ignorant folks at GeForce.com forums regarding inclusion of D3D9 - OpenCL interop into NVidia's Windows 10 drivers to support madVR's features - https://forums.geforce.com/default/t...good-/#4644241 ....

Don't worry about it, the interop isn't needed for NNEDI3 if madshi changes his code so it works again, apparently it's not a hard modification to make.
So just hold on to the old drivers until madshi fixes it.

[Zachs]

Originally Posted by ryrynz

Don't worry about it, the interop isn't needed for NNEDI3 if madshi changes his code so it works again, apparently it's not a hard modification to make.
So just hold on to the old drivers until madshi fixes it.

Yeah not hard at all. Took me a whole 15mins to do a quick hack version.

[madshi]

You mean using copyback? Or D3D11 interop with shared textures? Or SM 5.0? Three possible "solutions". Although OpenCL does seem to be faster, the more "modern" the GPU is, so I'd hate to lose it.

[kalston]

Originally Posted by madshi

You mean using copyback? Or D3D11 interop with shared textures? Or SM 5.0? Three possible "solutions". Although OpenCL does seem to be faster, the more "modern" the GPU is, so I'd hate to lose it.

That's a bummer, speed is actually quite crucial with NNEDI3...

[aufkrawall]

He didn't say he would drop OpenCL.
But I still stink it's important to have a reliable fallback in case OpenCL stops working for whatever reason (that just happened).

[ashlar42]

One question regarding debanding: considering the quality achievable with 10 bit output and quality dithering options... is debanding useful on a 10 bit display when rendering at 10 bit with madVR?

[ryrynz]

Originally Posted by ashlar42

One question regarding debanding: considering the quality achievable with 10 bit output and quality dithering options... is debanding useful on a 10 bit display when rendering at 10 bit with madVR?

It all depends on your media source. If you have banding in the source and you want it improved then yes.

[ajp_anton]

When using DXVA native to decode a 1280x718 video, two problems occur that don't with EVR:
1. An extra row (or two?) of grey pixels appear at the bottom (only when DXVA scaling is used), forcing a tiny stretch of the video to fit into 1-2 less pixels.
2. If scaled to 100%, the player crashes.

[michkrol]

I see none of the above on my setup:
MPC-HC 1.7.9.145 (x64) + internal LAVFilters, madVR 0.88.21, Geforce 750Ti (drivers v355.60), Windows 10 (x64).

Provide more info: system specs and sample file?

[Dlget]

updated to 355.60.
Now whenever i try to go into full screen MPC-be crashes.

355.69 out - D3D9-OpenCL no interop, right?

[Ver Greeneyes]

Originally Posted by XMonarchY

355.69 out - D3D9-OpenCL no interop, right?

The release notes don't list any changes. They probably just tweaked something to make them work well with the GeForce GTX 950.

[aufkrawall]

Unlikely that it has returned, but the release notes often don't list fixed issues.
It sounds stupid, but it really is that way.

[ajp_anton]

Originally Posted by michkrol

I see none of the above on my setup:
MPC-HC 1.7.9.145 (x64) + internal LAVFilters, madVR 0.88.21, Geforce 750Ti (drivers v355.60), Windows 10 (x64).

Provide more info: system specs and sample file?

On a ship with limited internet. Can't upload sample atm, so didn't think of providing more info either, sorry.

Windows 7 x64, MPC-HC (both 32- and 64-bit), LAV.
Intel i5-4200U.

Sample later.

[ryrynz]

Originally Posted by Ver Greeneyes

The release notes don't list any changes. They probably just tweaked something to make them work well with the GeForce GTX 950.

This driver is only for the GTX 950.

[Ver Greeneyes]

Yeah, but that doesn't really mean much. These drivers almost always work just fine on other cards, just need to add your device to nv_disp.inf/nv_dispi.inf. But I doubt they added back D3D9-OpenCl interop, which is the only thing that matters as far as this topic is concerned.

[ryrynz]

Originally Posted by Ver Greeneyes

Yeah, but that doesn't really mean much. These drivers almost always work just fine on other cards, just need to add your device to nv_disp.inf/nv_dispi.inf. But I doubt they added back D3D9-OpenCl interop, which is the only thing that matters as far as this topic is concerned.

Almost is the key word. But anyway, apparently the interop isn't going to be added back.. so should probably just drop the topic altogether.

[ajp_anton]

Originally Posted by ajp_anton

When using DXVA native to decode a 1280x718 video, two problems occur that don't with EVR:
1. An extra row (or two?) of grey pixels appear at the bottom (only when DXVA scaling is used), forcing a tiny stretch of the video to fit into 1-2 less pixels.
2. If scaled to 100%, the player crashes.

Originally Posted by ajp_anton

Windows 7 x64, MPC-HC (both 32- and 64-bit), LAV.
Intel i5-4200U. (GPU: Intel HD 4400)

Sample file:
http://s.ajpanton.se/sample_madVR.mkv

[Zachs]

Originally Posted by madshi

You mean using copyback? Or D3D11 interop with shared textures? Or SM 5.0? Three possible "solutions". Although OpenCL does seem to be faster, the more "modern" the GPU is, so I'd hate to lose it.

Well FWIW on NVidia at least, anything less than 128 neurons (i.e. 64 and below), the SM5.0 NNEDI3 trumps the OpenCL version using avoid branches optimization. On Intel with P4600 (which is still very modern), the SM5.0 version is ~2x faster than the OpenCL version across the board with the "Alt weight access + scalar small code" optimization option. For example, upscaling 720x576 to 1080p the P4600 renders in 31ms (16/16 neurons) making it perfectly acceptable to watch anything 30fps and below. With the OpenCL version, it needs 58ms. At the end of the day it really comes down to how well the driver/compiler maps the code to its underlying hardware.

Anyway I was talking about the new interop requiring only 15 mins to implement (EDIT: for MPDN - YMMV). To answer your first question, yes you can now use OpenCL NNEDI3 on the latest Nvidia drivers with MPDN, but some users prefer the SM5.0 version anyway as it's simply faster for them.

[x7007]

Originally Posted by Zachs

Well FWIW on NVidia at least, anything less than 128 neurons (i.e. 64 and below), the SM5.0 NNEDI3 trumps the OpenCL version using avoid branches optimization. On Intel with P4600 (which is still very modern), the SM5.0 version is ~2x faster than the OpenCL version across the board with the "Alt weight access + scalar small code" optimization option. For example, upscaling 720x576 to 1080p the P4600 renders in 31ms (16/16 neurons) making it perfectly acceptable to watch anything 30fps and below. With the OpenCL version, it needs 58ms. At the end of the day it really comes down to how well the driver/compiler maps the code to its underlying hardware.

Anyway I was talking about the new interop requiring only 15 mins to implement (EDIT: for MPDN - YMMV). To answer your first question, yes you can now use OpenCL NNEDI3 on the latest Nvidia drivers with MPDN, but some users prefer the SM5.0 version anyway as it's simply faster for them.

Hey, how can I use the OpenCL NNEDI3 ? with CUVID or DXVA2 write-back ?
Can you explain .
Thanks