View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000250 | madVR | bug | public | 2015-01-22 18:37 | 2018-01-14 15:02 |
| Reporter | JPulowski | Assigned To | madshi | ||
| Priority | high | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | unable to reproduce | ||
| OS | Windows | OS Version | 8.1, 64-bit | ||
| Summary | 0000250: Vertical lines when "Error Diffusion - option 1" is selected | ||||
| Description | When "Error Diffusion - option 1" option is selected for dithering, static vertical lines appear during video playback. Other dithering options do not have this issue. | ||||
| Steps To Reproduce | - Choose "Error Diffusion - option 1" for dithering from madVR. - Play a video via a media player. | ||||
| Tags | No tags attached. | ||||
| madVR Version | 0.87.13 | ||||
| Media Player (with version info) | MPC-HC 1.7.7.179 (1dad313) (develop) (master@46ce9d6) | ||||
| Splitter (with version info) | LAV Splitter 0.63.0.48-git | ||||
| Decoder (with version info) | LAV Video Decoder 0.63.0.48-git | ||||
| Decoding | CUDA | ||||
| Deinterlacing | auto mode | ||||
| DXVA2 Scaling Active | no | ||||
| Aero / Desktop Composition | On | ||||
| Problem occurs with mode | all modes | ||||
| GPU Manufacturer | NVidia | ||||
| GPU Model | GeForce GTX 690 | ||||
| GPU Driver Version | 347.25 WHQL | ||||
|
|
|
|
|
GTX 670 here, same thing. Started only after updating drivers to 347.25 version. |
|
|
This is very likely a bug in the new drivers, because it didn't occur with older drivers, and it also doesn't occur with AMD and Intel GPUs. Could you guys please report this to NVidia? If it's a bug in their drivers (which I think has a probability of 99%), there's nothing I can do to fix this. |
|
|
Certainly this should be a bug in the latest NVIDIA driver, but I was wondering how the NVIDIA driver is even able to differentiate between Error Diffusion Option 1 and Error Diffusion Option 2 as the problem does not manifest when the latter is selected. |
|
|
Reported it to NVIDIA. Looks like there are many issues with the latest drivers, lately. With the latest 347.xx drivers NNEDI3 and Error Diffusion 1 produces artifacts during playback. Well, I am not that hopeful but will wait for a reply from NVIDIA. |
|
|
Yesterday, I also reported this bug to NVIDIA via the CUDA Registered Developer program: Bug ID: 1602226, "[DirectCompute][347.12][Regression] 16px spaced vertical columns of dotted lines with madVR error diffusion dither" madshi, just a heads-up that I also listed your contact information in case they require more technical details about the DirectCompute code which triggers the bug, so there is a slim possibility they may end up emailing you. Unlikely though, since this bug is easy to reproduce. |
|
|
I just received a response from NVIDIA. They were able to reproduce the issue, and have assigned the bug to their development team for investigation. |
|
|
Great, thanks! |
|
|
Issue was not fixed in 347.52 WHQL, I'll try to check-up on the status. |
|
|
i can't reproduce this anymore with 349.90 windows 10 driver. i guess there is a high chance the next stable driver will have this fix too. |
|
|
Sounds promising. How's NNEDI3 and error diffusion performance of 349.90 compared to older pre-bug drivers? |
|
|
i'm going to kill that system now. i got a well know very hard bug. after that i try 341.44, 345.20 or 347.09? the numbers are such a mess. http://www.nvidia.com/Download/Find.aspx?lang=en-us and than update to 349.90 and compare. |
|
|
edit: tried to fix the number "translation" from the bugtracker so i removed all ~ i can't get windows 10 10041 with nvidia 349.90 running on my nvidia system. so this is 9926 with 349.65: in short just hope this version will never be released... all settings are default i just enabled SM and windows 7 overlay mode without exclusive fullscreen. nnedi3 chroma upscaling, with version 349.65, results in: resetting Direct3D device failed (8876086c) same error as this: http://bugs.madshi.net/view.php?id=234 i have a Palit Jetstream GTX 760 too hmm... nnedi3 set to always: 848x480 24hz to 1920x1080: double 64, quad 16, downscale at default 349.65: ~avg rendertimes 34.85ms GPU at 76 % but with serious corruption: http://abload.de/img/corumr1v.png screen is taker with window mode 347.09: ~avg rendertimes 32.51ms GPU at 70% error diffusion mode 1 performance: 1080p 30 hz at 1080p using cuda decoding for max powerstate SM is not active 349.65: rentertimes 6.63 ms gpu usage 18 % 347.09: rendertimes 6.63 ms gpu usage 19 % |
|
|
Hmmmm... Seems Mantis has screwed with your numbers somehow. So what is your verdict about the driver situation? |
|
|
working error diffusion mode 1 for breaking nnedi3 chroma completely and artefact's with slower image doubling. just hope it will never be released like this. |
|
|
I see, thanks for the tests. |
|
|
I've dropped back to 347.09 and am still getting the issue and other odd flickering. re-tried just now with a clean NV wipe, safe mode > drivercleaner then reboot and fresh install of 347.09. Will see how this fairs today. Kind of major issue for me, seems I can't really use option2 or ordered dithering either. opt1 gives the vertical lines, and the other two options just give tiny stutters, like motion blur. And odd random flicking. I was on 337.94 before that. All Ok with them. |
|
|
some news about 349.xx http://forum.doom9.org/showpost.php?p=1715810&postcount=348 http://www.phoronix.com/forums/showthread.php?116257-NVIDIA-Linux-349-12-Beta-Has-Improved-G-SYNC-amp-VDPAU-Features&p=480748#post480748 looks like they added openCL 1.2 so maybe this driver is pretty good in the end they may need to clean up some stuff. |
|
|
I've had a clean install of 347.09 for a day now and only get very occasion lines now. anything after 347.09 and its full on opt1 lines and odd flicking with opt2 etc. |
|
|
NVIDIA appears to have fixed this issue in the 350.05 Hotfix driver: http://nvidia.custhelp.com/app/answers/detail/a_id/3647 Similar to the Win10 driver, this Hotfix also adds support for OpenCL 1.2 on prior OS. |
|
|
Unfortunately, similar to what huhn posted about 349.65, the 350.05 driver now has corruption when using NNEDI3 ( http://i.imgbox.com/AxRKYBuL.png )... Not surprising, since this is also a r349 branch driver. |
|
|
And the OpenCL 1.2 support does not seem to support D3D9 interop, so the part I might be using is missing. It's not that dramatic, though, because there's a custom NVidia D3D9 interop extension which I'm currently using. But then, I don't really have use for 1.2 without the D3D9 interop, so there's no real progress for me. Anyway, any step forward is a step I appreciate. Maybe they will improve performance, too, at some point. But of course these artifacts are very annoying! According to cyberbeing NVidia has been analyzing the problem for more than 2 months now. How long do they need to fix such an obvious problem as this?? |
|
|
with new feature like directx 12 or WDDM 2.0 i guess they have a lot to do right now. direct compute issue (this issue 250)is fixed they simply added a new openCL issue. |
|
|
madshi, it actually looks like this new OpenCL NNEDI3 corruption is a bug in the r349 NVVM Compiler v4.2 rather than the kernel interpreter in the driver. If you override the madVR OpenCL kernel in the registry with one from an earlier CUDA 7.0 driver (NVVM v4.1), NNEDI3 seems to function as expected without any corruption. For those wondering, you can do this by just importing an older version of the key at: HKEY_CURRENT_USER\Software\madshi\madVR\OpenCL\ and then overriding the DriverVersion to 350.05 This will likely only work if you import an OpenCL kernel from another Cuda 7.0 (r346+) driver though. All of the r346 drivers generate identical NNEDI3 kernels, so it shouldn't matter which version you backup from before updating. |
|
|
I went ahead and submitted another bug via the CUDA Registered Developer program about this OpenCL NVVM Compiler problem: Bug ID: 1632554, "NVVM Compiler (version 4.2) is producing corrupted output from OpenCL 1.0 kernels" |
|
|
Interesting. Good method to figure out whether it's the compiler or something else which causes the problem. I guess most of the time the compiler will be responsible. |
|
|
NVIDIA has now reproduced the NNEDI3 OpenCL issue, and passed it along to the NVVM developers. It's worth mentioning that they were unable to reproduce the issue on a GTX 750Ti Maxwell (sm_50), so it seems possible this bug may only occur with Kepler GPUs (sm_30). |
|
|
about nnedi3 issue. i just tried 350.12 and it's fixed for me. can someone please double check this? if they really fixed this in such a short time for a hotfix GTA 5 driver... respect! |
|
|
Not fixed on my GTX 770. Still massive artifacts when using NNEDI3. |
|
|
that's strange isn't it? so i'm just lucky i guess... |
|
|
|
|
|
huhn, could you please confirm that it's actually fixed on your GTX 760 by testing the NNEDI3_bug1632554_test2.mkv video I just attached with NNEDI3 256 Neurons? |
|
|
i rebooted and tested your clip but not even angel beats can trigger the issue for me. i tried it with all types of neurons. |
|
|
Also if could you export the HKEY_CURRENT_USER\Software\madshi\madVR\OpenCL registry key from both 350.05 (artifacts with my sample?) and 350.12 (no artifacts?) driver installs, that would be useful when I update my bug report. Which OS are you testing on? If this really was an NVVM compiler bug for your GTX 760 as well, the Binary key should have changed between those two driver releases. If it didn't change, then this bug which remains on my GTX 770 may reside somewhere else in the driver. |
|
|
|
|
|
i'm using windows 10 10041 i can't reproduce the issue with 350.05 and i never used that version. i saw that issue with 349.65. i added the 2 regs which have the same binary key. i tried to get version 349.65 next. |
|
|
Thanks for your help. > i can't reproduce the issue with 350.05...windows 10 10041 This is interesting, since when I reported the bug to NVIDIA they reproduced it with a GTX 760 + 350.05 on Windows 7. So it sounds like the NNEDI3 corruption you previously saw with 349.65 may have been resolved by 350.05(?), yet in Windows 10 only? |
|
|
i try older madVR version next. because i just installed 349.65 and no issue... i haven't restarted yet. i'm running first some antivir stuff i didn't got the driver from nvidia i got i from a file share site so not today anymore. |
|
|
Okay, I think I see what's going on. It wasn't the 350.12 driver which resolved this issue for you, but rather the recent madVR x64 release. The difference being the NVVM generates a kernel with .address_size 32 with madVR x86, yet .address_size 64 with madVR x64. The NNEDI3 corruption does not occur on my GTX 770 with the .address_size 64 kernel, with 350.05 or 350.12. I didn't notice at first since madVR has an issue related to this, which causes it to not regenerate the OpenCL key when switching between madVR x86 & madVR x64. So whichever madVR version you run first, that OpenCL kernel will be used for both. I think what should be done here, is madVR should always generate a OpenCL kernel with x64 when using a 64bit OS. |
|
|
The 32bit version of madVR does not have the capability to talk to the 64bit NVidia OpenCL driver. Only the 64bit madVR version has that. On the other hand the 64bit madVR version can't talk to the 32bit NVidia OpenCL driver. So there isn't really much I can do here. It's weird that the OpenCL driver creates different kernels, anyway. For all intends and purposes, they should produce identical kernels, because the GPU doesn't really care at all whether the media player runs in 32bit or 64bit CPU mode. |
|
|
It doesn't though, with .address_size 64 NVVM generates a kernel with uses 64bit integers in various portions of the math (with a modified kernel to match), while the .address_size 32 uses a 32bit integers instead. I've opened a new bug about the OpenCL registry key failing to regenerate. http://bugs.madshi.net/view.php?id=283 |
|
|
Neither in my C++ code nor in my OpenCL kernel code "address_size" can be found, so I don't know how to control that. FWIW, pretty much all the integers in the OpenCL kernel are used for loops, only, or for things like the frame width/height. So they're not something 64bit would be needed for. All the real math is done in float. |
|
|
> Neither in my C++ code nor in my OpenCL kernel code "address_size" > can be found, so I don't know how to control that. .address_size would likely need to be passed to NVVM in the same way which .target is specified for GPU architecture. Though it seems likely the built-in driver NVVM sets these automatically if not specified, I'd suspect there must be some kind of api to override the default parameters. Who knows what that api would be though. > FWIW, pretty much all the integers in the OpenCL kernel are used for loops, > only, or for things like the frame width/height. Looking at the difference between .address_size 32 and .address_size 64, it seems only a couple parameters are changed from 32bit to 64bit integers. One being nnedi3$input, and the other being nnedi3_param_2 (whatever those refer to). Since .address_size 32 functioned just fine prior to r349, it doesn't seem like that could be directly related to any corruption. I'll upload the PTX which NVVM generates for reference. You'll probably need to read the PTX specification to understand what all that pseudo assembly means though... http://docs.nvidia.com/cuda/pdf/ptx_isa_4.2.pdf |
|
|
|
|
|
There's no API for setting ".address_size", and the OpenCL spec doesn't even know this parameter. There's a device information parameter you can ask which tells you which bitdepth the compiler will compile "size_t" types to. This can be either 32bit or 64bit. But I'm not using "size_t" anywhere. I'm always using types which have a strictly defined bitdepth. So ".address_size" should not even make a difference. We're talking about a simple and straight NVidia driver bug here. What NVVM seems to be doing here is violating the OpenCL spec. NVVM is not allowed to reinterpret my data types. I've explicitly told OpenCL which bitdepths I want to be used for every single one of my variables/parameters. |
|
|
I'm getting the feeling .address_size 64 may have the same function as the more intuitively named AMD compiler option GPU_FORCE_64BIT_PTR, and is probably doing exactly as intended by such an option. So if there is an issue, it sounds more like one of driver default settings than anything else? If you believe otherwise after looking at my NVVM_NNEDI3_Output.zip, I'd suggest you file a bug with NVIDIA yourself, since it's still unclear to me how this would violates the OpenCL spec. When I look at the OpenCL spec, it mentions that device hardware (i.e. GPU) address bits can be either 32bit or 64bit. Those compiler switches likely just force the GPU driver generate assembly in such a way so it will behave as a 64bit OpenCL hardware device, rather than a 32bit OpenCL hardware device. I would think of it in terms of a 32bit vs 64bit software, where you'd sometimes need to make minor code changes to take into account the 64bit address space in order everything to compile and function as expected. But you know more about OpenCL about I do, so maybe this comparison is incorrect? |
|
|
I'm not sure if we need to dig so deep ourselves here. It's a clear bug in the NVidia driver, so they should fix it, no? I don't really feel the need to investigate this myself. Sure, we could spend many hours trying to dig into the depths of what the driver does, analyze the PTX commands and compare them between different NVVM versions and bitdepths. But in the end the fix must come from NVidia. So why should we bother? Us spending those hours on implementing new features instead seems much more fruitful to me. Don't you agree? |
|
|
> It's a clear bug in the NVidia driver, so they should fix it, no? The NNEDI3 corruption issue is a clear bug in the NVIDIA driver. No need to investigate that, since NVIDIA is doing so themselves. > I don't really feel the need to investigate this myself. If you think there is a bug in the driver other than corruption issue I already have a bug open for, you may need to do a bit of investigation yourself. With statements such as... "What NVVM seems to be doing here is violating the OpenCL spec." "I'm always using types which have a strictly defined bitdepth. So ".address_size" should not even make a difference" ...if you were suggesting that (corruption bug non-withstanding) that NVVM in general handles the .address_size parameter incorrectly in relation to OpenCL, you'd need prove that theory with a reproducible test case if another bug were to be opened. That is all I was saying. |
|
|
Originally you said that the actual variables/parameters used in the kernel would change their bitdepth, depending on ".address_size", and that ".address_size" would depend on the NVVM bitdepth. *That* would have been a violation of the OpenCL spec. Now you're saying the variables/parameters don't change their bitdepth, after all, so also my comment about NVVM violating the OpenCL spec is no longer valid. I still don't really see a need for NVVM 32bit to create a different PTX kernel compared to NVVM 64bit, but as far as OpenCL memory addressing is concerned, I'm not really an expert. |
|
|
>Now you're saying the variables/parameters don't change their bitdepth All I'm saying is don't take my word for it. Anything I've said regarding this has in no way been verified. At best they are guesses based on what it sounds like such an option should be doing. Trying to understand exactly how the OpenCL code is being translated to PTX is a bit beyond me. The only thing clear is that the use of 64bit integers increases when .address_size 64 is specified. At that point only you could say for sure if any of those were actual clearly defined variables/parameters which shouldn't have been changed. Though as long as output is correct, maybe this doesn't even matter. |
|
|
I can either take your word for it, or investigate myself, which would cost me dozens of hours of my development time, or I could simply let NVidia do their job and be done with it. I prefer the latter. |
|
|
That's perfectly fine with me. No use wasting valuable time on trying to find a problem which likely doesn't even exist. Considering NVIDIA uses the PTX intermediary format for CUDA as well, if there were a serious problem with how a basic target parameter such as .address_size was being handled, I think it's safe to assume it would not go unnoticed for long. |
|
|
installed an old madVR version and used restore default and update back to the current version. i tried to reproduce this issue with a 32 bit player and i guess this is fixed now. but i can't 100% check if the openCL kernel is 32 bit. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2015-01-22 18:37 | JPulowski | New Issue | |
| 2015-01-22 18:37 | JPulowski | File Added: mpc-hc_madvr_ed1_bug.png | |
| 2015-01-24 11:07 | skaurus | Note Added: 0000686 | |
| 2015-01-24 11:19 | madshi | Note Added: 0000687 | |
| 2015-01-24 11:20 | madshi | Assigned To | => madshi |
| 2015-01-24 11:20 | madshi | Status | new => feedback |
| 2015-01-24 18:26 | omarank | Note Added: 0000688 | |
| 2015-01-24 18:31 | JPulowski | Note Added: 0000689 | |
| 2015-01-24 18:31 | JPulowski | Status | feedback => assigned |
| 2015-01-24 18:35 | madshi | Status | assigned => feedback |
| 2015-01-25 01:14 | cyberbeing | Note Added: 0000690 | |
| 2015-01-26 08:23 | cyberbeing | Note Added: 0000691 | |
| 2015-01-26 08:25 | cyberbeing | Note Edited: 0000691 | |
| 2015-01-26 09:37 | madshi | Note Added: 0000693 | |
| 2015-02-10 15:35 | cyberbeing | Note Added: 0000703 | |
| 2015-02-10 15:36 | cyberbeing | Note Edited: 0000703 | |
| 2015-02-10 15:36 | cyberbeing | Note Edited: 0000703 | |
| 2015-02-10 15:37 | cyberbeing | Note Edited: 0000703 | |
| 2015-03-23 17:48 | huhn | Note Added: 0000847 | |
| 2015-03-23 17:49 | madshi | Note Added: 0000848 | |
| 2015-03-23 18:27 | huhn | Note Added: 0000849 | |
| 2015-03-26 16:28 | huhn | Note Added: 0000867 | |
| 2015-03-26 16:30 | huhn | Note Edited: 0000867 | |
| 2015-03-26 16:32 | madshi | Note Added: 0000868 | |
| 2015-03-26 16:36 | huhn | Note Added: 0000869 | |
| 2015-03-26 17:19 | madshi | Note Added: 0000870 | |
| 2015-03-31 12:33 | JonnyRedHed | Note Added: 0000905 | |
| 2015-03-31 12:36 | JonnyRedHed | Note Edited: 0000905 | |
| 2015-04-02 11:31 | huhn | Note Added: 0000913 | |
| 2015-04-02 12:05 | JonnyRedHed | Note Added: 0000914 | |
| 2015-04-04 02:42 | cyberbeing | Note Added: 0000921 | |
| 2015-04-04 02:44 | cyberbeing | Note Edited: 0000921 | |
| 2015-04-04 02:44 | cyberbeing | Note Edited: 0000921 | |
| 2015-04-04 03:06 | cyberbeing | Note Added: 0000922 | |
| 2015-04-04 03:13 | cyberbeing | Note Edited: 0000922 | |
| 2015-04-04 08:59 | madshi | Note Added: 0000924 | |
| 2015-04-04 10:38 | huhn | Note Added: 0000927 | |
| 2015-04-05 06:35 | cyberbeing | Note Added: 0000929 | |
| 2015-04-05 07:35 | cyberbeing | Note Added: 0000930 | |
| 2015-04-05 13:36 | madshi | Note Added: 0000931 | |
| 2015-04-05 22:37 | cyberbeing | Note Edited: 0000929 | |
| 2015-04-09 12:16 | cyberbeing | Note Added: 0000934 | |
| 2015-04-14 00:54 | huhn | Note Added: 0000935 | |
| 2015-04-14 01:01 | cyberbeing | Note Added: 0000936 | |
| 2015-04-14 01:07 | huhn | Note Added: 0000937 | |
| 2015-04-14 01:08 | cyberbeing | File Added: NNEDI3_bug1632554_test2.mkv | |
| 2015-04-14 01:10 | cyberbeing | Note Added: 0000938 | |
| 2015-04-14 01:26 | huhn | Note Added: 0000939 | |
| 2015-04-14 01:27 | cyberbeing | Note Added: 0000940 | |
| 2015-04-14 01:28 | cyberbeing | Note Edited: 0000940 | |
| 2015-04-14 01:58 | huhn | File Added: 350.12 350.05.zip | |
| 2015-04-14 02:00 | huhn | Note Added: 0000941 | |
| 2015-04-14 02:19 | cyberbeing | Note Added: 0000942 | |
| 2015-04-14 02:27 | huhn | Note Added: 0000943 | |
| 2015-04-14 02:43 | cyberbeing | Note Added: 0000944 | |
| 2015-04-14 02:48 | madshi | Note Added: 0000945 | |
| 2015-04-14 03:10 | cyberbeing | Note Added: 0000947 | |
| 2015-04-14 03:10 | cyberbeing | Note Edited: 0000947 | |
| 2015-04-14 03:10 | cyberbeing | Note Edited: 0000947 | |
| 2015-04-14 03:12 | cyberbeing | Note Edited: 0000947 | |
| 2015-04-14 03:13 | cyberbeing | Note Edited: 0000947 | |
| 2015-04-14 03:17 | madshi | Note Added: 0000949 | |
| 2015-04-14 05:52 | cyberbeing | Note Added: 0000955 | |
| 2015-04-14 05:54 | cyberbeing | File Added: NVVM_NNEDI3_Output.zip | |
| 2015-04-14 05:54 | cyberbeing | Note Edited: 0000955 | |
| 2015-04-14 05:55 | cyberbeing | Note Edited: 0000955 | |
| 2015-04-14 10:06 | madshi | Note Added: 0000957 | |
| 2015-04-14 12:36 | cyberbeing | Note Added: 0000959 | |
| 2015-04-14 14:15 | madshi | Note Added: 0000960 | |
| 2015-04-14 15:00 | cyberbeing | Note Added: 0000962 | |
| 2015-04-14 15:10 | madshi | Note Added: 0000963 | |
| 2015-04-14 15:42 | cyberbeing | Note Added: 0000964 | |
| 2015-04-14 15:42 | cyberbeing | Note Edited: 0000964 | |
| 2015-04-14 15:54 | madshi | Note Added: 0000965 | |
| 2015-04-15 01:45 | cyberbeing | Note Added: 0000966 | |
| 2015-09-26 06:52 | huhn | Note Added: 0001181 | |
| 2018-01-14 15:02 | madshi | Status | feedback => closed |
| 2018-01-14 15:02 | madshi | Resolution | open => unable to reproduce |
