madVR - high quality video renderer (GPU assisted)

[pirlouy]

Originally Posted by madshi

Which Sammy TV is that? Can it do 4:4:4? I might be looking into getting a new monitor for my development PC. I'm tempted with misusing a TV for that. But 40" does sound a bit large. 30" would be ideal...

As Leeperry said, if you really care about 4:4:4, you have to use specific settings, then your TV will be in monitor mode, but you'll lose quite all options (including BFI which Leeperry really appreciates :P). In all other modes, you'll be in 4:2:2.

Originally Posted by leeperry

Yep, personally I find 27" too small and 32" a tad too big

Do you mean 32" is too big to watch a movie, or it's just for occasional events ?
Because in my case, all these shaders settings are nothing compared to watching on a bigger size. I plan on going from 40" to 55".

[cyberbeing]

Originally Posted by Soukyuu

I kind of don't see any difference between openCL dither and random dither, except for dropped frames :P
Tried dark and light scenes and both seem identical both when paused and playing. Looking at cyberbeing's post back here, I expected more.

In my post back there, I took a magnifying glass to each dither to see what they were doing. As madshi mentioned earlier in the thread, with real-world viewing the most he could notice on his projector setup was the lower noise-floor of the OpenCL error-diffusion. If you are unable to notice less temporal noise when you enable OpenCL error-diffusion, you probably aren't getting any realistic benefit from it. madVR random dither has crosstalk by nature, while the OpenCL error-diffusion essentially doesn't yet produces a pattern.

I've personally not yet decided the fate of the OpenCL dither on my setup, but I will say if we didn't have profiles in madVR I'd consider the OpenCL dither worthless. On high resolution displays, high framerate content, and/or Smooth Motion frc enabled, the cost:benefit becomes horrible quite quickly.

Out of all these cases, I believe madVR really could use a trade-quality-for-performance option to disable OpenCL dither when Smooth Motion is active, which is set as the default. Otherwise madshi, you really need to consider modifying the workflow so OpenCL dither is applied before Smooth Motion at original video framerate rather than after at double framerate w/ blended frames.

[mindbomb]

is error diffusion essentially free if you are already using opencl for nnedi3?

Hello. I was the one who thought renaming OpenCL .dll files would do the trick because the working OpenCL drivers had a different name and renaming made my black and green screens go away. I still think it may be a naming problem.

New broken-OpenCL 344.67 driver package includes compressed .dl_ files that are actually:
OpenCL32.dll
OpenCL64.dll
NVOpenCL32.dll
NVOpenCL64.dll
nvdisp.inf lists OpenCL.dll and NVOpenCL.dll which are not actually present in driver package, but are simply other .dll files renamed during installation:
OpenCL32.dll --> OpenCL.dll
NVOpenCL64.dll --> NVOpenCL.dll

Older 327.23 working OpenCL driver package includes:
OpenCL.dll
OpenCL64.dll
NVOpenCL32.dll
NVOpenCL.dll
But I have not installed them, so I do not know if those files change their names to something else.

I think its specifically the SysWOW64 NVOpenCL.dll that is being used as its the only one that actually creates a difference when being manipulated. In theory, replacing broken NVOpenCL.dll from a newer set with NVOpenCL.dll from an older working set would do the trick.

How would I know that its working? Would my CPU or GPU utilization sky-rocket? I know it does when I use new drivers and I get a black screen - is that a normal effect for working OpenCL drivers? Its at about 14-16% with GTX 770 when using NVOpenCL.dll from 327.23 drivers. Are you sure that 327.23 driver package does work 100%? I read that the issue has been acknowledged by nVidia - when was that?

It just sucks having to use older drivers since some of us also play games and want the latest drivers. I hope I can eventually get the latest 344.67 drivers to work with OpenCL...

[cyberbeing]

Originally Posted by mindbomb

is error diffusion essentially free if you are already using opencl for nnedi3?

No, it's an added cost.

About NNEDI3 cost in particular, I've noticed that it is actually bottlenecked by the default 224GB/s memory bandwidth @1.2Ghz Core on the GTX 770 when pushed above ~80% GPU load. I need to overclock to ~238GB/s memory bandwidth before the core clock becomes the bottleneck again.

Originally Posted by XMonarchY

I still think it may be a naming problem.

It's not. The correct name for the OpenCL kernel driver for the system directories on Nvidia is nvopencl.dll. They have different names in the driver package since one is for 64bit applications (System32 dir) and the other is for 32bit applications (SysWoW64 dir). Since Nvidia packages them in the same Display.Driver folder, they would have naming conflict otherwise.

The nvopencl.dll also contains a version compatibility check, and will not function with libraries from other driver versions. (I actually tested this last week).

Originally Posted by XMonarchY

How would I know that its working?

Open GPU-Z. If OpenCL is not checked, then you've broken OpenCL support in the driver.

The more time consuming way to test this, is to do the following:

1. Disabled OpenCL features
2. Close madVR
3. Open RegEdit
4. Delete HKEY_CURRENT_USER\Software\madshi\madVR\OpenCL if it exists
5. Play video with madVR
6. Enabled OpenCL features
7. Refresh HKEY_CURRENT_USER\Software\madshi\madVR key.

If OpenCL driver support does not exist, the HKEY_CURRENT_USER\Software\madshi\madVR\OpenCL key will not be re-created with a Binary OpenCL kernel, Driver Version, and Checksum under a subkey with your GPU name.

[Gagorian]

Is it normal that OpenCL error diffusion increases average rendering time 3x? My GPU is a r9 270 (basically a 7870?) and using latest madVR.

I tried playing a few 1080p24 standard x264 blu-ray movies presented at 23.976 Hz.

Average rendering time (using Jinc 3 AR for both Luma and Chroma, Debanding low, all trade quality for performance options except OpenCL error diffusion disabled) was around 8-10 ms. The rendering time is about the same for 720p movies, so scaling for instance is rather cheap even with Jinc 3 AR.

With OpenCL error diffusion the average rendering time was raised to around 28-30 ms.

Should it really be that demanding?

[DragonQ]

Reports so far suggest that OpenCL Error Diffusion is indeed very demanding. Can't imagine most people can even use it.

[leeperry]

Originally Posted by DragonQ

Reports so far suggest that OpenCL Error Diffusion is indeed very demanding. Can't imagine most people can even use it.

Madshi said that it wasn't all that demanding on his 7770(or was it 7790?) and I can confirm that it's a breeze on my factory overclocked 7850.

Originally Posted by pirlouy

Do you mean 32" is too big to watch a movie, or it's just for occasional events ?
Because in my case, all these shaders settings are nothing compared to watching on a bigger size. I plan on going from 40" to 55".

32" for a monitor when you stand like 80 cm away is a tad too big to my taste and as yesgrey said a long time ago vision is very demanding to the human brain, I happen to care as much for audio as I care for video so I prefer a display that's on the small side. The biggest and cheapest tweak to audio nirvana is to shut your eyes: http://www.mymusicmask.com/en/home.html

I've tried a few 50 inchers but defects became way too visible from a 2 meters distance and my brain was simply unable to focus on audio anymore. I remember that when I used to own a videoprojector it took me a lot of concentration to equally enjoy audio and video.

[bjd]

Originally Posted by leeperry

I agree that some sort of info in the OSD regarding NNEDI scaling would be most welcome.

BTW, I presume that "always - if upscaling is needed" should read "if scaling is bigger than 1.0 and lower than 2.0" for 2X luma and "if scaling is bigger than 2.0" for X4 luma? That's how I'd like to have them set

Yeah, I would like to see the res after NNEDI3 shown say below the movie resolution.

The more I think about it, I assume to get 576P -> 1080P without downscale/upscale you need to quadruple the image size to 2880x1152 (assuming the height is only doubled twice as it is over the target resolution) and then downscale (CR AR LL) to 1080p.

[cyberbeing]

Originally Posted by leeperry

Madshi said that it wasn't all that demanding on his 7770(or was it 7790?) and I can confirm that it's a breeze on my factory overclocked 7850.

It's partially a matter of perspective I believe. madshi's numbers showed it increased his relative render times by 400% when he enabled OpenCL dither compared to his previous settings. This could likely be interpolated into 400% higher GPU load and power draw. That said, I have no doubt it will perform well on AMD Southern Islands based GPUs, since that's what he optimized it for. madshi's numbers for the absolute render time cost of enabling openCL dither on his AMD 7770 (80W TDP, 1.3 TFLOP) @1680x1050, seems nearly identical to the numbers of my much higher powered GTX 770 (230W TDP, 3.2 TFLOP) @1680x1050, assuming he tested with smooth motion disabled.

I see madshi's argument of it not being *that* demanding, as more of a statement that it should still be usable based on absolute render time increases, which I'd agree with. If you want to use NNEDI3 as well, or have a weaker GPU already being pushed very hard before the OpenCL stuff, all bets are off.

[pirlouy]

Originally Posted by leeperry

http://www.mymusicmask.com/en/home.html

Very funny link !

I though people always wanted a bigger image, but you proved me wrong.

[iSunrise]

madshi, I have a bug to report with 0.87.4 (yes, finally, the week end nears, so I have more time to test):

There´s something wrong with chroma upscaling, even when using the Nvidia 327.23 drivers, as I get a yellow/greenish image instead of levels of grey (not sure if this is only NV related, don´t have an AMD at my disposal atm) when you enable chroma upscaling and you choose NNEDI3.

Steps to reproduce is pretty easy, just enable chroma upscaling NNEDI3 and it should show in windowed mode or in FSE. It also doesn´t matter how many neurons. I really hope this isn´t exclusively NV-related again, because this is using OpenCL.

For some reason, this is only happening on some files, example:
http://www.w6rz.net/filmrez.zip

This is with a GTX580 with the last working OpenCL drivers as of today (327.23).

[nevcairiel]

Originally Posted by cyberbeing

Otherwise madshi, you really need to consider modifying the workflow so OpenCL dither is applied before Smooth Motion at original video framerate rather than after at double framerate w/ blended frames.

Didn't this question come up just a few pages back already, possibly also by you?
You simply cannot do dithering any earlier, it HAS to be the very last step in the rendering pipeline, after any and all image processing. Doing dithering at any other time will do two things: Make dithering less effective, and reduce the quality of any following rendering steps - both things you definitely do not want.

[iSunrise]

I´ve made some simple profiles to test various settings on my GPU, but for some reason, madVR always selects one particular profile irregardless of the source. madVR always shows the active profile "1080p LowFPS" (with bold black characters) on all sources.

if      (srcHeight <= 576)                         "576p"

else if (srcHeight = 720)                          "720p"

else if ((srcHeight > 720) and 
        (srcHeight <= 1080) and 
        (srcFps <= 50))                            "1080p LowFPS"

else if ((srcHeight > 720) and 
        (srcHeight <= 1080) and 
        (srcFps > 50))                             "1080p HighFPS"

Is there an error in my code somewhere, because madVR tells me it´s ok (green arrow).

EDIT:

Found the problem, for some reason, I needed to edit that to:

else if ((srcHeight > 720) and 
        (srcHeight <= 1080) and 
        (srcFps < 50))                            "1080p LowFPS"

else if ((srcHeight > 720) and 
        (srcHeight <= 1080) and 
        (srcFps >= 50))                           "1080p HighFPS"

I still cannot see an error in my code though, does anyone see a problem? If not, is this a bug madshi?

[cyberbeing]

Originally Posted by nevcairiel

Didn't this question come up just a few pages back already, possibly also by you?
You simply cannot do dithering any earlier, it HAS to be the very last step in the rendering pipeline, after any and all image processing. Doing dithering at any other time will do two things: Make dithering less effective, and reduce the quality of any following rendering steps - both things you definitely do not want.

I did ask something like this earlier, but I'm not fully understanding. I thought madVR dithered the video much earlier during TV->PC levels conversion, YCbCr -> RGB conversion, and 3DLUT processing, which I would have thought came before Smooth Motion FRC takes place. It seems like for the frame blending to be most effective, it would need to occur on final post-processed video frames. What exactly is being dithered after frame blending occurs? It certainly can't be all dithering procedures required by madVR, and is probably only the dithering down to 8bit?

[DragonQ]

Originally Posted by leeperry

Madshi said that it wasn't all that demanding on his 7770(or was it 7790?) and I can confirm that it's a breeze on my factory overclocked 7850.

Maybe it's best on AMD GPUs. Intel ones certainly aren't good enough to do it, but obviously they're lower-end.

Originally Posted by leeperry

The biggest and cheapest tweak to audio nirvana is to shut your eyes: http://www.mymusicmask.com/en/home.html

True but $45 for a blindfold? Hahahaha.

[nevcairiel]

Originally Posted by cyberbeing

I did ask something like this earlier, but I'm not fully understanding. I thought madVR dithered the video much earlier during TV->PC levels conversion, YCbCr -> RGB conversion, and 3DLUT processing, which I would have thought came before Smooth Motion FRC takes place. It seems like for the frame blending to be most effective, it should need to occur on final post-processed video frames. What exactly is being dithered after frame blending occurs? It certainly can't be all dithering procedures required by madVR, and is probably only the dithering down to 8bit?

There should only be one dithering process, which reduces the internal 16-bit floating point pixels down to 8-bit integer, and this should be done as the very last step, because the output of this process is in much lower bitdepth, namely 8-bit pixels.
Everything before dithering should use a higher internal precision, so that no data accuracy is ever lost. Dithering destroys data. It destroys less data then pure rounding, but it still destroys data (but you need to destroy some data if you go 16->8 bit). You don't want to do it multiple times, or too early, or you lose more data then you would want.

Why would you dither after RGB conversion? Why not simply keep high precision pixels around?
If you dither once with random dither, the additional image noise is already in the image. If you then even upscale that image, you also upscale the noise, that could result in rather obvious noise artifacts.

[iSunrise]

Originally Posted by cyberbeing

I did ask something like this earlier, but I'm not fully understanding. I thought madVR dithered the video much earlier during TV->PC levels conversion, as well as YCbCr -> RGB conversion, which I would have thought would come before Smooth Motion FRC takes place. What exactly is being dithered after frame blending occurs?

Why would you do this? You should only process the final (16bit) image to your RGB output bitdepth (display), otherwise you would lose a lot of accuracy, which then would be processed again. Or do I not understand your question correctly?

When you work in a DAW, everything should be a it´s highest bitrate possible before the final dithering (mastering), since every processing step reduces your headroom.

[DragonQ]

I wonder if dither is used twice when you tick the options to use 10-bit buffers rather than 16-bit?

[nevcairiel]

Originally Posted by DragonQ

I wonder if dither is used twice when you tick the options to use 10-bit buffers rather than 16-bit?

More likely all calculations are just only done in 10-bit, which loses a bit of precision. Since its a option also meant to speed up rendering, its doubtful extra dithering steps would be involved.