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. |
30th January 2014, 20:56 | #22181 | Link | |
_
Join Date: May 2008
Location: France
Posts: 692
|
Quote:
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". |
|
30th January 2014, 21:05 | #22182 | Link | |
Broadband Junkie
Join Date: Oct 2005
Posts: 1,859
|
Quote:
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. |
|
30th January 2014, 21:17 | #22184 | Link |
Guest
Posts: n/a
|
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... Last edited by XMonarchY; 30th January 2014 at 21:44. |
30th January 2014, 21:43 | #22185 | Link | |
Broadband Junkie
Join Date: Oct 2005
Posts: 1,859
|
Quote:
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. 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). 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:
Last edited by cyberbeing; 30th January 2014 at 22:31. |
|
30th January 2014, 22:05 | #22186 | Link |
Registered User
Join Date: Jul 2013
Posts: 27
|
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? Last edited by Gagorian; 30th January 2014 at 22:07. |
30th January 2014, 22:32 | #22188 | Link | ||
Kid for Today
Join Date: Aug 2004
Posts: 3,477
|
Quote:
Quote:
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. |
||
30th January 2014, 22:45 | #22189 | Link | |
Registered User
Join Date: Apr 2010
Posts: 163
|
Quote:
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.
__________________
4gb DDR3/AMD Fx6300 Windows 8.1, GT750ti, Auzentech Meridian 7.1, LG 42LN5400 4:4:4 1080P LCD TV |
|
30th January 2014, 22:53 | #22190 | Link | |
Broadband Junkie
Join Date: Oct 2005
Posts: 1,859
|
Quote:
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. Last edited by cyberbeing; 30th January 2014 at 23:48. |
|
30th January 2014, 23:45 | #22192 | Link |
Registered User
Join Date: Dec 2008
Posts: 496
|
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). |
30th January 2014, 23:45 | #22193 | Link | |
Registered Developer
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,348
|
Quote:
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.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders |
|
30th January 2014, 23:54 | #22194 | Link |
Registered User
Join Date: Dec 2008
Posts: 496
|
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.
Code:
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" EDIT: Found the problem, for some reason, I needed to edit that to: Code:
else if ((srcHeight > 720) and (srcHeight <= 1080) and (srcFps < 50)) "1080p LowFPS" else if ((srcHeight > 720) and (srcHeight <= 1080) and (srcFps >= 50)) "1080p HighFPS" Last edited by iSunrise; 31st January 2014 at 00:04. |
31st January 2014, 00:00 | #22195 | Link | |
Broadband Junkie
Join Date: Oct 2005
Posts: 1,859
|
Quote:
Last edited by cyberbeing; 31st January 2014 at 00:17. |
|
31st January 2014, 00:13 | #22196 | Link | ||
Registered User
Join Date: Mar 2007
Posts: 934
|
Quote:
Quote:
__________________
TV Setup: LG OLED55B7V; Onkyo TX-NR515; ODroid N2+; CoreElec 9.2.7 |
||
31st January 2014, 00:17 | #22197 | Link | |
Registered Developer
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,348
|
Quote:
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.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders Last edited by nevcairiel; 31st January 2014 at 00:25. |
|
31st January 2014, 00:19 | #22198 | Link | |
Registered User
Join Date: Dec 2008
Posts: 496
|
Quote:
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. |
|
31st January 2014, 00:23 | #22200 | Link |
Registered Developer
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,348
|
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.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders |
Tags |
direct compute, dithering, error diffusion, madvr, ngu, nnedi3, quality, renderer, scaling, uhd upscaling, upsampling |
|
|