DGDecNV and KNLMeans under Win10_x64

[admin]

Did you lose interest in this problem?

[Guest 2]

@Guest 2

I made a 64-bit test version with CUDA 7.5 for you. Please tell me the results.

http://rationalqm.us/misc/Guest 2_64.zip

I'll do a try with that ASAP.

I didn't lose interest, I had to work for 12 hours every day on last friday, saturday and sunday to solve a bad work problem.

As I wrote on doom9, my current encoding pipeline is 32bit, I need that version if possible

Thanks for your work.

[admin]

http://rationalqm.us/misc/Guest 2_32.zip

[Guest 2]

http://rationalqm.us/misc/Guest 2_32.zip

As I wrote on Doom9, tried DGDecNV with another OpenCL plugin named nnedi3ocl however it's so old I can't set OpenCL GPU priority.

If I remove Intel GPU from bios and leave Nvidia only, it simply doesn't work, even with sw decoding.



Now I'm going to install Nvidia developer drivers with Windows 10 and OpenCL extension support.

Edit: neither developer 355.97 does the magic. KNLMeansCL works perfectly without DGDecNV.

[admin]

"KNLMeansCL works perfectly without DGDecNV"

And DGDecNV works perfectly without KNLMeansCL?

For my system, they both work perfectly together.

Windows 10 64-bit
DGDecNV 2049 64-bit
KNLMeansCL 64-bit 0.6.2
GeForce GT 730
OpenCL 1.2
CUDA 355.82
Avisynth+ r1825

[Guest 2]

And DGDecNV works perfectly without KNLMeansCL?

For my system, they both work perfectly together.

Windows 10 64-bit
DGDecNV 2049 64-bit
KNLMeansCL 64-bit 0.6.2
GeForce GT 730
OpenCL 1.2
CUDA 355.82
Avisynth+ r1825

The answer is yes on 32bit.

Your system is working on 64 bit, I just have to try 64 bit but I suppose you could be faster as I have to understand how to use AviSynth+ on 64bit without messing things up.

[Guest 2]

I was looking for x64 encoding alternatives.

Look at latest threads of http://forum.doom9.org/showthread.php?t=172068&page=29, there are some problems with Windows10 and DGDecNV.

Can you please tell me the easiest way to test x264 encoding in x64 environment?

[admin]

Look at latest threads of http://forum.doom9.org/showthread.php?t=172068&page=29, there are some problems with Windows10 and DGDecNV.

You jump to conclusions! I could equally say "problems with Windows 10 and staxrip".

Can you please tell me the easiest way to test x264 encoding in x64 environment?

Install Avisynth+ and then use a 64-bit version of x264.exe. BTW, there is a great thread on Doom9 about switching Avisynth versions back and forth easily.

Somehow I doubt all this will make a difference but certainly try it if you like.

[admin]

Agreed. On the other hand, it may be a useful heuristic to try to get someone to look into the issue, especially when everyone is pointing fingers at each other.

[AJR]

Can you please tell me the easiest way to test x264 encoding in x64 environment?

All you have to do is install AVS+ from here:
http://www.avs-plus.net/

This build (r1576) is the most stable, I would not recommend r1825. Then you can use DGIndexNV/DGDecodeNV/x264, all 64 Bit.

May I know why exactly you dont recommend r1825? Whats wrong with this version? Authors of Avisynth+ recommends r1825 as the most stable "single threaded" solution, MT is marked as unstable.

[AJR]

I dont use QTGMC so I dont understand why it is so important to say dont use r1825 in general. I am using hw deint via VP6. I dont see such slowdown between r1576 and r1825. Did you find anyone else who has confirmed general slowdown?

I cannot find recommendation for r1825. So maybe I was not remembered well. But I am sure I have read a post that r1825 in sigle threaded processing is working at least the same well as r1576. If you want I can edit my previous post and delete the sentence about recommendation

[jpsdr]

I dont use QTGMC

QTGMC is just used here as test to show a potential global/general issue, not something specific to QTGMC.

[admin]

Didn't someone identify the commit that caused it? If so, why can't we have a fixed version pronto?

[admin]

Have the original developers abandoned Avisynth+? We now have random people trying to hack away on it?

[Guest 2]

Could you please put version 2049 instead of test in the test builds?

Otherwise staxrip can't recognize them

[admin]

I don't know what you are talking about. I don't put "test" anywhere.

[Guest 2]

Just found that AVSMeter64 and x264_x64 works with 64 bit versions of both DGDecNV and KNLMeansCL:

Code: Select all

LoadPlugin("D:\eseguibili\media\DGDecNV\x64\DGDecodeNV.dll")
DGSource("E:\in\2_01 favoloso mondo di Amelie, Il\amelie.dgi")
KNLMeansCL(D=1, A=1, h=7.0,device_type="GPU")
CompTest(1)

Code: Select all

AVSMeter 2.1.2 (x64)
AviSynth+ 0.1 (r1825, MT, x86_64) (0.1.0.0)

Number of frames:                 1764
Length (hh:mm:ss.ms):     00:01:13.500
Frame width:                      1920
Frame height:                      816
Framerate:                      24.000 (24/1)
Colorspace:                       YV12

Frames processed:               1764 (0 - 1763)
FPS (min | max | average):      2.087 | 41.93 | 22.76
Memory usage (phys | virt):     101 | 389 MB
Thread count:                   23
CPU usage (average):            10%

Time (elapsed):                 00:01:17.497

There must be something wrong with NVIDIA drivers or something else on 32 bit.

I was accustomed with MeGUI, I'll have to use command line. StaxRip gives me problem with demux dependencies.

[admin]

Thanks for the status report and please keep me informed of any further findings.

[Guest 2]

Thanks for the status report and please keep me informed of any further findings.

No other findings for some time, at least until AviSynth+ gives no image corruption and cretindesalpes compiles an x64 version of modified MVTools.

If you can report this behaviour to your Nvidia contacts, probably you can debug together the problem.

In the mean time I'll be obliged to use Intel GPU to decode videos.

[admin]

I'm not interested in debugging KNLMeansCL, and I'm certainly not going to bother nVidia about something only one person reports.

[Guest 2]

I'm not interested in debugging KNLMeansCL, and I'm certainly not going to bother nVidia about something only one person reports.

It's a pity there are no other working OpenCL AviSynth plugins now.

[admin]

Why is it a pity? Who cares about OpenCL?

CUDA outperforms OpenCL by 30% and CUDA performs faster data transfers to and from a GPU's memory.

To protect the source for a closed-source application requires jumping through hoops for OpenCL.

Anyway, it's all moot for DGDecNV which relies on CUVID. I suppose one could try to make a case for OpenCL transform filters on portability grounds, but I speculate that most people are more concerned about performance on their own platform than the theoretical portability to other platforms.

From the internet: "When portability is an issue, it is always better to use a standard. However, an interesting fact on the portability of OpenCL is that while a big part of the same code (mostly the kernels) can be certainly executed in several platforms, the high performance will not be as portable. There will still be a need of making optimizations to exploit the architecture at hand. A code optimized for a GPU does not necessarily work as optimized on a multicore ARM or FPGA. Also the control code is likely not 100% portable and must be re-written when changing the platform to a totally different one."

Flame suit is on, fire away!

[Guest 2]

Why is it a pity? Who cares about OpenCL?
CUDA outperforms OpenCL by 30% and CUDA performs faster data transfers to and from a GPU's memory.

Ok, let's try to tell Khanattila to port KNLMeansCL to CUDA.

[admin]

KNLMeansCL must be a really big deal to have you in such a state. Help me out, what is so great about it? I'm not doubting, I just don't know anything about it.

[Aleron Ives]

Why is it a pity? Who cares about OpenCL?

Well, nVidia certainly doesn't. They added a bug for GK104 cards in their 330.x driver branch that cuts OpenCL performance in half, which means I can never upgrade my GPU driver without killing my Folding@home performance. Apparently nVidia doesn't care about the bug at all, because they've released many drivers over the last year and have never taken any steps to fix it. They don't seem to care about supporting their cards with older architectures, either.