Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
25th July 2015, 23:42 | #32141 | Link | |
Registered User
Join Date: Mar 2002
Posts: 2,323
|
Quote:
I had been using CUVID so far, now I switched to DXVA2 copyback, and I haven't known this: "1. ... DXVA2 Copy-Back allows the graphics card to drop down to the medium power state if the GPU load is low enough." Although I have been maxed out the powerstate to P5, gpu was always used at P5 with CUVID, even when MPC-HC was paused or stopped, now it goes down to the lowest states in these cases as well: less power -> less heat -> less noise.
__________________
Ryzen 5 2600,Asus Prime b450-Plus,16GB,MSI GTX 1060 Gaming X 6GB(v398.18),Win10 LTSC 1809,MPC-BEx64+LAV+MadVR,Yamaha RX-A870,LG OLED77G2(2160p@23/24/25/29/30/50/59/60Hz) | madvr config Last edited by chros; 25th July 2015 at 23:46. |
|
26th July 2015, 00:36 | #32142 | Link | |
Registered User
Join Date: Dec 2011
Posts: 1,812
|
Quote:
Not being able to use NNEDI3 would be a tragic loss, at least to me. |
|
26th July 2015, 09:18 | #32143 | Link |
Registered User
Join Date: Jul 2015
Posts: 16
|
Using 0.88.20, when a MPC-HC OSD element pops up (volume, skip, etc) there is a very minor stutter, as though 1-2 frames had to repeat. Its noticeable, but isn't consistent in its severity or length. Big improvement from earlier versions, but not pre-OSD rewrite smoothness.
The madVR OSD seems to cause this issue too. Its like theres something off, almost like smooth motion was disabled, but less extreme. GTX 660, MPC-HC (latest nightly) internal LAV, ISR, etc. D3D11 exclusive. |
26th July 2015, 09:49 | #32144 | Link | |
Registered User
Join Date: Sep 2014
Posts: 280
|
Quote:
Is there a windows 10 working driver with that extension? |
|
26th July 2015, 23:12 | #32147 | Link | |||||||||||||||||||
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
Quote:
Quote:
Ok, please try again with v0.88.21. Quote:
Quote:
Quote:
Quote:
Quote:
I find it hard to understand your image descriptions, though. I'm not sure if @0.xx is the radius of the strength?? Or is it sometimes this and sometimes that? Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
In any case, currently madVR *always* draws in paused/stopped mode. I will change that in a future version so that it only draws when it's needed. That will depend on the media player, though (which OSD APIs they're using). Quote:
The purpose of first downscaling and then upscaling again is that this is the only way we can objectively judge whether the upscaled image comes near to the original. If we don't use this approach, we have e.g. a DVD resolution source and an 1080p upscale, but whether the upscale is good or not nobody can say. Different upscalers, different sharpening algorithms produce different "looks". Some users prefer this, other users prefer that. Without having the original to compare to, if you ask 100 different users for which algorithm combination they prefer, you'll get 98 different answers. Quote:
Quote:
Quote:
Quote:
|
|||||||||||||||||||
26th July 2015, 23:14 | #32148 | Link |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
madVR v0.88.21 released
http://madshi.net/madVR.zip Code:
* OSD rendering back to 0.88.16 logic, except when low latency mode is active * fixed: DXVA processing failed when video stream switched resolution * fixed: render times weren't shown correctly * fixed: SuperRes bigger radius values could cause artifacts * fixed: low latency mode sometimes wasn't turned off when it should |
27th July 2015, 00:58 | #32150 | Link |
Registered User
Join Date: Feb 2002
Location: San Jose, California
Posts: 4,406
|
I have been unable to get NNEDI3 in madVR working with the Windows 10 Nvidia drivers 353.54. Other OpenCL tests do work and by uninstalling 54 and reinstalling 353.30 NNEDI3 works again. Windows Update will automatically re-install 353.54 which breaks it again.
Tested with a 980 Ti, madVR v0.88.20, and Windows 10 Pro (not preview).
__________________
madVR options explained Last edited by Asmodian; 27th July 2015 at 01:01. |
27th July 2015, 01:21 | #32152 | Link |
Registered User
Join Date: Oct 2012
Posts: 7,903
|
AFAIK madVR uses cl_nv_d3d9_sharing for nvidia. so it can't work with these drivers.
nvidia removed this extension nothing you can do about you can only hope the next WHQL driver have them again so nvidia user can use nnedi3 with windows 10 if not you have to hope madshi is spending time on it. which could be a huge waste of time. CL_KHL_d3d10_sharing could have the same copyback issue like AMD cl_khl_dx9_media_sharing. and who know if nvidia isn't removing cl_nv_d3d11_sharing too? i mean it looks like they have nothing better to do right now them crippling there own drivers. there are workarounds to stop the windows updates for nvidia driver but wrong thread. |
27th July 2015, 01:38 | #32153 | Link | ||
Kid for Today
Join Date: Aug 2004
Posts: 3,477
|
Quote:
Quote:
"sxbr75+SR3@0.41" in .15: 3 passes, 0.41 strength. "1@0.66" in .20: first figure is strength, second is radius. Anyway, I was hoping for you explaining me how HQ looks so much closer to the ground truth than LQ and that didn't happen, I take it that my screenshots were hard to kill then. I won't give up on SR(mostly due to the magic it does on motion blur, even more striking on 29.97fps footage O-M-G talk about a one-way ticket!), you were kind enough to add a kludge in order to force LQ in .20 but I take it that the seperate knobs for the number of passes and strength will never come back...even as kludges if I ask very very nicely? And this ** radius stuff will replace them? Even 4*0.41 or 3*0.42 don't look nearly as good as 3*0.41 IME so I'm not willing to compromise whatsoever, your "pretty much the same" and "roughly the same" don't cut it by a very long shot so it sounds like I'll stick to .15 and just got myself a lot of free time suddenly. If 2 passes at 1.0 are supposed to look "roughly the same" as 3 passes at 0.41 then I wonder why you spent countless hours nitpicking about a lot of details in mVR, such as chroma for instance when many ppl claim that differences IRL are completely invisible......nothing in what you do goes by the "pretty much the same" principle so color me surprised to read that you are willing to kill the SR golden goose *killer* feature in such a tremendous and dramatic way(to me anyway) And if you are so concerned about the GPU consumption wasted by one extra pass then I wonder why you even allow 256 neurons NNEDI3 to begin with, this is not consistent at all. I couldn't care less about a few extra percents of GPU load if PQ looks better to me, I truly wonder how you came up with the idea that mixing the strength and number passes together as a single knob could ever work But truth be told, I can't really think of anything to improve in .15 tbh(proper SR on chroma woulda been nice but hardly vital), PQ is truly beyond words so I'm totally cool with calling it my very own 1.0 and live happily ever after......and no more e-drama for you to cope with(well except when that other .15 LQ lover will be back from vacation next week ^^), happy happy joy joy My only problem atm is that 1080p movies got more resolution but 720p encodes get the magical SR motion-blur treatment, choices.. I also don't understand why madHcNet32.dll is locked even when mVR is closed lately, I don't have any A/V resident app running and virustotal doesn't consider my mVR installation infected...oh well, that never happened before, it's only after a zillion .15/.20 rollings that it started acting up. Last edited by leeperry; 27th July 2015 at 02:11. |
||
27th July 2015, 12:21 | #32157 | Link | |
Registered User
Join Date: Sep 2006
Posts: 2,197
|
Quote:
__________________
Laptop Lenovo Legion 5 17IMH05: i5-10300H, 16 GB Ram, NVIDIA GTX 1650 Ti (+ Intel UHD 630), Windows 10 x64, madVR (x64), MPC-HC (x64), LAV Filter (x64), XySubfilter (x64) (K-lite codec pack) |
|
27th July 2015, 15:16 | #32158 | Link |
Registered User
Join Date: Feb 2004
Posts: 399
|
madshi, even with 0.88.21 that has the OSD rendering back to 0.88.16, the image is now black while seeking forward / backward.
This does not happen with the true/pure 0.88.16, any way around it?
__________________
XP SP3 / Geforce 8500 / Zoom Player |
27th July 2015, 16:06 | #32159 | Link | ||||||
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Does this test build fix it?
http://madshi.net/madVR8821b.rar Quote:
Quote:
From what I can see, your comparison is interesting, but not very goal oriented. You've posted a bunch of different screenshots with different settings, and all the conclusions I can draw from them are these: 1) Using a bunch of somewhat different settings results in images which look somewhat different. 2) You prefer one specific set of settings with one specific madVR version over a different set of settings with a different madVR version. 3) Latest SuperRes with default settings does produce aliasing with your test image, while with your preferred settings it's less of a problem. 4) With your specific test image, some other algo changes I did between v0.88.15 and v0.88.21 have a certain effect, too. I'm not totally sure what your goal with those images were. If you just wanted to show that your settings with v0.88.15 produce a somewhat different result to default settings with v0.88.20 when using the "BilinearSuperRes" hack, you've succeeded, but other than that it's hard to draw any hard conclusions. A goal oriented test would have been to use v0.88.15 for all images, and then to compare 3 passes with 0.65 strength to 2 passes with 1.00 strength, to check if there's a noticeably difference in image quality. But you didn't do that, so you didn't put any weight to your wish that you want to be able to adjust passes and strength separately. FWIW, SuperRes is still not "finished". There's one change I plan to do for the next build, which will change the look of the image slightly again (but not too much). Furthermore I will probably increase the radius by default which should get rid of most aliasing problems. Quote:
So far nobody has shown any proof that 3 passes with lower strength looks better at all than 2 passes with higher strength. All the evidence so far suggests that both produce nearly identical results. Yes, there are tiny differences, but it's hard to say which is actually better. If there were proof that 3 passes with lower strength would objectively be better, I would consider allowing that, even if it costs more GPU power. But there's no evidence that points in that direction. And I'm not going to waste GPU power on something where nobody is able to produce any evidence of improvement with any test images. Quote:
Quote:
Quote:
This is only a cosmetical issue, right? Why do seeks seemingly take so long in your case? |
||||||
27th July 2015, 16:10 | #32160 | Link |
Guest
Posts: n/a
|
Is the "Low Latency Mode" some new option or is it enabled by default?
With 88.20, I can set Chroma Upscaling NNEDI3 64n with SR Passes = 4 & Strength = 1 and Upscaling Refinement SR to Strength = 4, Radius = 0.66 and have no presentation glitches. With 88.21, I get presentation glitches unless I lower Chroma Upscaling SR to Passes = 2 & Strength = 1 and also lower Upscaling Refinement SR to Strength = 2, Radius = 0.66 . Not sure why - maybe presentation glitches were not properly reported in 88.20? |
Tags |
direct compute, dithering, error diffusion, madvr, ngu, nnedi3, quality, renderer, scaling, uhd upscaling, upsampling |
Thread Tools | Search this Thread |
Display Modes | |
|
|