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. |
3rd March 2014, 13:36 | #24202 | Link |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
@XMonarchY,
Graeme has replied to the problem you reported here: http://www.avsforum.com/t/1471169/madvr-argyllcms Can you please follow-up there and answer any questions he might have? Specifically he's asking for the .ti3 file you used and the collink options etc. |
3rd March 2014, 18:29 | #24205 | Link |
Registered User
Join Date: Feb 2002
Location: San Jose, California
Posts: 4,407
|
Based on feedback at avsforum it looks like it is actually a feature to allow wtw representation when possible (it is only possible when using -a in collink and linear GPU gamma ramps). It is only that on my display (and I assume XmonarchY's) blue cannot get any more blue so the brighter whites turn yellow. As only test videos should have any wtw beyond ~237 and the color isn't very off at 237 we probably shouldn't worry about it.
It does make interpreting test patterns trickier. Edit: OR not! I'll just keep watch for a bit and see. Last edited by Asmodian; 3rd March 2014 at 18:37. |
3rd March 2014, 18:36 | #24208 | Link |
Registered User
Join Date: Jan 2014
Posts: 93
|
Fantastic presenter madshi! Danke schön!
However, I can't really get smooth motion to work, without serious judders, while the delayed (and dropped) frames numbers climb. decoder, subtitle, upload, render and backbuffer queue is always full and I went with the maximum amount for each. This is most noticeable when I do something while the video is playing, like minimizing some random window or so. With smooth motion disabled, actions such as these have no impact on the video. PC/environment specs of interest: NVIDIA GTX480 1.5GB @ Stock INTEL i7-2600k @ 4.8GHz 12GB DDR3 RAM @ 1600MHz 2x Samsung PX2370 1920x1080 displays @ 70Hz Test with various videos (720p, 1080p, 480p), result remains the same: Smooth Motion is unfortunately unusable However, lower resolutions are less prone to the issue. P.S. using mpcbe with lav(split+decode), ffdshow tryouts (filter video, mix audio), reclock and xysub |
3rd March 2014, 18:39 | #24209 | Link | |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
Maximum queue size is not always the best idea. If you run out of GPU RAM, this can have all kinds of bad effects. Anyway. Have you tried fullscreen exclusive mode? That's the best mode to use for smooth motion to work reliably. |
|
3rd March 2014, 19:11 | #24210 | Link | |
Registered User
Join Date: Jan 2014
Posts: 93
|
Quote:
still ~1/3 of VRAM left and plenty of RAM too. exclusive works much better, however, as i am using two monitors, its not really an option. Plus, it causes visual defects: Minimizing, maximizing or closing windows will freeze the animation of said window in a state inbetween, till you exit exclusive mode on the other monitor. |
|
3rd March 2014, 19:16 | #24211 | Link |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Well, exclusive mode is the recommended mode. Of course if you have a dual monitor setup and want to continue working on the primary monitor while playback is running on the secondary, that might currently be problematic. I'm not sure if I can improve that. Maybe, but not soon. You could also try Overlay mode.
|
3rd March 2014, 19:30 | #24213 | Link | |
Registered User
Join Date: Jan 2014
Posts: 93
|
Quote:
Also, is there a way to stop it from reinitializing when dragging the player to the other screen? My display have the same resolution and framerate/Hz, so there is no need to clear the queues, at least some of them. EDIT: oh yeah, its probably been covered before, but searching a thread with 1200+ pages is like looking for that infamous needle in a haystack: Why doesnt OpenCL dithering work with NVIDIA? shouldnt it properly support OpenCL by now? Last edited by Ceremony; 3rd March 2014 at 19:35. |
|
3rd March 2014, 19:33 | #24214 | Link | |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
That is necessary, because every monitor is driven by a separate "GPU", even if it's just 2 output ports of the same PCIe card. |
|
3rd March 2014, 19:48 | #24215 | Link | |
Registered User
Join Date: Jan 2014
Posts: 93
|
Quote:
well, this is probably the lowest priority request one can make^^ |
|
3rd March 2014, 20:11 | #24216 | Link | |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
Yes, too many more important things to do. |
|
3rd March 2014, 20:33 | #24217 | Link |
Guest
Posts: n/a
|
Well... I am glad that 3DLUT WTW issue is now being worked on. It appears that at the moment, the only way to create a proper WTW is to make sure that all 256 bits of R, G, and B are present for the original LUT. That isn't possible on my TV - my B at 100% gray level is at 110% or so, which means 10% of bits are be missing to make up for imbalances in the rest of the LUT. This is why bars are yellow. Someone who is missing R, or G, instead of B, has pink or whichever other color bars. It is only my luck that Asmodian has a similar issue or my feedback/report would be dismissed...
Where should people submit the nVidia OpenCL <-> D3D9 interlop bug? nVidia's official bug reporting channel? Should any more information be provided, like a generic letter? I think the more people submit the bug, the more likely it is to be fixed in the next driver release or some time in the future... Can D3D10 or D3D11 be used with OpenCL instead of D3D9 to run NNEDI3? |
3rd March 2014, 21:37 | #24218 | Link | |
Broadband Junkie
Join Date: Oct 2005
Posts: 1,859
|
Quote:
Posting in ManualG's stickied Driver Release threads on Geforce Forums Bug reports NVIDIA's CUDA Registered Developer bug reports (for madshi only, since NVIDIA's implements OpenCL via their CUDA compiler) Or probably a similar bug reporting mechanism which may exist through NVIDIA's Graphics/Game Development Registered Developer Program for Direct3D/OpenGL bugs (because of past abuse, they are more strict on accepting applications for that program, compared to the CUDA program where they'd accept anyone easily). Last edited by cyberbeing; 3rd March 2014 at 21:45. |
|
3rd March 2014, 23:40 | #24220 | Link | |
Registered User
Join Date: May 2008
Posts: 84
|
Quote:
BTW: FSE works without problems on secondary screen while normal work is done on the primary. |
|
Tags |
direct compute, dithering, error diffusion, madvr, ngu, nnedi3, quality, renderer, scaling, uhd upscaling, upsampling |
|
|